Webhook Delivery - My Crypto Server

My Crypto Server uses Inngest for durable webhook delivery. Each outbound delivery is a separate Inngest step — if your server is down or returns an error, Inngest retries with backoff automatically.

Delivery flow

session.paid event
       │
       ▼
  webhookDeliver (Inngest function)
       │
       ├── POST to endpoint URL
       │         │
       │         ├── 2xx → delivered ✓
       │         │
       │         └── non-2xx / timeout → retry (up to 6 attempts)
       │
       └── all retries exhausted → delivery marked failed

Retry schedule

Inngest retries with exponential backoff. 6 attempts span approximately 31 hours total.

Attempt	Approximate delay
1	Immediate
2	~30 seconds
3	~5 minutes
4	~30 minutes
5	~3 hours
6	~12 hours

One function per delivery

Each (event, endpoint) pair is a separate Inngest function invocation. If you have 3 webhook endpoints subscribed to session.paid, a single payment spawns 3 independent webhookDeliver runs. A failure on one endpoint doesn’t affect delivery to the others.

Delivery headers

Every POST includes:

Content-Type: application/json
X-Webhook-Signature: t=<unix_timestamp>,v1=<hmac_hex>
X-Webhook-Timestamp: <unix_timestamp>
X-Webhook-Event-Id: <event_uuid>

Always verify the signature. See Webhooks → Verifying signatures.

Timeout

Your server must respond within 30 seconds. If it doesn’t, the delivery is counted as failed and retried.

Manual replay

From the dashboard under Webhooks → Deliveries, you can see every delivery attempt and replay any of them — including successful ones. This is useful for:

Replaying a delivery your handler accidentally acknowledged without processing.
Replaying events after you fix a bug in your webhook handler.
Debugging delivery failures.

Viewing delivery history via API

GET /api/v1/events

The Events API shows all events and their delivery status. For delivery-level detail (per-endpoint status codes), use the dashboard.

Event deduplication

Your webhook handler may receive the same event more than once (e.g. if your server returned a 200 but Inngest didn’t receive the response). Always make your handler idempotent — use the event.id field to deduplicate:

const processed = new Set<string>();

app.post("/webhooks/crypto", async (req, res) => {
  const event = verifyWebhook({ ... });

  if (processed.has(event.id)) {
    return res.json({ received: true }); // already handled
  }

  await handleEvent(event);
  processed.add(event.id);
  res.json({ received: true });
});

In production, store processed IDs in a database rather than an in-memory set.

​Delivery flow

​Retry schedule

​One function per delivery

​Delivery headers

​Timeout

​Manual replay

​Viewing delivery history via API

​Event deduplication