Reliable async delivery. Zero queue infrastructure.

Webhook delivery is inherently unreliable — endpoints go down, networks fail, and services restart. The only honest delivery guarantee is at-least-once: every event will be delivered at least once, retried until acknowledged, and persisted so it cannot be lost even if the delivery infrastructure restarts.

When an event is enqueued for delivery, it is durably persisted before any delivery attempt. If delivery fails — the endpoint returned a 5xx, timed out, or was unreachable — the event remains in the queue and retries according to the configured retry schedule. It stays in the queue until it receives a 2xx acknowledgement or exhausts all retry attempts.

At-least-once delivery has an important consequence: your webhook handlers must be idempotent — processing the same event twice must produce the same outcome as processing it once. Every event includes a stable event ID that your handler can use to deduplicate retries. Apitide provides tooling to inspect event IDs and understand which deliveries are retry attempts.

A spike in event volume — a flash sale, a batch import, a downstream service catching up after an outage — can overwhelm webhook endpoints that are not designed for burst traffic. Without throttling, the delivery infrastructure amplifies the spike: every queued event attempts delivery simultaneously, turning a manageable backlog into a traffic storm.

Apitide's per-endpoint throttling caps the delivery rate to each endpoint regardless of queue depth. Configure deliveries per second, per minute, or per hour — the delivery system paces itself to stay within the limit while working through the queue. Burst capacity allows short-term spikes above the steady-state limit without triggering throttling for single-request bursts.

Priority queues let you designate some event types as high-priority. High-priority events are delivered ahead of standard events regardless of queue order — payment confirmations and fraud alerts move ahead of analytics events and audit logs when the queue is congested. Priority is configurable per event type, not just per endpoint.

Webhook endpoints are publicly reachable URLs. Without signature verification, any actor on the internet can POST fabricated events to your endpoint and trigger your business logic — cancelling subscriptions, marking orders as paid, triggering fulfilment for non-existent orders.

Apitide generates an HMAC-SHA256 signature for every outbound webhook using an endpoint-specific signing secret. The receiving endpoint verifies the signature by computing the HMAC over the raw request bytes using the same secret and comparing the result to the signature header. If they match, the event is genuine. If they don't, reject it before processing.

Verification is over raw bytes — not parsed JSON — because JSON parsers can reorder keys or strip whitespace, changing the byte representation and causing legitimate events to fail verification. Apitide's verification tooling handles this correctly. Replay attack protection is built in via a timestamp in the signature payload: events signed more than five minutes ago are rejected, preventing captured signatures from being replayed hours later.