Buy Webhook Inbox.
Capture, verify, and inspect inbound partner webhooks before they hit your core application.
Drop-In Integration Stage
OpenAPI 3.1 & Gateway Compatibleimport hmac, hashlib, json, httpx
# Provider sends to your Webhook Inbox endpoint
endpoint_id = "stripe_billing"
payload = {"type": "invoice.paid", "data": {"id": "inv_01"}}
body = json.dumps(payload).encode()
signature = hmac.new(b"whsec_your_secret", body, hashlib.sha256).hexdigest()
response = httpx.post(
"https://api.youstostore.com/v1/in/" + endpoint_id,
headers={"X-Webhook-Signature": signature},
json={
"payload": payload,
"source_event_id": "evt_stripe_abc123"
}
)
result = response.json() # HTTP 202
print(result["event_id"]) # "wh_01JXYZ"
print(result["status"]) # "accepted"Developer Tier
Growth Tier
RECOMMENDEDEnterprise Tier
Webhook Inbox
**Eyebrow:** Durable inbound webhook intake
Engineering Pain & Fragility
Billing, commerce and developer platforms send business-critical events on their schedule. Your application may be deploying, overloaded or temporarily unavailable at exactly that moment. A direct webhook handler has to authenticate the sender, accept bursts, deduplicate retries, persist payloads safely and preserve enough evidence to recover later — all before it starts the business logic you built the integration for.
Provider retries are not an event-recovery strategy. Retry windows expire, payloads change between attempts, and providers rarely guarantee delivery order. If your handler drops an event during a deploy or a traffic spike, the only recovery path is a manual support ticket asking the provider to resend.
Webhook Inbox isolates the first part of that problem: trustworthy inbound acceptance and retained-event operations. It is deliberately narrower than a workflow automation product or a general outbound webhook platform.
What the API Solves
Point a configured provider webhook at `POST /v1/in/{endpoint_id}`. The current MVP accepts a JSON envelope containing `payload` and an optional `source_event_id`. It verifies an HMAC-SHA256 signature over the exact request bytes, rejects oversized or malformed requests, and creates a deterministic event ID from the tenant, endpoint and source identity.
A new event is acknowledged with HTTP `202` only after its durable receipt has been written. The response includes an `event_id`, `received_at` timestamp and `accepted` status. If the same source identity is received again, the API returns the stable event ID with `duplicate` status rather than creating a second event.
Authenticated management endpoints let your team list compact receipt evidence and queue a retained event for replay. The MVP stores the original request envelope encrypted for that replay path. It does not transform the payload.
How it works. Step by step.
Configure an inbox endpoint.
Associate an endpoint ID with a tenant and source secret in the service deployment.
Send provider events to the ingress URL.
The source posts a JSON envelope to `/v1/in/{endpoint_id}` with `X-Webhook-Signature` computed over the exact bytes.
Verify before acceptance.
Webhook Inbox validates the endpoint format, body size, signature and JSON schema.
Create a stable receipt.
The service uses `source_event_id`, or a request digest when no source ID is supplied, to derive a stable event ID and detect duplicates.
Persist, then acknowledge.
The encrypted payload and receipt metadata are stored before the API returns `202 accepted`.
Inspect operational state.
Call `GET /v1/events`, optionally filtering by `pending`, `delivered` or `dead_letter`, to see IDs, statuses, attempt counts and receipt times.
Queue a replay.
Call `POST /v1/events/{event_id}/replay` with an `Idempotency-Key`. The API returns a stable delivery ID and `queued` status. An optional override must be a public HTTPS URL.
Built for enterprise production standards.
**Persist-before-ack ingress
**Persist-before-ack ingress:** Create the receipt before returning an acceptance response.
**Exact-byte signature verification
**Exact-byte signature verification:** Verify `X-Webhook-Signature` against the incoming body using HMAC-SHA256 in the current adapter.
**Stable duplicate handling
**Stable duplicate handling:** Use a provider source ID when available, with a body-derived fallback, to return a repeatable event ID.
**Encrypted retained payload
**Encrypted retained payload:** Encrypt the stored webhook envelope in the application store; list responses expose metadata, not body content.
**Tenant-scoped management
**Tenant-scoped management:** Authenticate list and replay operations with `X-API-Key` and resolve tenant context server-side.
**Receipt visibility
**Receipt visibility:** List event ID, status, attempt count and receipt time, with optional state filtering.
**Idempotent, guarded replay
**Idempotent, guarded replay:** Require an idempotency key and reject override destinations that are not public HTTPS URLs.
**Bounded ingress
**Bounded ingress:** Cap each event at 512 KiB and validate the JSON envelope strictly.
Ideal use cases & engineering workflows.
Webhook Inbox is for software teams that consume third-party events but do not want inbound durability to become a product of its own:
- SaaS teams receiving billing and subscription events; - commerce applications consuming order, payment or fulfilment notifications; - developer tools reacting to source-control or CI events; - platform teams standardizing webhook ingress across several internal services; - agencies and integration teams that need a recoverable boundary between a provider and customer code.
- Accept Stripe-style billing events while a billing worker is being deployed. - Retain GitHub-style repository events during an application outage. - Buffer Shopify-style commerce notifications before internal processing. - Deduplicate a provider that retries the same source event ID. - Give operators a compact list of pending or dead-letter receipts. - Queue a retained event for replay after a destination recovers.
Why buy instead of building internally?
A durable webhook boundary needs exact-byte signature handling, duplicate identity, persist-before-ack ordering, encrypted storage, tenant separation, safe replay, SSRF defenses and observability without body logs.
Webhook Inbox puts those concerns behind a focused contract. Developers keep destination logic in the application, while operators get stable receipt IDs and a recovery action—without adding a visual workflow system or proprietary transformation language.
Security, privacy and operational integrity.
Ingress signatures are compared using constant-time HMAC comparison in the current implementation. Management API keys are indexed by SHA-256 digest, can be revoked, and map to server-side tenant principals. Cross-tenant event lookup is prevented by tenant-scoped record access in the application layer.
The MVP encrypts the stored request envelope before writing it to the application database. Receipt listings expose only metadata, and request-completion logs omit bodies. Confirm deployment-specific retention, deletion and replay-audit controls before purchase.
The service rejects forged signatures, malformed endpoints, oversized bodies and unsafe destinations. Tests cover encrypted receipts, duplicates, tenant-scoped listing and replay. These properties are not a certification or production SLA.
Architectural Scope & Production Boundaries
Questions & answers for engineering leads.
No. It receives webhooks sent to your application. It is not an outbound customer-webhook service.
Deploy Webhook Inbox in minutes.
Start with our developer tier on Polar.sh Merchant of Record. Automated EU VAT invoices, instant API key generation, and 99.99% edge uptime SLA.