Skip to main content
A webhook is an inbound HTTP endpoint provisioned by your project. External systems post events to the URL; workflows in the project listen to specific webhook endpoints as triggers. Webhooks are intentionally sibling to integrations (not nested inside them). Integrations are outbound — your workflows call external systems. Webhooks are inbound — external systems call your project.

​
Creating a webhook

Describe the inbound event:
“Create a webhook so our EHR system can notify us when a patient’s chart is updated.”
or
“Add a webhook endpoint for Stripe payment events.”
The system creates the webhook and assigns a URL under your org’s runtime subdomain:
or for custom domains on Enterprise:
Copy this URL and configure it in the external system.

​
Connecting a webhook to a workflow

Once the webhook exists, a workflow can listen to it:
“When the EHR webhook fires, extract the patient ID, look up the record in our entities, and run the PHI-aware chart update workflow.”
The system compiles a workflow with a webhook trigger, wires the payload schema, and sets up the lookup step.

​
Payload schema

The system infers payload schema from your description or from a sample payload you provide:
“The EHR sends JSON like this: {"patient_id": "...", "event": "chart_updated", "updated_fields": [...]}.”
Paste the sample payload in chat. The system extracts the schema, makes it part of the workflow contract, and validates incoming payloads against it at runtime. Payloads that don’t match the schema are rejected with a 400 before the workflow fires.

​
Authentication

Webhooks support: Configure the authentication method when creating the webhook. The secret is stored encrypted at the project level and is never exposed in the contract.

​
Multi-trigger with webhooks

A workflow can listen to multiple webhook endpoints when the payload schemas are compatible (Class A or Class B multi-trigger). Example: two referral partners each send intake data to separate webhook URLs, but the downstream processing is identical. Configure both webhooks as triggers on the same workflow. See Workflow authoring → Multi-trigger workflows.

​
Reverse-dependency view

From the webhook resource view, you can see which workflow handles incoming requests. A webhook cannot be deleted while a workflow depends on it.