Skip to content

Inbound webhook ingestion with replay

Point Stripe, GitHub, Shopify or any sender at an Eventeer listener. Every event is accepted, deduplicated and stored, so a deploy or an outage on your side never loses data.

Get startedRead the API docs

The problem

Webhooks are fire-and-forget from the sender's side. Stripe, GitHub and Shopify will retry for a while, but if your service is down for a deploy, a migration or a bad release, events can fall off the end of their retry schedule. You then reconcile by hand, if you can.

Running your own queue in front of the app fixes that, and it also becomes another service to patch, scale and monitor. You need an endpoint that is always up, a place to put the payload, deduplication for senders that retry aggressively, and a way to look at what arrived last Tuesday.

Many teams also want the same event in more than one place: the billing service, the analytics pipeline, a Slack notifier. Asking each provider to configure three endpoints is rarely possible, and building a fan-out layer is a project of its own.

How Eventeer handles it

  • A URL per source

    Each listener has an unguessable URL. It accepts JSON, plain text and form bodies up to 256 KB, and answers 202 once the event is stored.

  • Idempotent by design

    Send an Idempotency-Key and retries from the provider collapse into one event. The duplicate response tells the sender it was already received.

  • Pick your auth

    Run a listener anonymous, with a bearer token, or with HMAC signatures. A signed request cannot be replayed inside the 300-second window.

  • Keep and browse everything

    Events are stored for 7, 30 or 90 days depending on plan. Filter the explorer by listener, device, source, time range or a JSON payload fragment.

  • Replay and fan out

    Replay a stored event to a destination from the explorer, or attach several destinations so one inbound event reaches every service that needs it.

An inbound webhook queue that is always accepting

Eventeer sits between the sender and your code. The sender gets a fast acknowledgement from the listener. Your service then consumes events when it is ready: through a stream over WebSocket, or through a destination that posts to your endpoint.

Replaying failed events

Destinations deliver at-least-once: 8 attempts with backoff over roughly 24 hours, with a delivery log per destination. When your service was down for longer than that, a dead delivery can be retried manually, and any stored event can be replayed to a destination from the event explorer. Your handler should dedupe on the event id or the X-Eventeer-Event-Id header.

Signed in both directions

Outbound deliveries carry an X-Eventeer-Signature header with HMAC-SHA256 over the timestamp and body, so your endpoint can prove the request came from Eventeer. The free signature verifier shows how the scheme works.

What it looks like

A listener is one URL. This sketch creates a signed listener, posts an event with an idempotency key and reads it back through the REST API.

Create a listener, send an event, read it back
# 1. Create a listener that only accepts signed requests
curl -X POST https://app.eventeer.io/api/v1/listeners \
  -H "Authorization: Bearer $EVENTEER_KEY" -H "Content-Type: application/json" \
  -d '{"name":"stripe","type":"webhook","auth_mode":"hmac"}'

# 2. A sender posts an event; the Idempotency-Key makes retries safe
curl -X POST https://app.eventeer.io/in/w/lst_… \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: evt_1PqXyz" \
  -H "X-Eventeer-Signature: t=1761930000,v1=5257a869…" \
  -d '{"type":"order.created","amount":42.5}'

# 3. Fetch what arrived, newest first
curl "https://app.eventeer.io/api/v1/events?listener=lst_…&limit=20" \
  -H "Authorization: Bearer $EVENTEER_KEY"

Questions

What happens if the same webhook arrives twice?
If the request carries an Idempotency-Key header, Eventeer answers the repeat with 200 and duplicate: true and stores nothing new. Keys are deduplicated per listener for the retention period. Without the header, every request is stored as its own event.
Can I verify signatures from Stripe or GitHub?
A listener in HMAC mode checks the X-Eventeer-Signature scheme (HMAC-SHA256 over timestamp and raw body, 300-second window). Providers that sign differently are best served by a token listener or the anonymous unguessable URL, and your own service can still verify the provider signature on replay.
How long are events kept, and how big can they be?
Events are kept for your plan's retention: 7 days on Starter, 30 on Growth, 90 on Scale. A request body can be up to 256 KB of JSON, text or form data.

Related

Stop losing webhooks to downtime

Create a listener, point your first provider at it, and keep every event until your retention window ends.

Get startedLog in