What Can Actions Do?
Billing & Payments
Customer Context
System Status
Order & Inventory
Ticketing & Jira
Any REST API
Action Types
Scheduled Actions
Actions can run automatically on a schedule using cron expressions — no user question required.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
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
Trigger: “When the user asks about a refund status, invoice, or payment”Parameters:
STRIPE_API_KEYDouble Charge Investigation
Double Charge Investigation
Trigger: “When the user reports duplicate charges, double billing, or being charged twice”Parameters:
STRIPE_API_KEYOutage & Incident Status
Outage & Incident Status
Trigger: “When the user reports an error, outage, downtime, or asks if there’s a known issue”Parameters:
STATUSPAGE_API_KEY, STATUSPAGE_PAGE_IDEntitlements & Plan Lookup
Entitlements & Plan Lookup
Trigger: “When the user asks about their plan, features, entitlements, limits, or why they can’t access something”Parameters:
PRODUCT_DB_API_KEYCreate Jira Bug with Full Context
Create Jira Bug with Full Context
Trigger: “When the user asks to create a bug report, Jira issue, or ticket for engineering”Parameters:
JIRA_API_TOKEN, JIRA_EMAIL, JIRA_DOMAIN, JIRA_PROJECT_KEYFor Support Leaders
SLA Breach Prevention
SLA Breach Prevention
Trigger: “When the user asks about SLA status, at-risk tickets, or potential SLA breaches”Parameters:
ZENDESK_API_TOKEN, ZENDESK_SUBDOMAIN, ZENDESK_EMAILProactive Incident Communications
Proactive Incident Communications
Trigger: “When the user asks which customers are affected by an incident, outage, or issue”Parameters:
ANALYTICS_API_KEYFor Customers (Self-Service)
Order & Shipping Status
Order & Shipping Status
Trigger: “When the user asks about order status, shipping, tracking, or delivery”Parameters:
SHIPPO_API_KEYAccount & Billing Self-Service
Account & Billing Self-Service
Trigger: “When the user asks about their account, plan, subscription, billing, or renewal”Parameters:
STRIPE_API_KEYReal-Time Product Availability
Real-Time Product Availability
Trigger: “When the user asks about stock, inventory, availability, or if a product is in stock”Parameters:
INVENTORY_API_KEY
How Actions Work
Trigger Detection
Parameter Extraction
Execution
Response Handling
Creating an Action

Step 1: Basic Information

Step 2: Define 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

Isolated Execution
Pre-installed Libraries
Results via stdout
print() output is captured and returnedSecrets Protection
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
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:Basic Pattern
Every Python action follows the same pattern:API Call Actions


{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:
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

Dashboard Actions
Per-Action Menu (⋮)
How Actions Appear in Answers

Secrets Management

Variables

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.
- 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.
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
Write Specific Trigger Conditions
Write Specific Trigger Conditions
Write Clear Parameter Descriptions
Write Clear Parameter Descriptions
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
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
Every enabled action is evaluated
Parameters are extracted for each match
Matched actions run in parallel
One unified answer is generated
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)
pto_balance_lookup
pto_balance_lookup
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)
submit_pto_request
submit_pto_request
{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)
notify_manager
notify_manager
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: (runssubmit_pto_requestandnotify_managerin parallel) Done. PTO request #4892 submitted to SAP for Friday, Apr 17. The HR approvals channel has been notified on Slack.
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.
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).