Migrate to the Outbound Gateway

Moving to the Outbound Gateway is a staged cutover, not a big-bang switch. You import your event types, customers and endpoints together with their existing signing secrets, publish every event to both providers for a while, and then switch customers over one at a time. Where the old secret can be imported and the signature scheme already is Standard Webhooks (Svix, Outpost in Standard Webhooks mode), your customers don't change anything. At every stage, rollback is one step back.

The Outbound Gateway is generally available on the Basic, Business and Pro plans. For what it is and how it compares, see the Outbound Gateway overview and the webhooks-as-a-service comparison.

Choose your source

Every Outbound Gateway delivery is signed with Standard Webhooks: webhook-id, webhook-timestamp and webhook-signature (v1, HMAC-SHA256 with a whsec_ secret, one secret per endpoint). Customers whose receivers change need the receiving guide.

Import existing signing secrets

Creating an endpoint accepts an optional secret, so a migrated customer keeps verifying with the key they already have. The secret must be 32 to 100 standard base64 characters (A-Z, a-z, 0-9, +, /, padded or not) that decode to a key of at least 24 bytes. The whsec_ prefix is optional; a secret given without it is stored and returned with it. This is the format Svix and other Standard Webhooks senders issue. Without secret, Webhook Relay generates a new whsec_ secret as usual.

# Read OLD_SECRET from the old provider into the environment. Never echo it.
jq -n --arg url "https://acme.example/webhooks" --arg secret "$OLD_SECRET" \
  '{url: $url, event_types: ["invoice.paid"], secret: $secret}' |
curl -s --user "$RELAY_KEY:$RELAY_SECRET" -X POST \
  https://my.webhookrelay.com/v1/outbound/consumers/customer_42/endpoints \
  -H 'Content-Type: application/json' --data @- | jq '{id, state}'

• Refused: URL-safe base64 (-, _), UUIDs (hyphens), anything shorter than 32 characters, and asymmetric whsk_ / whpk_ keys. The 400 error never echoes the secret. Create those endpoints without secret; they get a new one.
• After import the secret is encrypted at rest, reveal returns it (with the whsec_ prefix), and rotation works the same as for a generated secret.
• Dashboard: the Add endpoint dialog has an optional Existing signing secret field (create only), for migrating a handful of customers without code.
• MCP: create_outbound_endpoint accepts the same secret argument.
• SDKs: the TypeScript and Go SDKs add a secret option to endpoint create in their next release (relay.outbound.endpoints.create(consumer, { url, eventTypes, secret }), Go OutboundEndpointOptions.Secret). Until then, create imported endpoints with the REST call, as the import scripts in each guide do.

A secret that imports only keeps the same key. If the old provider used a different signature scheme (Convoy, Hook0, Outpost's default mode, most homegrown senders), the customer still switches their verification code to Standard Webhooks, but they keep the same secret value in their configuration.

Why move: cheap to start, best to scale

Start for $9.99. At 10 million messages it's still a flat plan. The Outbound Gateway is included in Webhook Relay plans from Basic. There are no per-message fees, retries and fan-out are free, and outbound messages don't count against your inbound webhook quota. You pay for how many customers you serve, not for how many events you send.

Enterprise plans can raise limits up to the platform ceiling of 1,000 consumers, 100 endpoints per consumer and 1,000 event types.

Monthly cost with about 30 days of history. List prices checked on 2026-10-10 from Svix pricing and Hookdeck Outpost pricing:

Svix: $20 Basic / $490 Pro including 50k messages, then $0.0001 per message. Outpost: Starter $0 + $10 per million (7-day retention only), Growth $499 + $10 per million. A 256 KiB payload is one Outbound Gateway message.

Beyond price, each endpoint is its own delivery lane with its own rate limit (50 per second by default), concurrency and retry schedule, so one failing customer never delays another. Every attempt is recorded for 35 days, and you can retry one delivery, re-send failed deliveries or replay skipped ones.

Before you start: what doesn't carry over

• Secrets in other formats. Only Standard Webhooks-format secrets import (see above). Endpoints whose secret doesn't fit get a new whsec_ secret, and those customers update their receiver once.
• Limits. Your plan sets the number of consumers, endpoints per consumer and event types (see the table above). GET /v1/outbound/access returns your effective limits (see Check access and limits).
• No bulk import endpoint. The scripts in each guide create resources one call at a time and can be re-run after a failure.
• Consumer portal. There is no embeddable portal for your customers to manage their own endpoints. Add, update and remove endpoints from your own product with the API.
• Destinations. Endpoints are public HTTPS URLs. Non-HTTP destinations such as SQS or Pub/Sub are not available.
• History. Past messages and attempts stay with the old provider. The Outbound Gateway keeps history from the day you start publishing.

Check access and limits

The Outbound Gateway is included in the Basic, Business and Pro plans. Open Outbound webhooks in the dashboard, then confirm from code. The response includes your account's effective limits:

curl --user "$RELAY_KEY:$RELAY_SECRET" https://my.webhookrelay.com/v1/outbound/access
# {"enabled":true,"limits":{"consumers":100,"endpoints_per_consumer":10,"event_types":300}}

"enabled": false means the account is on the Free plan: upgrade to Basic or above on the billing page. Until then, every other /v1/outbound route returns 403.

Use an access token restricted to Outbound: manage for the import, and a separate Outbound: publish only token for the services that publish. See Create an access token.

The cutover plan

The plan is the same for every source. Each guide fills in the provider-specific calls.

Two rules keep this safe:

• Exactly one provider delivers to a customer at a time. Both providers assign their own message IDs, so a receiver that deduplicates on the message ID can't detect a copy sent by the other provider. If you also put your own event ID in the payload, receivers can deduplicate across providers.
• Don't replay the shadow period. Messages skipped while an endpoint was paused were already delivered by the old provider. Don't call replay-missing for that window when you resume.

Verify with a free Webhook Bin

Before switching anyone, prove that your publish path and your customers' verification work end to end:

1. Create a free Webhook Bin (curl -s -X POST https://bin.webhookrelay.com/v1/bins) and register https://bin.webhookrelay.com/v1/webhooks/<BIN_ID> as an endpoint of a test consumer such as migration-test. Bins are public, so publish test data only.
2. Publish a test event to migration-test and read the captured request back with curl -s https://bin.webhookrelay.com/v1/bins/<BIN_ID>.
3. Paste the headers, body and the endpoint's secret into the Standard Webhooks signature verifier. It must report a valid signature. To prove secret import end to end, create the test endpoint with a test secret in the old provider's format and verify with that secret.
4. During the shadow stage, compare counts per customer and event type: the old provider's delivered messages against GET /v1/outbound/messages?consumer=<id> and the rejected deliveries on each paused endpoint (GET /v1/outbound/endpoints/{id}/deliveries?status=rejected).

Let your agent do it

Every guide ends with a prompt for Claude Code, Cursor, Codex or any coding agent with shell and web access. The prompt points the agent at a machine-readable playbook:

Each playbook lists the exact API calls, the checks to run and what the agent must never do. The agent stops for your approval before stage 4. If you connect the Webhook Relay MCP server, the agent can create consumers and endpoints (including imported secrets) and check deliveries with the outbound MCP tools instead of scripts.

Next steps

• Set up the Outbound Gateway: tokens, event types, consumers, endpoints and publishing.
• Receive and verify outbound webhooks: the page to send customers whose receivers change.
• Monitor, retry and recover deliveries: delivery history, endpoint health, pause and resume.