HTTP Webhooks
If a system can POST, it can trigger an agent. JSON, form data, and file uploads all hit the same endpoint. No glue server, no parser to maintain.
Overview
Every webhook connector gets a unique URL and a secret key. Anything that can send an HTTP request can trigger the agent behind it: POST a JSON body, submit form data, upload files as multipart, or fire a plain GET with query parameters. Three modes cover the delivery patterns that matter. Inbound queues the run and returns run IDs immediately, sync holds the connection and returns the agent's result in the same response, and outbound POSTs completed run results to a configured URL.
That replaces a separate glue service: an HTTP server, a payload parser, an auth check, a queue, and a worker. Point the source system at the webhook URL, and the request arrives in the agent as structured input with nothing else to deploy or patch.
How it works
Create the connector and pick a mode
Add an HTTP Webhook connector from the agent's Connector Flow. Inbound queues runs and responds immediately with run IDs, sync waits for the agent to finish (5 minutes by default) and returns the result inline, and outbound delivers completed run results to the configured endpoint.
Copy the URL and secret
The connector detail drawer opens with the webhook URL and secret. Authentication is enabled by default; send the secret in the X-Connic-Secret header, an Authorization: Bearer header, or a query parameter.
Send requests
POST JSON, form data, or multipart file uploads, or send a GET with query parameters. The payload is passed to the agent as input, and each request triggers a run on every linked agent.
Production patterns
Patterns teams ship in production, with Connic running the queues, workers, and schedulers.
Order placed
POST /webhook/ordersAgent validates payment, checks inventory, scores fraud risk, and routes to fulfillment before the confirmation email leaves the queue.
Order placed
POST /webhook/ordersAgent validates payment, checks inventory, scores fraud risk, and routes to fulfillment before the confirmation email leaves the queue.
Form submitted
POST /webhook/leadsAgent enriches with company data, scores buying intent, and routes hot leads to the CRM. Cold leads drop into a nurture sequence.
Form submitted
POST /webhook/leadsAgent enriches with company data, scores buying intent, and routes hot leads to the CRM. Cold leads drop into a nurture sequence.
Card declined
POST /webhook/paymentsAgent identifies the decline reason, sends a retry link, and offers an alternate payment method to recover revenue that would otherwise be written off.
Card declined
POST /webhook/paymentsAgent identifies the decline reason, sends a retry link, and offers an alternate payment method to recover revenue that would otherwise be written off.
Ticket created
POST /webhook/supportAgent categorizes the ticket, pulls the relevant docs, and drafts a reply. Routine questions resolve instantly; tricky ones reach a human with full context attached.
Ticket created
POST /webhook/supportAgent categorizes the ticket, pulls the relevant docs, and drafts a reply. Routine questions resolve instantly; tricky ones reach a human with full context attached.
Authentication and signature verification
Inbound and sync webhooks require the connector secret by default, provided as an X-Connic-Secret header (recommended), an Authorization: Bearer header, or a query parameter. Require Authentication can be turned off when a middleware before-function validates requests before they reach the agent.
Outbound deliveries are signed. Every request Connic POSTs to the configured endpoint carries an X-Connic-Signature header with a hex-encoded HMAC-SHA256 signature and an X-Connic-Timestamp header. Verify by computing HMAC-SHA256 over the timestamp, a dot, and the raw body; timestamps older than 5 minutes can be rejected to prevent replays. For endpoints on private networks, route outbound requests through a Connic Bridge.
Payloads, files, and responses
A JSON body is passed to the agent as-is, form fields become key-value pairs, and query parameters (except the secret) come along on GET requests. Multipart uploads arrive in the payload with text fields at the top level and files base64-encoded under a files key; each file is handed to the model as inline data. Images, PDFs, Office documents, and data files are supported, up to 10 MB per file.
Every request that clears authentication becomes a normal agent run: it shows up in run history with full traces, token and cost tracking, and the same guardrails and approval rules as any other trigger. Inbound responses return the dispatched run_ids, and sync responses return the run's output directly. See the full request and response formats in the webhook docs.
Information
- Publisher
- By Connic
- Connectors
- Connectors
- Modes
- Inbound, Outbound, Sync
- Documentation
- HTTP Webhooks docs
Frequently Asked Questions
X-Connic-Secret header, an Authorization: Bearer header, or a query parameter. Deliveries Connic sends out are signed with HMAC-SHA256 in the X-Connic-Signature header plus an X-Connic-Timestamp header, so the endpoint can verify authenticity and reject replayed requests.multipart/form-data with one or more file fields and they are passed to the model as inline data. Images, PDFs, Word and OpenDocument files, spreadsheets, presentations, and plain-text formats are supported, up to 10 MB per file. Files arrive base64-encoded under a files key in the payload, so middleware can inspect or validate them before the run.Bring the event source, payload shape, result destination, and any private-network or approval requirements. We will map HTTP Webhooks to the right Connic connector mode, deployment path, and observability setup.
Talk to Sales