webhooks

Every subscription in the workspace, newest first, with its state and how many consecutive failures it has seen. The secret is not among the fields: it is answered once, at creation and at each rotation, and stored sealed - there is no read that can produce it again.

The subscribe half of the REST hooks pattern: an integration platform creates its own subscription through this route and deletes it again when the user turns the automation off. What arrives at the target is the CloudEvent, identical to the one this system uses internally - there is no feature available only internally or only externally - signed with a secret generated here, answered once in this response, and never readable afterwards. The target is an egress channel and is treated as one: it goes through the guarded client, so a private range or the cloud metadata address is refused unless the installation has deliberately released private networks.

The target, the event types, the filter and the state. Re-enabling a subscription that was disabled for sustained unreachability is a write like any other and is audited as one - somebody decided the target is reachable again, and the trail says who. An omitted field is left alone. The secret is not changeable here; rotation has its own route, because handing a new secret to a subscriber is a different act from editing one.

The unsubscribe half of the REST hooks pattern. The deliveries go with the subscription: a delivery log for a subscription nobody can reach any more is a record of attempts against an address the workspace no longer knows.

Every attempt with its status, the response the target gave and when the next attempt is due. A run of eight failures ends in DEAD_LETTER, which is where an operator looks and what a replay acts on.

The same event, sent again by hand after whatever made it fail has been fixed. The event identifier is the one it always had, so a subscriber that deduplicates on X-Hubtask-Event-Id sees the repeat for what it is; the attempt counter carries on rather than resetting, so the delivery log stays a true account of how many times this event was sent.

One event, delivered to one named subscription through the same pipeline every delivery takes: the same delivery table, the same signature, the same retry ladder and the same dead letter. The subscription's own event-type filter is deliberately not consulted - naming the subscription is the point of the call - but a paused or disabled subscription is refused, and an event a restore replayed is never delivered. This is also what a rule's SEND_WEBHOOK action performs: the rule names the subscription, and the run supplies the event it is about.

Answers the new secret once, and keeps the old one verifying for a grace period. That overlap is the whole point of the route: a subscriber cannot deploy atomically, and a rotation that took effect instantly would drop every event arriving between the call and the deployment. Signatures are computed with the current secret from this moment on. What the grace period buys is the subscriber's side of the check, not ours.

Events of one type, oldest first, for a platform that has no address a webhook could reach - an n8n instance behind NAT, a Zapier polling trigger. The body of each entry is the same CloudEvent a webhook subscription would have been POSTed: one schema, two transports, and id is the same value X-Hubtask-Event-Id carries, so a consumer that already deduplicates on it needs to learn nothing new. The cursor is opaque, signed and derived from the outbox's own ordering, so it survives a restart and a failover. Two polls with it neither repeat an event nor step over one. The window is the outbox's retention period, and a cursor older than it is refused with 410 gone rather than silently answered from the beginning. A poller that missed more than the window has to be told that it missed - one that was quietly restarted would go on reporting a consistency it does not have. A replayed event - one a restore wrote rather than one somebody did - is not answered here, exactly as it is not delivered to a webhook.