HookieFour pipelines, each written end to end: what arrives, what Hookie does with it, what your own service receives, and where Hookie stops.
That last part is the one worth reading before you build anything. Hookie delivers a signed event over HTTPS. A destination can carry its own headers, an API key and a JSON body template, so a plain notice can go straight to Slack or Datadog. Anything that needs judgement or your credentials — writing to your CRM, updating a ticket, deciding whether to email — is your service's job, and the destination points at it.
Lead Intake & AI Qualification
A plain HTML form posts straight at an endpoint, a workflow scores the lead, and a branch delivers only the ones worth chasing.
Read the use case →AI-Powered Support Ticket Triage
Helpdesk webhooks land, an AI step assigns severity, and the urgent ones are escalated to your own service.
Read the use case →Billing & Account Lifecycle Automation
Stripe events routed into datasets by kind, with dunning separated from provisioning.
Read the use case →Product-Led Onboarding & Activation
Signup and activation events drive a workflow that waits for the next step and nudges when it does not come.
Read the use case →What they have in common
| The raw body is kept first | Stored verbatim in submissions before any rule runs, so a routing change cannot retroactively lose what already arrived. |
|---|---|
| Datasets are just names | A dataset exists the moment a record is routed into it. There is nothing to create and no migration to run. |
| Delivery is signed and retried | HMAC-SHA256 over timestamp and body, retried for about a day (8 attempts), then dead-lettered — and replayable once you have fixed whatever was broken. |
| Everything is visible afterwards | The submission, the records, the workflow instance with its per-step log, and the delivery with your service's status code, latency and response body. |