Replace ad-hoc HTTP calls between microservices with durable webhook delivery. Fan-out from one source to many consumers, route by event type, and guarantee delivery.
The HTTP webhook protocol has no persistence, no retries, and no observability — and it shows.
Order service calls Fulfillment service directly. Fulfillment is slow. Order service times out. The order fails. The customer sees an error. The real problem was a temporary slowdown two services away.
An order event needs to reach fulfillment, inventory, analytics, and notifications simultaneously. Writing that fan-out logic in the order service means the order service knows about every downstream consumer — adding a new consumer requires changing the publisher.
Your notification service is redeploying. The order service fired the user.created event — the notification service missed it. There's no retry built into direct HTTP calls, so the welcome email is never sent.
From raw HTTP POST to guaranteed delivery — set up in under 10 minutes.
Services POST events to their ingest endpoint instead of calling downstream services directly. GetHook acknowledges immediately — the publisher doesn't wait for consumers.
POST /ingest/src_order_service_token
{ "event_type": "order.created", "payload": { "order_id": "ord_abc", "customer_id": "cust_xyz", "amount": 9900 } }Route order.* to the fulfillment service, payment.* to billing, and user.* to notification — using glob patterns. Add a new consumer by adding a route, no publisher changes needed.
POST /v1/routes
{ "event_type_pattern": "order.*", "destination_id": "dest_fulfillment" }
{ "event_type_pattern": "payment.*", "destination_id": "dest_billing" }
{ "event_type_pattern": "*", "destination_id": "dest_audit_log" }If Fulfillment fails, GetHook retries Fulfillment. If Billing fails, GetHook retries Billing. Each destination has its own retry schedule — a failing consumer doesn't affect other consumers.
GET /v1/events/{id}
# Shows per-destination delivery status:
# fulfillment: delivered (attempt 1)
# billing: retrying (attempt 2)
# audit_log: delivered (attempt 1)Publishers post an event and return. They don't know who the consumers are, how many there are, or whether they succeeded.
Add a new consumer by adding a route. The publisher never changes. New consumers start receiving all future events instantly.
Each destination retries independently. A failing notification service doesn't prevent fulfillment from receiving the event.
GetHook's Postgres-backed queue provides durable, concurrent event delivery. No additional infrastructure to provision or operate.
Events are persisted before the 200 OK is returned to the publisher. They cannot be lost by a consumer failure or network issue.
Events that exhaust all retry attempts go to dead-letter status. They can be replayed individually or in bulk after a consumer bug is fixed.
Webhook events are the nervous system of modern AI agents. GetHook ensures every trigger — document uploads, user messages, tool responses — reaches your agent reliably, with replay for debugging.
Every webhook event is a data point. GetHook persists all events durably and fans out to your data warehouse, BI tool, and streaming pipeline simultaneously — with replay for backfills.
GitHub push events, PR webhooks, and deployment notifications routed reliably to your CI/CD system — with automatic retry if Jenkins, ArgoCD, or your deploy service is temporarily unavailable.
Up and running in minutes. No credit card required. Connect your first source and see events flowing in real time.