> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hookie.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Use Cases

> Concrete event pipelines you can stand up in an afternoon — lead intake with AI qualification, support ticket triage, billing lifecycle, and product-led onboarding.

Four 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 JSON event to a URL you own. Your service is what writes to your CRM, posts to Slack, or sends the email.** Hookie does not talk to those products, and there is no configuration that makes it — a destination is one immutable HTTPS URL, one fixed body and one fixed header set, with no auth header and no body template.

<CardGroup cols={2}>
  <Card title="Lead intake & AI qualification" icon="filter" href="/use-cases/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.
  </Card>

  <Card title="Support ticket triage" icon="life-ring" href="/use-cases/support-ticket-triage">
    Helpdesk webhooks land, an AI step assigns severity, and the urgent ones are escalated to your own service.
  </Card>

  <Card title="Billing & account lifecycle" icon="credit-card" href="/use-cases/billing-account-lifecycle">
    Stripe events routed into datasets by kind, with dunning separated from provisioning.
  </Card>

  <Card title="Product-led onboarding" icon="rocket" href="/use-cases/product-led-onboarding">
    Signup and activation events drive a workflow that waits for the next step and nudges when it does not come.
  </Card>
</CardGroup>

## 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, exponential backoff up to 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.  |

<Note>
  Building one of these? [`hookie listen`](/cli/local-development) forwards the live events to your laptop while you write the handler, so you can develop against real payloads without deploying anything.
</Note>