Outbound Gateway: send webhooks to your customers

The Outbound Gateway is Webhook Relay's webhooks-as-a-service: it 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. It is generally available on every plan, Free included. For pricing and a feature tour, see the Outbound Gateway overview; for how it compares with Svix, Hookdeck Outpost, Convoy and Hook0, see the webhooks-as-a-service comparison.

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. You can import an existing secret when a customer moves from another sender.
• 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 5 failed attempts in a row. Optionally, they can be disabled automatically after a long outage. One call (GET /v1/outbound/endpoints?state=failing) or the dashboard's Endpoint health tab lists failing endpoints across all customers. Failures never open incidents or send emails to your account.
• History and recovery. For 35 days, you can view every delivery attempt with its response, filter deliveries by status, event type or message, 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. Access tokens can be restricted to outbound read, publish or manage.

Plans and limits

The Outbound Gateway is generally available and self-serve on every plan, Free included, and on Enterprise. Sign up, then open Outbound webhooks in the dashboard; no support ticket is needed. Business and Pro serve unlimited customers; every plan includes a monthly message allowance.

A message is one accepted publish: fan-out to every subscribed endpoint and retries don't count again, a payload up to 256 KiB is one message, and outbound messages don't count toward your plan's inbound webhook quota. Over the monthly message quota, publishing is refused with 429 until the next billing period, unless you add extra outbound message packs on the plan page: +100,000 messages for $5 a month on Basic, +1,000,000 for $20 on Business and +5,000,000 for $50 on Pro ($54, $216 and $540 a year). Enterprise plans can raise or remove any limit.

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.
• Migrate to the Outbound Gateway: step-by-step guides from Svix, Hookdeck Outpost, Convoy, Hook0 or a homegrown sender that import existing signing secrets where possible, each with a prompt for your coding agent.