Inbound Webhooks

Inbound webhooks let external systems push events into Sprigr Teams. Each webhook gets a unique URL that accepts HTTP POST requests, processes the incoming payload, and routes it to the right destination — whether that is a specific agent, a workflow, a custom script, or your knowledge base.

Webhooks are the bridge between your existing systems and Sprigr Teams. Any system that can send HTTP requests (monitoring tools, CRMs, e-commerce platforms, form builders) can trigger actions in your workspace.

How webhooks work

1. You create a webhook in Sprigr Teams, which generates a unique URL
2. You configure your external system to send HTTP POST requests to that URL
3. When an event occurs, the external system sends a payload to the webhook URL
4. Sprigr Teams receives the payload, authenticates the request (if configured), and routes it to the configured destination

Each webhook can be configured with authentication, a destination type, and a response mode.

Destination types

When creating a webhook, you choose where incoming payloads should be routed.

Agent

Send to a specific agent. The webhook payload is delivered as a message to the selected agent, which starts a new conversation or continues an existing one. The agent can then process the information and take action using its tools and integrations.

Best for: Alerts, notifications, and events that need an intelligent response. For example, a monitoring alert that the agent should diagnose and triage.

Configuration:

• Select the destination agent
• Optionally provide a system message that gives the agent context about what this webhook is for

Workflow

Trigger a workflow. The webhook payload is passed as input to the selected workflow, starting a new execution. The payload data is available to all steps in the workflow.

Best for: Structured, multi-step processes that should kick off when an event happens. For example, starting an onboarding workflow when your HR system sends a “new employee” event.

Configuration:

• Select the destination workflow
• The workflow must have an Event trigger type configured

Code

Run a webhook script. The payload is passed to a custom script that you write. The script can transform data, apply routing logic, and decide what happens next — including forwarding to an agent, triggering a workflow, or returning a custom response.

Best for: Complex routing, data transformation, or when you need to filter events before they reach an agent. See Webhook Scripts for details.

Configuration:

• Write or select a script in the built-in code editor
• The script receives the payload, headers, and query parameters as input

Sprigr

Write to a knowledge base. The webhook payload is automatically processed and stored in a knowledge base index. This is useful for feeding data into your agents’ knowledge without manual uploads.

Best for: Continuous data ingestion. For example, receiving product updates from your e-commerce platform and keeping your product knowledge base current.

Configuration:

• Select the destination knowledge base index
• Optionally configure field mapping to control how the payload maps to knowledge base fields

Authentication types

You can secure your webhooks with authentication to ensure only authorised systems can send events.

Type	Description
None	No authentication. Any system with the URL can send events. Only use this for testing or internal systems.
HMAC	The sender signs each request with a shared secret. Sprigr Teams verifies the signature to confirm the request is authentic. This is the most common method and is supported by most webhook providers.
Bearer token	The sender includes a token in the Authorization header. Sprigr Teams checks the token against a stored value. Simple and widely supported.
Custom header	The sender includes a custom header with a secret value. You define the header name and expected value. Useful when the sending system has its own authentication scheme.

Tip

Always use authentication for production webhooks. Without it, anyone who discovers the URL can send fake events to your workspace.

Response modes

Control how Sprigr Teams responds to incoming webhook requests:

• Async (acknowledge immediately) — Sprigr Teams responds with a 200 OK immediately and processes the payload in the background. This is the default and recommended mode. The sending system does not wait for processing to complete.
• Sync (wait for response) — Sprigr Teams processes the payload and returns the result in the HTTP response. The sending system waits for the response. Use this when the sender needs an answer (for example, a form submission that should return a confirmation message).

Note

Sync mode has a timeout limit. If processing takes too long, the request will time out. For complex processing, use async mode and have the agent or workflow send results through another channel (email, Slack, etc.).

Creating a webhook

1. Navigate to the Webhooks page

   Sign in to team.sprigr.com and click Webhooks in the sidebar.

2. Click “New Webhook”

   Click the New Webhook button to open the creation form.

   

3. Enter a name

   Give the webhook a descriptive name like “New Job Notifications” or “Payment Events”. This helps your team identify the webhook later.

4. Select a destination type

   Choose where incoming payloads should be routed: agent, workflow, code, or sprigr. Then configure the destination — for example, select which agent should receive the messages.

5. Configure authentication

   Choose an authentication method (None, HMAC, Bearer Token, or Custom Header) and enter the required credentials. You can click Generate to auto-create a signing secret.

6. Select a response mode

   Choose Async (return 200 immediately) or Sync (wait for the agent/workflow to process and return a response). Async is the most common choice.

7. Click “Create Webhook”

   Click Create Webhook. The webhook is created and a unique URL is generated. Copy this URL and configure it in the external system that will be sending events.

Try asking your agent

“Set up a webhook that accepts job notifications from our CRM and passes them to the Scheduling agent for processing.”

“Create a webhook endpoint for Stripe payment events that updates our Bookkeeper agent when invoices are paid.”

Once created, you can view the webhook detail page with its configuration, URL, and trigger history.

Trigger history

Every webhook maintains a log of received events. You can also click Test to send a test payload. The trigger history shows:

• Timestamp of each received event
• The HTTP status code returned
• Whether the payload was successfully processed
• A preview of the payload
• The destination it was routed to

Use the trigger history to verify that your external system is sending events correctly and to debug any issues with payload processing.

Next steps

• Webhook Scripts — Write custom scripts to process and route webhook payloads.
• Workflows — Trigger workflows from webhook events.
• Knowledge Bases — Feed webhook data into your knowledge bases.