Outbound Gateway: send webhooks to your customers

The Outbound Gateway sends webhooks from your product to your customers. Your backend publishes each event once. Webhook Relay signs it, delivers it to every endpoint your customer subscribed, retries failures for up to 48 hours, paces each endpoint and records every attempt so you can inspect, retry or replay deliveries later.

You don't need your own queue, retry worker, signing code or delivery log. Your customers verify standard signatures and receive each message at least once.

How it works

1. You describe your events. Register event types such as invoice.paid.
2. You register each customer. Create a consumer for each customer using your own customer ID, then add the HTTPS endpoint URLs they give you. Each endpoint gets its own signing secret.
3. You publish. When an event happens, publish a message for one consumer and event type. The API answers 202 Accepted with a durable receipt.
4. Webhook Relay delivers. Each subscribed endpoint receives a signed POST. Failed attempts are retried on a backoff schedule. Endpoint health, attempts and responses are recorded.

Vocabulary

What you get

• Signed deliveries. Standard Webhooks headers (webhook-id, webhook-timestamp, webhook-signature) with a separate secret for each endpoint, plus a 24-hour overlap when you rotate a secret.
• Retries. Up to eight attempts within 48 hours, honoring Retry-After on 429 and 503 responses.
• Isolation and pacing. Each endpoint has its own rate limit (50 deliveries per second by default) and concurrency limit, so one slow customer never holds up another.
• Health tracking. Endpoints become failing after repeated errors. Optionally, they can be disabled automatically after a long outage. Failures are tracked on the endpoint; they never open incidents or send emails to your account.
• History and recovery. For 35 days, you can view every delivery attempt with its response, retry a delivery, re-send failed deliveries or replay messages skipped while an endpoint was paused.
• Payload Functions. Attach a Function to an endpoint to reshape the JSON body for a specific customer or to drop messages.
• Every surface. The REST API, the TypeScript and Go SDKs, the dashboard and MCP tools (and therefore the dashboard agent) all support the same operations.

Early access

The Outbound Gateway is in early access. To turn it on, open the Outbound webhooks page in the dashboard and click Request to enable. This opens a support ticket, and we reply there when the feature is enabled for your account. Until then, the page shows the SDK examples so you can prepare your integration.

Outbound messages do not count toward your plan's inbound webhook quota.

Why use Webhook Relay

Sending webhooks looks like one HTTP request and is really a small distributed system. A single POST is trivial; sending every event to every customer, correctly, for years, is not. Once you commit to delivering webhooks, you have signed up to own all of this:

• Durable storage between publish and delivery. If your API publishes and returns, the message has to survive a restart, a deploy, an OOM kill and a database failover before the customer's endpoint accepts it. That means a queue or an outbox table, plus a worker, plus a way to replay what the worker drops.
• A retry schedule that respects the receiver. The first attempt fails on a deploy, a 5xx, a slow database, a rate limit. You need increasing backoff, a deadline, and Retry-After handling — then the judgement to stop retrying an endpoint that is gone forever.
• Per-endpoint isolation. One customer with a broken endpoint must not delay anyone else's events. That means per-endpoint rate limits, concurrency limits and a health state machine, not one shared worker racing through a global queue.
• Signing and safe rotation. Every customer needs their own secret, a signature scheme their SDK already verifies, and a rotation path that never drops a delivery mid-roll.
• Observability and recovery. When a customer says "we missed an event," you need to show them the attempt, its response and its status — then resend one delivery, re-send the failures in bulk, or replay what was skipped while their endpoint was paused.
• Delivery from wherever your code runs. The same publish call has to work from a cron job, an API handler, a background worker and an AI agent, without each one re-implementing the client.

That is a queue, a retry engine, a signer, a rate limiter, a health tracker, a delivery log, a recovery pipeline and several clients — a project that is easy to start and expensive to keep correct. The bugs are quiet: a dropped message during a deploy, a retry storm against a customer who is already down, a signature that fails only during key rotation.

The Outbound Gateway is that system, hosted. You register event types, consumers and endpoints once, then call publish — one method — from any of your services. Webhook Relay owns the queue, retries, per-endpoint pacing, health, signing, history and recovery, and hands your customers Standard Webhooks signatures their existing libraries can verify. You keep the product logic that decides what happened; Webhook Relay handles getting it there.

Next steps

• Set up the Outbound Gateway: create a token, event types, a consumer and an endpoint, then publish your first message.
• Receive and verify outbound webhooks: what your customers' endpoints receive and how to verify signatures.
• Monitor, retry and recover deliveries: delivery history, endpoint health, recovery, Functions and limits.