What Can Actions Do?
Billing & Payments
Look up refunds, invoices, subscriptions, and charges in Stripe, billing systems, or ERPs
Customer Context
Pull account details, entitlements, and plan info from CRM or product databases
System Status
Check Statuspage, Datadog, or monitoring tools for outages and incidents
Order & Inventory
Track shipments, check stock levels, and query warehouse systems in real-time
Ticketing & Jira
Create bugs, update tickets, check SLAs, and manage queue hygiene
Any REST API
Connect to any system with an API — internal tools, third-party services, or custom endpoints
Action Types
| Type | Description | Latency | Best For |
|---|---|---|---|
| Python Code | Execute custom Python scripts in isolated sandbox containers | 2-3 seconds | Complex logic, data processing, multi-step API calls, AI integrations |
| API Call | Make HTTP requests directly to external APIs | Very low (~100ms) | Simple REST API lookups, single-endpoint queries |
Scheduled Actions
Actions can run automatically on a schedule using cron expressions — no user question required.| Use Case | Cron Expression | Description |
|---|---|---|
| Daily SLA report | 0 9 * * * | Every day at 9 AM |
| Hourly status check | 0 * * * * | Every hour |
| Weekly digest | 0 9 * * 1 | Every Monday at 9 AM |
| Every 15 minutes | */15 * * * * | For real-time monitoring |
How to Enable Scheduling
How to Enable Scheduling
- Open the action editor
- Scroll to Schedule Configuration
- Toggle Enable Scheduling
- Enter a cron expression (e.g.,
0 9 * * *for daily at 9 AM)
- Morning SLA briefing — Check at-risk tickets before the team starts
- Incident monitoring — Poll status pages every 15 minutes
- Usage alerts — Daily check for customers approaching limits
- Data sync — Periodically update external systems
High-Impact Actions for Common Pain Points
Customer asks: “I requested a refund 3 days ago but still haven’t received it. Order #12345. What’s going on?”
Without Actions
- Open Stripe dashboard
- Search for customer email
- Copy transaction ID
- Check subscription status in another tab
- Cross-reference with CRM
- Type “let me check and get back to you”
- 5+ minutes per ticket
With Actions
- Agent asks Guru: “Check refund for order 12345”
- Action fetches data from Stripe automatically
- AI responds with status, ETA, and next steps
- Done in seconds
For Support Agents
Refund / Invoice / Payment Lookup
Refund / Invoice / Payment Lookup
Pain: Billing questions are high-volume. Agents waste time hopping between Stripe, ERP, CRM, and email threads just to answer “where is my refund?”User asks: “Where is my refund for order 12345?” or “Can you resend the invoice for December?”Integrations: Stripe, Billing/ERP, CRMResult: Refund state + ETA + invoice link + next step (if failed)Impact: Reduces billing tickets 40%+, eliminates “let me check and get back to you”
Trigger: “When the user asks about a refund status, invoice, or payment”Parameters:
Secrets:
Trigger: “When the user asks about a refund status, invoice, or payment”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
order_id | String | Order or invoice number | Yes |
customer_email | String | Customer’s email address | No |
STRIPE_API_KEYDouble Charge Investigation
Double Charge Investigation
Pain: “I was charged twice!” claims escalate fast. Agents need exact transaction mapping to prevent unnecessary refunds.User asks: “I see two charges of $49.99. What happened?”Integrations: Payment provider, Subscription ledgerResult: Charge IDs, whether one is auth/hold, whether it was reversed, recommended responseImpact: Prevents unnecessary refunds, reduces escalations, improves customer trust
Trigger: “When the user reports duplicate charges, double billing, or being charged twice”Parameters:
Secrets:
Trigger: “When the user reports duplicate charges, double billing, or being charged twice”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
customer_email | String | Customer’s email address | Yes |
amount | Number | The charge amount in question | No |
STRIPE_API_KEYOutage & Incident Status
Outage & Incident Status
Pain: During outages, agents guess and customers get conflicting answers. Tickets pile up with the same question.User asks: “Your app is down!” or “502 error - is this known?”Integrations: Statuspage, Datadog/New Relic, Incident channelResult: Current incident status, impacted regions/features, workaround, ETA, subscribe linkImpact: Deflects 80%+ of duplicate incident tickets, standardizes incident communication
Trigger: “When the user reports an error, outage, downtime, or asks if there’s a known issue”Parameters:
Secrets:
Trigger: “When the user reports an error, outage, downtime, or asks if there’s a known issue”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
error_code | String | Error code or message (e.g., 502, timeout) | No |
feature | String | Feature or service affected | No |
STATUSPAGE_API_KEY, STATUSPAGE_PAGE_IDEntitlements & Plan Lookup
Entitlements & Plan Lookup
Pain: “Why can’t I use feature X?” causes long back-and-forth. Agents ask “What plan are you on?” when they could just look it up.User asks: “Why can’t I use SSO?” or “What’s my seat limit?”Integrations: CRM, Product DB, Feature flagsResult: Plan, entitlements, usage limits, what to upgrade, exact remediationImpact: Fewer escalations to Sales/Engineering, faster resolution
Trigger: “When the user asks about their plan, features, entitlements, limits, or why they can’t access something”Parameters:
Secrets:
Trigger: “When the user asks about their plan, features, entitlements, limits, or why they can’t access something”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
customer_email | String | Customer’s email or account ID | Yes |
feature | String | Feature they’re asking about | No |
PRODUCT_DB_API_KEYCreate Jira Bug with Full Context
Create Jira Bug with Full Context
Pain: Agents write low-quality Jira tickets. Engineers bounce them back asking for steps, logs, and environment details.Agent asks: “Create a Jira bug for this crash with all the details”Integrations: Jira/Linear, Log aggregator, Error trackingResult: Structured bug (steps, expected/actual, env, severity, customer impact)Impact: Fewer loops with engineering, faster MTTR, happier developers
Trigger: “When the user asks to create a bug report, Jira issue, or ticket for engineering”Parameters:
Secrets:
Trigger: “When the user asks to create a bug report, Jira issue, or ticket for engineering”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
summary | String | Brief description of the bug | Yes |
steps | String | Steps to reproduce | No |
customer_email | String | Affected customer | No |
priority | String | Priority level (low/medium/high/critical) | No |
JIRA_API_TOKEN, JIRA_EMAIL, JIRA_DOMAIN, JIRA_PROJECT_KEYFor Support Leaders
SLA Breach Prevention
SLA Breach Prevention
Pain: Missed SLAs create churn and fire drills. Agents don’t notice until it’s too late.Leader asks: “Which tickets will breach SLA in the next 2 hours?”Integrations: Ticketing system, SLA policies, Queue metricsResult: Prioritized list + recommended reassignment + breach countdownImpact: 60% fewer SLA breaches, better WBR metrics, reduced churn
Trigger: “When the user asks about SLA status, at-risk tickets, or potential SLA breaches”Parameters:
Secrets:
Trigger: “When the user asks about SLA status, at-risk tickets, or potential SLA breaches”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
hours_ahead | Number | How many hours to look ahead | No |
team | String | Specific team or queue to check | No |
ZENDESK_API_TOKEN, ZENDESK_SUBDOMAIN, ZENDESK_EMAILProactive Incident Communications
Proactive Incident Communications
Pain: During incidents, teams manually compile who is impacted. Customers find out on Twitter before you tell them.Leader asks: “Which customers are impacted by the EU latency issue?”Integrations: Usage telemetry, Region mapping, CRM segmentsResult: Impacted customer list + suggested email template + Zendesk macro updateImpact: Reduces churn by communicating fast and accurately, builds trust
Trigger: “When the user asks which customers are affected by an incident, outage, or issue”Parameters:
Secrets:
Trigger: “When the user asks which customers are affected by an incident, outage, or issue”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
incident_type | String | Type of incident (latency, outage, feature) | Yes |
region | String | Affected region (EU, US, APAC, etc.) | No |
ANALYTICS_API_KEYFor Customers (Self-Service)
Order & Shipping Status
Order & Shipping Status
Pain: “Where is my order?” is the #1 support question. Customers ask constantly, agents guess ETAs, wrong info causes refunds.Customer asks: “Where is my order #12345?” or “When will my package arrive?”Integrations: OMS, Carrier tracking (FedEx/UPS/USPS), Warehouse statusResult: Real tracking summary, last scan location, expected delivery, exception handlingImpact: Deflects 60%+ of WISMO tickets, reduces refunds from “lost” packages
Trigger: “When the user asks about order status, shipping, tracking, or delivery”Parameters:
Secrets:
Trigger: “When the user asks about order status, shipping, tracking, or delivery”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
order_id | String | Order number or tracking number | Yes |
SHIPPO_API_KEYAccount & Billing Self-Service
Account & Billing Self-Service
Pain: Customers can’t find basic account info. “What plan am I on?” “When does my trial end?” flood support.Customer asks: “What plan am I on?” or “When does my subscription renew?”Integrations: Billing system, Subscription managementResult: Plan details, renewal date, usage stats, upgrade optionsImpact: Deflects 40% of account-related tickets, enables self-service upgrades
Trigger: “When the user asks about their account, plan, subscription, billing, or renewal”Parameters:
Secrets:
Trigger: “When the user asks about their account, plan, subscription, billing, or renewal”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
customer_email | String | Customer’s email (from session/memory) | Yes |
STRIPE_API_KEYReal-Time Product Availability
Real-Time Product Availability
Pain: “Is this in stock?” questions are endless. Static KB answers are outdated by the time they’re published.Customer asks: “Is the Blue Widget in stock in size XL?”Integrations: Inventory management, Warehouse systemsResult: Real-time stock level, shipping estimate, alternatives if out of stockImpact: Reduces pre-sales questions 50%, increases conversions with accurate info
Trigger: “When the user asks about stock, inventory, availability, or if a product is in stock”Parameters:
Secrets:
Trigger: “When the user asks about stock, inventory, availability, or if a product is in stock”Parameters:
| Name | Type | What to Extract | Required |
|---|---|---|---|
product_name | String | Product name or SKU | Yes |
variant | String | Size, color, or other variant | No |
INVENTORY_API_KEY
Each Guru has a limit on the number of actions based on your plan (shown as “5 of 10 actions used”).
How Actions Work
Parameter Extraction
Parameters are automatically extracted from the user’s question based on your descriptions.
Execution
Python code runs in an isolated container, or an HTTP request is made to your API endpoint.
Actions only execute if all required parameters can be extracted from the user’s question (or have default values).
Creating an Action

Step 1: Basic Information

| Field | Description | Example |
|---|---|---|
| Action Name | Descriptive name for your action | ”Get Weather Data” |
| When to Trigger | Specific conditions for when this action should run | ”When the user asks about current weather for a city” |
Step 2: Define Parameters

| Field | Description |
|---|---|
| Name | Letters and underscores only (e.g., city, user_id) |
| Type | String, Number, or Boolean |
| What to Extract | Clear description for extraction |
| Required | Must be provided for action to run |
| Default Value | Fallback if not extracted |
- Python Code:
os.environ.get('city') - API Call:
https://api.example.com/weather/{city}
Step 3: Configure Action Type
Choose Python Code or API Call and configure accordingly. See Python Code Actions or API Call Actions below.Step 4: Testing
Before enabling the action, use Test Action to run it with sample parameters. This verifies that parameters, secrets, and the action logic work as expected. Check that the output looks correct and that secrets are masked in the result.Python Code Actions

Isolated Execution
Each run uses a fresh container, destroyed after use
Pre-installed Libraries
pandas, numpy, requests, openai, and more ready to use
Results via stdout
Your
print() output is captured and returnedSecrets Protection
All secrets are masked in output automatically
Sandbox Environment
Python code runs inside an isolated sandbox container: Base Image:python:3.13-slim with git and curl installed
Pre-installed Python Packages
Pre-installed Python Packages
You cannot install additional packages at runtime. If you need a package that isn’t listed, contact us.
Execution Limits
| Resource | Limit |
|---|---|
| Memory | 512MB |
| CPU | 1 core |
| Max Processes | 128 |
| Timeout | 30 seconds |
Temp Storage (/tmp) | 100MB |
Security Restrictions
| Restriction | Description |
|---|---|
| Read-only filesystem | Only /tmp is writable |
| No binary execution | /tmp mounted with noexec flag |
| Dropped capabilities | All Linux capabilities removed |
| Network access | Allowed for API calls |
Accessing Parameters and Secrets
Parameters and secrets are injected as environment variables:Basic Pattern
Every Python action follows the same pattern:See High-Impact Actions for Common Pain Points for 10 production-ready examples with real API integrations.
API Call Actions

| Field | Description | Example |
|---|---|---|
| HTTP Method | GET, POST, PUT, PATCH, DELETE | GET |
| Endpoint URL | API endpoint with parameter placeholders | https://api.github.com/users/{username} |
| Headers | Authentication and content type | Authorization: Bearer {API_KEY} |
| Request Body | JSON payload (for POST/PUT/PATCH) | See below |

{parameter_name} or {SECRET_NAME} syntax anywhere in the URL, headers, or body.
Managing Actions

Dashboard Actions
| Action | Description |
|---|---|
| History | View execution history of all actions |
| Import | Import action from JSON file |
| Create an Action | Create new action from scratch |
Per-Action Menu (⋮)
| Action | Description |
|---|---|
| Edit | Modify configuration |
| Export | Download as JSON file |
| Trigger Action | Run manually |
| Disable | Temporarily disable |
| Delete | Permanently remove |
If a secret used by an action is deleted, that action will be automatically disabled.
How Actions Appear in Answers

Secrets Management

| Feature | Description |
|---|---|
| Encryption | AES-256 encryption at rest |
| Masking | Automatically masked in all output |
| Python Access | os.environ.get('SECRET_NAME') |
| API Call Access | {SECRET_NAME} syntax |
Best Practices
Write Specific Trigger Conditions
Write Specific Trigger Conditions
| Avoid | Do Instead |
|---|---|
| ”When asking about data" | "When asking about current weather conditions for a specific location" |
| "When user needs info" | "When user asks for a GitHub user’s profile information” |
Write Clear Parameter Descriptions
Write Clear Parameter Descriptions
| Avoid | Do Instead |
|---|---|
id - “The ID” | user_id - “The unique identifier for the GitHub user whose profile information is being requested” |
city - “City” | city - “The name of the city to get weather data for (e.g., London, New York)” |
Test Before Enabling
Test Before Enabling
- Always test actions with various parameter combinations
- Verify error handling for missing or invalid parameters
- Check that secrets are properly masked in output
Keep Actions Focused
Keep Actions Focused
- Each action should do one specific task
- Avoid actions that try to do too many things
- Create multiple simple actions instead of one complex one