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:
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. A payload that doesn’t match the schema is acknowledged with 200 and recorded as a failed receipt, but the workflow never runs. A body that isn’t a JSON object or array is refused with 422 INVALID_PAYLOAD and not recorded. An empty body is accepted as a bare trigger.
Authentication
Every request must be signed — a webhook has no unauthenticated mode:
A request with a missing or invalid signature, or a stale timestamp, is refused with
401 UNAUTHORIZED and not recorded.
Independently of the signature, a webhook can restrict senders to an IP allowlist.
Each webhook gets its own signing secret (hasp_whk_…) when it is created. The secret is stored encrypted at the project level and is never exposed in the contract.