DEV Community: mmiura

Designing Webhook Retries: Schedules, Jitter, Idempotency and Auto-Disabling Endpoints

mmiura — Mon, 05 Oct 2026 13:17:16 +0000

Retrying webhooks comes down to four decisions: when to try again, when to give up, how the receiver tells a retry from a new event, and when to stop sending to an endpoint that's gone. We go through each one with the policies Stripe, Shopify, GitHub and Svix publish.

Retrying webhooks comes down to four decisions: when to try again, when to give up, how the receiver tells a retry from a new event, and when to stop sending to an endpoint that is clearly gone. This post walks through each one with the policies real providers publish, the code you need if you build it yourself, and how Webhook Admin handles it.

How popular providers retry

All of these were checked against the official docs on 2026-09-27.

Provider	Retries	Response timeout	Signature header
Stripe	Exponential backoff for up to 3 days (live mode); 3 times over a few hours in sandboxes	Not stated	`Stripe-Signature` (HMAC-SHA256)
Shopify	Up to 8 times over 4 hours, then the subscription is removed	5 seconds	`X-Shopify-Hmac-SHA256`
GitHub	No automatic retries; redeliver manually or via the API	10 seconds	`X-Hub-Signature-256` (HMAC-SHA256)
Svix	Immediately, 5s, 5m, 30m, 2h, 5h, 10h, 10h	15 seconds	`webhook-signature` (Standard Webhooks)

Sources: Stripe, Shopify retries, Shopify signatures, GitHub failed deliveries, GitHub signatures, Svix

The retry window ranges from zero (GitHub) to about 4 hours (Shopify) to about 28 hours (Svix) to 3 days (Stripe). Four hours covers a bad deploy on the receiver's side but not a weekend outage. Three days covers the weekend, at the cost of a burst of stale events when the receiver comes back. Pick the window first, then fit the intervals into it.

If you build this yourself, you will probably start with your job queue's built-in retry: SQS visibility timeouts, Cloud Tasks, Sidekiq, BullMQ. That handles "the worker crashed, run the job again." It does not track failures per endpoint, stop sending to dead endpoints, or show your support team what happened to a delivery. Those parts are on you.

Backoff and when to give up

Exponential backoff

Start with short intervals and lengthen them as failures continue. Most transient failures (a dropped connection, a pod restart) clear within seconds. An endpoint that has been down for an hour will not recover faster because you hit it every minute.

const BASE_MS = 5_000;          // first retry delay
const CAP_MS = 10 * 3600_000;   // cap a single delay at 10 hours
const MAX_ATTEMPTS = 8;         // including the first attempt

/** Delay after `attempts` failures, or null to give up */
export function backoffMs(attempts: number): number | null {
  if (attempts >= MAX_ATTEMPTS) return null;
  const exp = Math.min(CAP_MS, BASE_MS * 2 ** (attempts - 1));
  return Math.floor(Math.random() * exp); // full jitter
}

Jitter

The Math.random() is the jitter. Without it, the 1,000 deliveries that failed during a receiver's outage are all retried at the same moment, right as the receiver comes back up. Picking a random delay between zero and the backoff value spreads them out. This is the "Full Jitter" strategy from the AWS Architecture Blog post Exponential Backoff And Jitter (2015): random(0, min(cap, base * 2 ** attempt)).

Limiting how many requests you send to each endpoint at once solves the same thundering-herd problem from a different angle. More on that below.

After the last attempt

Keep the failed event and mark it as failed, so it can be replayed by hand. Stripe lets you resend from the Dashboard and the CLI. A "replay everything that failed since 14:00" action saves a lot of back-and-forth with customers after an incident on their side.

Timeouts and what counts as success

Timeout: 5 to 15 seconds is typical (Shopify 5, GitHub 10, Svix 15). A long timeout lets one slow endpoint tie up your workers.
Success: only 2xx. Treat 3xx as a failure and don't follow redirects; following them means sending to a URL you never validated.
Response body: store the first 1 KB or so. It is enough to see the receiver's error message without bloating your logs.

export async function sendOnce(url: string, headers: Record<string, string>, body: string) {
  const started = Date.now();
  try {
    const res = await fetch(url, {
      method: 'POST',
      headers,
      body,
      redirect: 'manual',
      signal: AbortSignal.timeout(15_000),
    });
    const head = (await res.text()).slice(0, 1024);
    return { ok: res.status >= 200 && res.status < 300, status: res.status, head, ms: Date.now() - started };
  } catch (e) {
    return { ok: false, status: null, head: null, ms: Date.now() - started, error: String(e) };
  }
}

Idempotency and webhook-id

Retries mean the receiver will sometimes get the same event twice. If the receiver finishes its work but the response is lost on the way back, the sender sees a failure and retries. Delivery is at-least-once, and deduplication happens on the receiving side.

To make that possible, give every event a unique ID and send the same ID on every retry. Standard Webhooks puts it in the webhook-id header. The timestamp (webhook-timestamp) and the signature are regenerated for each attempt; the ID never changes.

Your receiver docs should then tell customers three things: store the ID under a unique constraint and skip events already seen, return 2xx for duplicates too (a 4xx makes the sender retry again), and return 2xx before doing slow work. A handler that calls three external APIs before responding will hit the timeout, get marked as failed, and receive a retry for work it already did. Handling duplicate webhooks has receiver code for this.

Ordering isn't guaranteed either. With retries in play, "created → deleted → updated" can arrive in that order, so put the object ID in the payload and let receivers re-fetch state (Out-of-order webhooks).

Stopping endpoints that keep failing

A churned customer's URL or an expired domain will never succeed, and every retry to it holds a worker until the timeout. Handle this in two stages:

Pause briefly (circuit breaker): after several consecutive failures to the same endpoint, stop sending for a few seconds, then let one request through to probe. This keeps one slow endpoint from delaying deliveries to everyone else.
Disable: after failures have continued for days, disable the endpoint and notify someone. Svix disables after 5 days.

Make the disable visible to both the team that sends and the customer who owns the endpoint. Otherwise you find out when the customer asks why they stopped getting events three weeks ago.

How Webhook Admin handles retries

These are the values in Webhook Admin's code as of 2026-09-27. The table below is the default retry schedule; you can choose the number of retries and the interval per endpoint, as long as the last retry comes within 3 days of the first send.

Attempt	Delay since previous attempt	Time since first attempt
1	immediate	0
2	5 seconds	5 s
3	5 minutes	~5 min
4	30 minutes	~35 min
5	2 hours	~2 h 35 min
6	5 hours	~7 h 35 min
7	10 hours	~17 h 35 min
8	10 hours	~27 h 35 min

The default schedule is the same one Svix uses, with no jitter. Instead, each endpoint gets at most 10 concurrent requests by default, and after 5 consecutive failures Webhook Admin stops sending to it for 30 seconds, then lets one request through. Deliveries waiting for a slot stay in the queue.
Responses time out after 15 seconds. Only 2xx counts as success. Redirects aren't followed, and 410 is retried like any other failure. The first 1,024 bytes of each response are logged.
Signatures follow Standard Webhooks (webhook-id, webhook-timestamp, webhook-signature with v1 HMAC-SHA256). webhook-id stays the same across retries; timestamp and signature are regenerated per attempt. After a secret rotation, both old and new signatures are sent for 24 hours.
An endpoint that has been failing for 5 days is disabled automatically. Alerts go to Slack, Teams, Chatwork, email or a webhook when failures have lasted an hour, when retries run out and when an endpoint is disabled, at most once an hour per endpoint.
Failed deliveries can be replayed from the dashboard or the API.

When you send through the API, add an Idempotency-Key so a retry on your side doesn't create a second message. The same key returns the same message ID for 24 hours.

curl -X POST https://api.webhookadmin.com/v1/messages \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: invoice-2026-0927-001" \
  -d '{"consumer":"customer_123","event_type":"invoice.paid","payload":{"invoice_id":"inv_001","amount":12000}}'

Checklist

Retry window and intervals (exponential backoff with jitter, or per-endpoint concurrency limits)
Success rule (2xx only, no redirects) and timeout
An event ID that survives retries, plus receiver docs that say "dedupe on the ID" and "return 2xx first"
Storage for failed events and a way to replay them
Circuit breaking, auto-disabling and alerts for endpoints that keep failing

If you'd rather not build and maintain retries, delivery logs, auto-disabling and failure alerts yourself, Webhook Admin is free up to 50,000 messages a month: https://app.webhookadmin.com/signup

Quick FAQ

Should webhook retries use jitter?

With plain exponential backoff, yes. Without it, every delivery that failed during a receiver's outage is retried at the same moment. A per-endpoint concurrency limit solves the same problem from the sender side.

Which responses should count as delivered?

Only 2xx. Treat 3xx as a failure and don't follow redirects, because following them sends the payload to a URL you never validated.

What should happen after the last retry?

Keep the event marked as failed so someone can replay it, and disable endpoints that have failed for days, notifying both your team and the endpoint's owner.

Thanks for reading! What retry schedule do you use for outgoing webhooks, and how did you pick it? We'd love to hear in the comments.

This post first appeared on the Webhook Admin blog.

Webhook Delivery Services Compared: Svix, Hookdeck Outpost, Convoy, Hook0, DIY and Webhook Admin

mmiura — Tue, 29 Sep 2026 13:17:50 +0000

Comparing webhook delivery services is harder than it should be, because every pricing page is laid out differently. We compared Svix, Hookdeck Outpost, Convoy, Hook0, building it yourself and our own product on price, free tier, static IPs and self-hosting, using each vendor's own pages.

This is a comparison for teams deciding whether to build outbound webhooks themselves or hand them to a service. It covers Svix, Hookdeck Outpost, Convoy, Hook0, building it yourself, and Webhook Admin. Every price and feature below comes from the vendor's own pricing page or docs as of 2026-09-27. Where a page doesn't say, the table says "not stated."

We run Webhook Admin, so we have a stake in this. We've tried to say plainly where another option is the better fit.

What these services do

The core is the same everywhere:

An API to publish an event once and have it delivered to every subscribed endpoint
Retries with backoff, plus manual replay of failed deliveries
HMAC-SHA256 signatures
Searchable delivery logs
Endpoint management per customer, with event-type filtering

The differences are in how usage is metered, which plan includes static IPs, whether you can self-host, and whether you get a customer-facing portal.

Pricing and key limits

	Free tier	First paid plan	Log retention	Static source IPs	Self-hosting	Currency
Svix	50k messages / mo	Basic from $20 / mo (50k included, then $0.0001 / msg)	Free 7 d / Basic 30 d / Professional 90 d	Professional (from $490 / mo) and Enterprise	Yes (svix-webhooks, MIT; README notes some hosted features aren't in the repo)	USD
Hookdeck Outpost	Managed: first 50k events free	Starter: $10 per million events	Starter 7 d / Growth 30 d	Add-on on every managed plan ("+ $100")	Yes (Apache 2.0)	USD
Convoy	Community (self-hosted): $0	Premium (self-hosted): $999 / mo	Not stated	Via a forward proxy you run (mole)	Yes (Elastic License 2.0)	USD
Hook0	100 events / day	Startup €59 / mo (30k events / day, excl. VAT)	Developer 7 d / Startup 14 d / Pro 30 d	Pro (€190 / mo) "on demand", Enterprise	Yes (SSPL)	EUR
Webhook Admin	50k messages / mo, 1 project	Starter $20 / mo (500k messages, 3 projects)	Free 7 d / Starter 30 d / Pro and Business 90 d	Starter and up	On request (Enterprise)	USD, JPY

Sources (all checked 2026-09-27):

Svix: pricing, source IPs, svix-webhooks
Hookdeck: Outpost pricing, Outpost overview, Event Gateway pricing
Convoy: pricing, static IP guide, license
Hook0: pricing
Webhook Admin: pricing

The options one by one

Svix

The best-known dedicated webhook sending service. It publishes its retry schedule (immediately, 5s, 5m, 30m, 2h, 5h, 10h, 10h) and disables endpoints after 5 days of continuous failure (Svix retries); Webhook Admin uses the same schedule and the same 5-day rule. Retries aren't billed, and each 64 KiB of payload counts as one message.

Static source IPs start at Professional (from $490 a month). The IPs are published per region, and Svix commits to keeping them stable for existing customers. Enterprise adds on-prem deployment, including FIPS 140-3.

Good fit: strict procurement or compliance requirements, or you need an on-prem deployment.

Hookdeck Outpost

Hookdeck's sending product. (Hookdeck Event Gateway is their receiving product, with separate pricing.) Outpost is open source under Apache 2.0 and delivers to HTTP webhooks as well as SQS, Kinesis, S3, Pub/Sub, Azure Service Bus, RabbitMQ and Kafka. Managed usage is $10 per million events, which gets very cheap at volume.

Static IPs are an add-on on every managed plan, listed as "+ $100" (the page doesn't say whether that is monthly).

Good fit: your customers want events in queues and streams, not just HTTP endpoints, or you want the same open-source engine self-hosted and managed.

Convoy

An open-source gateway that handles both incoming and outgoing webhooks. The pricing page lists self-hosted plans: Community at $0 and Premium at $999 a month, which adds portal links, circuit breaking, role-based access control and more. The license is Elastic License 2.0.

For static IPs, Convoy's guide has you run a forward proxy (mole, a wrapper around Smokescreen) in front of it.

Good fit: you want everything in your own infrastructure, sending and receiving in one system, and you have people to operate it.

Hook0

A European service billed in EUR, metered per day rather than per month. The free Developer plan allows 100 events a day. The self-hosted edition is free under the SSPL. Static IPs are "on demand" on Pro, with no price listed.

Good fit: you're in Europe and want EUR billing, or SSPL works for your self-hosting plans.

Build it yourself

With one or two endpoints and modest volume, putting the HTTP call on your job queue's retry (SQS, Cloud Tasks, Sidekiq, BullMQ) is enough. In the Hacker News thread below, one commenter says they run billions of webhooks this way on Sidekiq.

What tends to come later: a UI to find a specific delivery, replay for failed events, auto-disabling and alerts for dead endpoints, secret rotation, SSRF protection, and static IPs. In that thread, "How do you handle production webhook delivery reliability in your apps?" (June 2025), the original poster describes a buggy retry path that delayed payment processing for hours (Hacker News).

Good fit: few endpoints, no need for logs or a UI, or data that can't leave your infrastructure.

Webhook Admin

Built for companies that send webhooks from several products and want them in one dashboard, organized by project.

Static source IP from the Starter plan: deliveries go out from one fixed IPv4 address.
Failure alerts to Slack, Microsoft Teams, email, a webhook or Chatwork when failures last an hour, when retries run out, and when an endpoint is disabled.
An embeddable portal where your customers manage their own endpoints, from Starter up.
Standard Webhooks signatures, so receivers can verify with existing libraries.
An MCP server, so AI agents can register endpoints and replay deliveries.
Overage is $2.00 per 100k messages, and retries aren't billed.

On the Enterprise plan, self-hosting in your own environment is available on request, priced per contract. Webhook Admin only delivers to HTTP endpoints; it doesn't push to queues the way Outpost does. For an on-prem deployment on your own servers, Svix Enterprise is the better fit.

Cost example: 500k messages a month with static IPs

Say one customer requires an IP allowlist and you send 500,000 messages a month. Using list prices only (no tax, no negotiated discounts):

	Calculation	Per month
Svix	Professional from $490 + 450k × $0.0001	from $535
Hookdeck Outpost (managed)	450k × $10 / 1M + $100 static IP (assumed monthly)	~$104.50
Hook0	Pro €190 + static IP (price not listed)	€190 + static IP
Convoy	Community $0 + your servers, database and proxy	depends on your infra
Webhook Admin	Starter (up to 500k)	$20

Without the static IP requirement, Svix drops to Basic (from $20 plus $45 overage) and Outpost to about $4.50. At higher volumes Outpost's metering pulls ahead: 10 million messages a month is about $100 on Outpost versus $299 on Webhook Admin Pro ($199 for 5 million, plus $2.00 per 100,000 over).

How to choose

On-prem or heavy compliance requirements: Svix Enterprise.
Destinations beyond HTTP, or an open-source engine you can also buy managed: Hookdeck Outpost.
Self-hosted, sending and receiving in one system: Convoy.
A handful of endpoints and no need for logs or a UI: build it on your job queue.
Customers with IP allowlists on a small budget, or many projects you want in one dashboard: Webhook Admin.

You can try Webhook Admin on the Free plan with 50,000 messages a month. The static IP is available from the Starter plan ($20 / mo): https://app.webhookadmin.com/signup

Quick FAQ

Which service is cheapest?

Without a static IP, Hookdeck Outpost's managed plan is cheapest at volume ($10 per million events). If a receiver requires a static source IP, Webhook Admin Starter ($20 a month for 500,000 messages) is the lowest list price in this comparison.

Can I self-host?

Svix (svix-webhooks), Hookdeck Outpost, Convoy and Hook0 all have self-hostable versions under different licenses. Webhook Admin is a hosted service; on the Enterprise plan, self-hosting in your own environment is available on request.

Are retries billed?

Svix and Webhook Admin don't bill retries. Svix also counts each 64 KiB of payload as one message, so check each pricing page for how size is metered.

Thanks for reading! What mattered most when you picked a webhook service, or decided to build your own? We'd love to hear in the comments.

This post first appeared on the Webhook Admin blog.

Sending Webhooks from a Static IP: NAT Gateways, Proxies and Relays

mmiura — Mon, 28 Sep 2026 07:28:54 +0000

"Can you give us a list of IPs to allowlist?" If you send webhooks to B2B customers, you've probably seen this one. We get asked it a lot at Webhook Admin, so here's how the options compare.

Sooner or later a customer's security team asks: "Which IP addresses will your webhooks come from? We need to allowlist them." If your app runs on serverless functions, containers or a PaaS, the honest answer is "it changes," because outbound IPs move with deploys and scaling. This post covers three ways to send from fixed addresses, what each costs, and how IP allowlisting fits alongside signatures.

Why customers ask for it

Some companies filter inbound traffic by source IP as a matter of policy, especially for systems inside a corporate network. Telling them "we sign every request, so you don't need an allowlist" often doesn't get past the firewall team.

Providers have taken different positions. Stripe publishes 15 webhook source IPs, with text and JSON lists, and announces changes 7 days in advance on a mailing list (Stripe). Svix publishes static source IPs per region and commits to not changing them for existing customers, but only on its Professional and Enterprise tiers (Svix). KOMOJU lists its source IPs but notes they can change without notice and recommends verifying signatures instead of filtering by IP (KOMOJU). For a fuller table of what each provider publishes, see Webhook IP allowlisting.

Option 1: NAT gateway

Run the sending workers in a private subnet and route outbound traffic through a NAT gateway with an Elastic IP. Every request leaves from that address.

AWS pricing in us-east-1, checked on 2026-09-27:

Item	Price	Per month (730 h)
NAT gateway	$0.045 / hour	~$32.85
NAT data processing	$0.045 / GB	depends on traffic
Public IPv4 address	$0.005 / hour	~$3.65

Two gateways for redundancy, each with its own IP, come to about $73 a month before data processing and transfer. Prices vary by region.

Sources: Amazon VPC pricing, AWS Price List API

This fits if your workers already run in a VPC. It doesn't help if you send from Vercel, Cloudflare Workers or another platform outside your VPC.

Option 2: forward proxy

Run an HTTP CONNECT proxy on a host with a static IP and route only webhook traffic through it. On the app side it's one setting on the HTTP client.

import { ProxyAgent, fetch } from 'undici';

const proxy = new ProxyAgent(process.env.WEBHOOK_PROXY_URL!); // e.g. http://user:pass@proxy.internal:4750

await fetch(endpointUrl, {
  method: 'POST',
  headers,
  body,
  dispatcher: proxy,
  redirect: 'manual',
  signal: AbortSignal.timeout(15_000),
});

Stripe's open-source Smokescreen is a common choice. Convoy documents exactly this setup with mole, its wrapper around Smokescreen, and suggests putting several proxies behind a load balancer to scale (Convoy).

You pay for the hosts and the IPs, and you own redundancy, patching, and the SSRF checks described below.

Option 3: relay service

Your app asks a relay "send this body to this URL," and the relay sends it from its static IP and returns the result. Unlike a forward proxy, the relay understands the request, so it can validate destinations, enforce timeouts and record responses itself.

Fly.io supports app-scoped static egress IPs. fly ips allocate-egress --app <app> -r <region> allocates an IPv4/IPv6 pair in a region, and each IPv4 costs $3.60 a month. The addresses survive machine replacement and redeploys (Fly.io docs).

A minimal relay authenticates your app with a shared-secret HMAC and rejects stale requests:

import { createHmac, timingSafeEqual } from 'node:crypto';
import http from 'node:http';

const SECRET = process.env.APP_SHARED_SECRET!;

http.createServer(async (req, res) => {
  const ts = String(req.headers['x-app-timestamp'] ?? '');
  const sig = String(req.headers['x-app-signature'] ?? '');
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return res.writeHead(401).end();

  const chunks: Buffer[] = [];
  for await (const c of req) chunks.push(c as Buffer);
  const raw = Buffer.concat(chunks).toString('utf8');

  const expected = createHmac('sha256', SECRET).update(`${ts}.${raw}`).digest('base64');
  if (sig.length !== expected.length || !timingSafeEqual(Buffer.from(sig), Buffer.from(expected))) {
    return res.writeHead(401).end();
  }

  const { url, headers, body } = JSON.parse(raw);
  // validate the destination here (next section), then send
  const r = await fetch(url, { method: 'POST', headers, body, redirect: 'manual', signal: AbortSignal.timeout(15_000) });
  res.writeHead(200, { 'content-type': 'application/json' }).end(JSON.stringify({ status: r.status }));
}).listen(8080);

SSRF checks you can't skip

A static-IP sender is, by design, trusted by your customers' firewalls. It also sends to URLs your users type in. If someone registers a URL that resolves to an internal address, that trusted box will happily POST into your own network or your cloud's metadata service.

Put these checks in the proxy or relay:

At registration: HTTPS only, standard ports only, no raw IP addresses in the URL, no internal hostnames such as .internal or .local.
At send time: resolve the hostname and refuse if any returned address is private (10/8, 172.16/12, 192.168/16), loopback, link-local (169.254/16, which includes cloud metadata endpoints), CGNAT (100.64/10), or an IPv6 ULA or link-local address.
Connect to the IP you just checked. Resolving again lets a DNS rebinding attack return a safe address to the check and an internal one to the connection. Keep SNI and certificate validation on the original hostname.
Don't follow redirects.

Pair the allowlist with signatures

An IP allowlist narrows which network paths can reach the endpoint, but it says nothing about who sent the request or whether the body was changed. Receivers should still verify the signature on every delivery (why allowlisting doesn't replace signatures).

Send customers the signature details together with the IP list. If you sign with Standard Webhooks, they can verify with an existing library in their language.

Publishing your IPs is fine

Source IP addresses aren't secrets. An HTTPS request needs a completed TCP handshake before any data flows, so an attacker can't spoof your source address and get a full request through. Knowing your IPs doesn't let anyone impersonate you. That's why Stripe publishes its list.

When you publish:

Put the list in two places: your docs and your dashboard. A machine-readable JSON file lets customers automate firewall updates.
Announce changes in advance: Stripe gives 7 days.
Ask customers to allow every address from day one: if you run more than one sender for redundancy, a customer who allowed only one will see failures when traffic moves.

How Webhook Admin does it

In Webhook Admin, sending from a static IP is a per-endpoint setting, available from the Starter plan ($20/mo).

Deliveries to that endpoint come from one IPv4 address, 209.71.107.233, which is also shown in the dashboard and the docs.
Right before each send, the hostname is resolved again and every returned address is checked; if any of them is internal, nothing is sent. Redirects are not followed. Because the source is IPv4, the destination needs an A record.
Signing (Standard Webhooks), retries and delivery logs work the same as for other endpoints. Each attempt in the log shows the IP it was sent from.

Create an endpoint with fixed_ip set:

curl -X POST https://api.webhookadmin.com/v1/endpoints \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"consumer_id":"con_...","url":"https://partner.example.com/webhooks","fixed_ip":true}'

Which setup to pick

Setup	Rough monthly cost	Good fit when
NAT gateway (AWS us-east-1, two AZs)	~$73 + data	Your senders already run in a VPC
Forward proxy (self-hosted)	hosts + IPs	You want to add a proxy to an existing HTTP client and keep everything else
Relay (Fly.io or similar)	$3.60 per IPv4 + machines	You send from serverless and want destination checks and logging in one place
A delivery service's static IP	depends on the plan	You want redundancy and SSRF protection handled for you

If a customer's firewall is the only reason you're about to build and run a relay, Webhook Admin gives you a static source IP from the Starter plan ($20/mo): https://app.webhookadmin.com/signup

Quick FAQ

Is it safe to publish my webhook source IPs?
Yes. Source IPs aren't secrets, and an attacker can't complete a TCP handshake from a spoofed address, so knowing the IPs doesn't let anyone impersonate you.

Do I still need signatures if the customer allowlists my IP?
Yes. An IP match only shows which network the request came from. The signature shows who sent it and that the body wasn't changed.

Why does the destination need an IPv4 address?
If you send from a single static IPv4 address, the connection has to go over IPv4, so a destination with only an AAAA record can't be reached.

Thanks for reading! How do you handle IP allowlist requests on your side? We'd love to hear in the comments.

This post first appeared on the Webhook Admin blog.