Skip to main content
Actions transform your Guru from a static knowledge base into a dynamic AI agent that can execute code, call APIs, and fetch real-time data. When users ask questions, your Guru automatically triggers relevant actions to provide live, accurate responses.

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

Use API Call for simple lookups (faster response). Use Python Code when you need to process data, call multiple APIs, or add conditional logic.

Scheduled Actions

Actions can run automatically on a schedule using cron expressions — no user question required.
  1. Open the action editor
  2. Scroll to Schedule Configuration
  3. Toggle Enable Scheduling
  4. Enter a cron expression (e.g., 0 9 * * * for daily at 9 AM)
The action will run automatically at the scheduled time. Results are logged in the action history.
Common scheduled action patterns:
  • 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

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: STRIPE_API_KEY
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: STRIPE_API_KEY
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: STATUSPAGE_API_KEY, STATUSPAGE_PAGE_ID
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: PRODUCT_DB_API_KEY
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: JIRA_API_TOKEN, JIRA_EMAIL, JIRA_DOMAIN, JIRA_PROJECT_KEY

For Support Leaders

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: ZENDESK_API_TOKEN, ZENDESK_SUBDOMAIN, ZENDESK_EMAIL
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: ANALYTICS_API_KEY

For Customers (Self-Service)

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: SHIPPO_API_KEY
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: STRIPE_API_KEY
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: INVENTORY_API_KEY
Actions
Each Guru has a limit on the number of actions based on your plan (shown as “5 of 10 actions used”).

How Actions Work

1

Trigger Detection

The Guru checks if the user’s question matches your defined trigger conditions.
2

Parameter Extraction

Parameters are automatically extracted from the user’s question based on your descriptions.
3

Execution

Python code runs in an isolated container, or an HTTP request is made to your API endpoint.
4

Response Handling

The AI interprets and presents the results to the user.
Actions only execute if all required parameters can be extracted from the user’s question (or have default values).

Creating an Action

Empty Actions

Step 1: Basic Information

Action Basic Configuration
Be specific with trigger conditions. Instead of “When asking about data”, use “When asking about current weather conditions for a specific location”.

Step 2: Define Parameters

Action Parameters Configuration
Parameters are values extracted from the user’s question: How to use parameters:
  • 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

Python Code Configuration
Execute custom Python code in isolated Docker containers. Secrets and parameters are injected as environment variables.

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 returned

Secrets 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
You cannot install additional packages at runtime. If you need a package that isn’t listed, contact us.
When using boto3, the AWS SDK endpoint URL must be a static string literal in your code. Dynamic values (env vars, kwargs expansion, computed strings) are rejected at validation time, and mutating AWS endpoint or metadata env vars (AWS_ENDPOINT_URL*, AWS_EC2_METADATA_DISABLED, AWS_IGNORE_CONFIGURED_ENDPOINT_URLS) from inside an action is blocked. EC2 instance metadata probing is disabled in the sandbox.

Execution Limits

Security Restrictions

Accessing Parameters and Secrets

Parameters and secrets are injected as environment variables:
The os module is restricted. Only os.environ, os.environ.get(), and os.getenv() are allowed. Other os functions (os.system(), os.popen(), file operations) are blocked.

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

API Call Configuration
Configure HTTP requests to external APIs:
API Call Request Body
Request Body Example:
Use {parameter_name} or {SECRET_NAME} syntax anywhere in the URL, headers, or body. You can also reference the built-in variables {GURUBASE_USER_EMAIL}, {GURUBASE_USER_NAME}, {GURUBASE_USER_GROUPS}, and {GURUBASE_GURU_SLUG}. See Built-in Variables for details and limitations. Example URL with built-in variables:

Built-in Variables

Gurubase automatically injects four reserved variables at execution time. These are available in both Python Code and API Call actions.

Python Code Usage

API Call Usage

Use {VARIABLE_NAME} syntax in endpoint URL, headers, or request body:
Header example:
These names are reserved. You cannot create a parameter or secret named GURUBASE_USER_EMAIL, GURUBASE_USER_NAME, GURUBASE_USER_GROUPS, or GURUBASE_GURU_SLUG. The action will be rejected at validation time.
User variables (GURUBASE_USER_EMAIL, GURUBASE_USER_NAME, GURUBASE_USER_GROUPS) are populated only when the action is called from the Gurubase web UI (chat or Test button). When the action runs via widget, bot integrations (Slack, Discord, Jira, GitHub, Zendesk), MCP, or any API-key-authenticated path, user email and name resolve to empty strings, and groups resolves to Everyone. GURUBASE_GURU_SLUG is always populated. Check for empty values if your action can be triggered from multiple paths.

Managing Actions

Actions Management Dashboard

Dashboard Actions

Execution history is retained for a limited number of days (5 days by default on Gurubase Cloud). The exact retention period is shown beneath the Execution History title on the History page.

Per-Action Menu (⋮)

If a secret used by an action is deleted, that action will be automatically disabled.

How Actions Appear in Answers

Action Reference
When an action is used, it’s shown with the action name in the response.

Secrets Management

Secrets
Secrets are encrypted credentials (API keys, tokens, passwords) stored in Guru Settings → Secrets.
Secret names cannot conflict with parameter or variable names. Secret, variable, and parameter names also cannot be GURUBASE_USER_EMAIL, GURUBASE_USER_NAME, GURUBASE_USER_GROUPS, or GURUBASE_GURU_SLUG — those are reserved for built-in variables. Deleting a secret automatically disables all actions using it.

Variables

Variables
Variables are plain-text values stored in Guru Settings → Variables. They are available to actions at runtime, but the delivery mechanism differs by action type: Python Code actions receive them as real environment variables (read with os.environ.get('VARIABLE_NAME')), while API Call actions do not get process-level env injection and instead resolve {VARIABLE_NAME} placeholders in the request template (endpoint, headers, body, basic-auth fields) via string substitution at execution time. Variables stay plain-text in both paths: they are not encrypted at rest and not masked in execution logs or output, so use them only for non-sensitive configuration like base URLs, default IDs, or feature flags. When to use which
  • Secrets for anything you would not want to appear in logs or exported audit data (API keys, tokens, passwords, signing keys).
  • Variables for everything else (URLs, region codes, default IDs, switches). Pulling these into Variables makes it easy to update them in one place without editing every action.
Keys must be unique across Secrets and Variables for a guru. A variable named API_BASE_URL and a secret named API_BASE_URL cannot coexist. Reserved prefixes (LD_, PYTHON_, EXECUTOR_, REDIS_, DOCKER_) and reserved names like GURUBASE_USER_EMAIL are blocked for both. Deleting a variable automatically disables all actions that reference it.
Automatic variables When you create an Action or Agent, Gurubase auto-creates a Variable whose value is that entity’s slug: ACTION_<SLUG>_SLUG holds the action’s slug, and AGENT_<SLUG>_SLUG holds the agent’s slug. This lets one action invoke another by reference, for example by passing os.environ.get('ACTION_LOOKUP_ORDER_SLUG') to a tool call. These appear in the Variables page with an Automatic chip; edit and delete are disabled because the lifecycle is managed by Gurubase. Deleting the underlying action also removes the variable. The ACTION_ and AGENT_ prefixes are reserved for these auto-managed variables and cannot be used for user-created secrets or variables.

Best Practices

  • Always test actions with various parameter combinations
  • Verify error handling for missing or invalid parameters
  • Check that secrets are properly masked in output
  • 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

Multi-Step Workflows

Most real workflows don’t fit into a single action. They chain reads with writes, or fan out writes across multiple systems in one turn. Gurubase runs every relevant action per turn, each selected and parameterized independently based on the user’s question. A single turn can include:
  • Reads to pull live data from a database, CRM, or HR system.
  • Writes that actually change state in the systems you own (create a ticket, submit a request, post a message).
  • Parallel fan-out to multiple systems (create a Jira issue and DM an on-call engineer at the same time).

How Gurubase Picks Multiple Actions per Turn

1

Every enabled action is evaluated

Each action’s condition prompt is checked against the user’s question. Any number of conditions can match in a single turn.
2

Parameters are extracted for each match

For every matched action, the LLM pulls the required parameters out of the conversation (including context from earlier turns).
3

Matched actions run in parallel

Up to 3 actions execute concurrently. Results stream back as they complete.
4

One unified answer is generated

Gurubase composes a single response that weaves together outputs from every action plus knowledge from your sources.

Worked Example: Employee PTO Flow

This is the pattern demonstrated in the HR Guru demo video: an employee assistant that reads a PTO balance in one turn, then writes the request to SAP and pings the manager on Slack in the next. One conversation, two action types, three systems.

Action 1: Read the PTO balance (Python)

What it does: Reads the signed-in user’s email from the built-in GURUBASE_USER_EMAIL variable, calls the HR API, prints the balance. The printed output is injected into the agent’s answer.Sample response: “Hi Alex, you have 12 PTO days remaining this year. Last used on March 3, 2026 (2 days).”

Action 2: Create the PTO request in SAP (API call)

What it does: POSTs to SAP’s time-off endpoint. The signed-in user’s email is pulled from {GURUBASE_USER_EMAIL}, the date comes from the extracted date parameter, and the SAP token is resolved from the encrypted SAP_API_TOKEN secret at execution time.

Action 3: Notify the manager (API call)

What it does: Posts a Slack message to the HR approvals channel. The condition prompt is scoped so this fires alongside submit_pto_request (in the same turn), not as an independent action the LLM might pick on its own.

How it plays out

Turn 1 (read)
User: How many PTO days do I have left? Agent: (runs pto_balance_lookup) Hi Alex, you have 12 PTO days remaining this year. Last used on March 3, 2026 (2 days).
Turn 2 (parallel writes)
User: Perfect. Book Friday off then. Agent: (runs submit_pto_request and notify_manager in parallel) Done. PTO request #4892 submitted to SAP for Friday, Apr 17. The HR approvals channel has been notified on Slack.
Condition prompts are the glue. Write them specifically enough that notify_manager only fires alongside a real submission, not on every chat about PTO.

Parallel vs Sequential

Matched actions always run in parallel within a single turn (up to 3 concurrent). This keeps response time low and is the right default when actions are independent, like SAP + Slack above. If you need true data dependencies where the output of action A must feed action B, you have two options:
  • Multi-turn: Let turn 1 finish, then drive turn 2 with the follow-up question. The conversation carries context between turns, which is how the PTO flow above works.
  • Agent actions: Wrap the whole sequence in a single AGENT-type action whose internal tool-calling loop runs the steps in order. The agent sees each sub-tool’s output before deciding on the next one.
For most workflows, parallel + multi-turn is plenty. Reach for AGENT only when one user request truly needs a deterministic multi-step pipeline.

Testing the Flow

Before enabling a multi-action workflow for users:
  • Test each action standalone from the Action Builder with hand-picked parameters. Every action should succeed in isolation.
  • Run a full conversation in the Guru preview. Verify the right combination of actions fires at each turn and that parameters extract correctly from the user’s wording.
  • Review the audit log. Every run records inputs, outputs, duration, and the question that triggered it. This is the fastest way to debug extraction failures or parameter mismatches.
  • Stress-test condition overlap. If two actions might fire for the same question, either tighten their condition prompts or accept that both will run (and make sure neither has side effects that break the other).

Next Steps

Prompting Your Guru

Customize your Guru’s responses and behavior

Data Sources

Add and manage knowledge sources

Analytics

Monitor action usage and performance

MCP Client Connections

Connect external MCP tools to your Guru

API Reference

Build custom integrations