Stop duplicate webhooks.Let your solo buildersAI agents take their time.

You can. Here's what you're signing up for:

Reliability — Idempotency keys, dead-letter queues, backoff state machines. One missed edge case and you double-process a payment or silently drop an event. Most teams find these bugs in production, at 2 AM.

Security — Every provider signs differently. Stripe HMAC-SHA256 + timestamp, GitHub raw SHA-256, Shopify Base64. You maintain one verifier per provider, handle key rotation, encrypted storage. Skip one = accepting unsigned traffic.

Observability — Debugging means grepping CloudWatch across Lambda invocations. No searchable event log, no replay, no full payload history.

Cost — Infra is $50–200/mo. The real cost is $3,000–5,000/mo in engineer time: on-call, migrations, debugging stuck retries. AnyHook Pro is $20/month and zero maintenance.

→ How delivery works under the hood

Different hops. Stripe's clock runs on the connection to your public URL. Point that at AnyHook and Stripe waits on our edge — which returns 2xx in milliseconds.

The Timeout column is our delivery clock: how long we wait for your endpoint to respond (60s Free, 120s Pro, 5 min Scale). Most endpoints respond well within that. For tasks that take even longer, return 202 Accepted and process async.

→ Retry schedule & timeout details

Zapier/Make are low-code automation platforms — visual editors, drag-and-drop flows. AnyHook is a developer-grade relay: your webhook, your endpoint, your code, your infrastructure.

Writing Python or TypeScript to process webhooks? Use AnyHook. Want "if payment → send email" without code? Use Zapier.

Events are written to a durable queue before we return 200 to the sender. If our Forwarder is temporarily down, events queue up and process on recovery. The sender already got their 200 — no retries, no data loss.

Uptime published at status.anyhook.net.

Yes — that's exactly what AnyHook is for. We acknowledge Stripe in under 50ms. Your Agent runs as long as it needs.

Your endpoint should return 202 Accepted immediately, then process async. AnyHook's delivery timeout (60s Free, 120s Pro, 5 min Scale) only applies to that initial HTTP round-trip.

→ Delivery timeout & retry schedule

No. Return 200 as soon as the webhook is authenticated. Run business logic async. This is Stripe's recommended pattern.

With AnyHook: edge validates signature → event queued → Stripe gets 200 instantly → failures retried and replayed in AnyHook instead of forcing Stripe to redeliver.

AnyHook handles async event webhooks where a fast 2xx is the contract. Not a fit for synchronous control webhooks that need a specific response body:

Twilio Voice (expects TwiML), Discord Interactions (expects JSON UI), Shopify Carrier Shipping (expects live rates). Standard event webhooks from these providers work perfectly.

Your endpoint returns 202 Accepted immediately → processes the task async. AnyHook marks delivery successful on the 202. Your Agent runs for minutes or hours — no impact on the webhook lifecycle.

If your endpoint returns 200 only after the Agent completes, it will trigger retries on long tasks. Fix: 202 + async.

Yes — three ways:

1. Dashboard — click Replay on any event. One click, no re-triggering from Stripe.

2. API single replay — POST /api/v1/events/{id}/replay to replay one event programmatically.

3. Batch recovery — POST /api/v1/apps/{slug}/replay-failed replays all failed events for an app in one call.

Need to inspect first? GET /api/v1/apps/{slug}/events/undelivered lists every event that didn't make it. Replays are tagged is_replay: true and linked to the original event. Replays don't count against your quota.

→ Dashboard replay & API replay

No — and that's intentional. AnyHook classifies HTTP status codes into retryable and terminal:

Retryable (will retry with backoff): 5xx server errors, 408 timeout, 429 rate limited, network errors.

Terminal (marked failed immediately): 400, 401, 403, 404, 422 — any 4xx except 408/429.

Why? A 400 Bad Request or 422 Unprocessable Entity means the payload or auth is wrong — retrying the same request wastes your retry quota and delays the real fix. AnyHook marks it failed immediately so you get notified faster and can fix the root cause.

Failed events are always available for replay once you've fixed the issue.

→ Full retry classification table

AnyHook is a real-time relay — events are forwarded as fast as they arrive. We do not currently apply rate limiting or concurrency caps on outbound delivery.

For most teams this is ideal: you want events delivered immediately, not artificially delayed. If your server can handle the traffic from your webhook source directly, it can handle the same volume through AnyHook.

If your server is sensitive to bursts:

1. Return 429 with a Retry-After header — AnyHook will back off and retry.

2. Use your own queue internally (e.g. accept fast, process async).

Per-destination concurrency limits are on our roadmap — if this is critical for your use case, let us know.

→ Delivery pipeline architecture

Nothing is lost. Here's the sequence:

1. AnyHook keeps retrying on an exponential backoff (5 min → 30 min → 2 h → 12 h).

2. If all retries fail, we email you with the event ID, destination, status code, and a direct link to the event in your dashboard.

3. You also get a circuit breaker alert if 20+ deliveries fail in a row — AnyHook progressively pauses that destination (10 min → 30 min → 2 h → 24 h) to protect your quota. Inbound events keep being received and stored — only outbound delivery pauses.

4. When your server is back: call GET /api/v1/apps/{slug}/events/undelivered to see what you missed, then POST /api/v1/apps/{slug}/replay-failed to catch up. One API call replays everything.

→ Circuit breaker & recovery flow

Encrypted in transit (TLS) and at rest. Retained only for your plan window (3 / 30 / 90 days), then permanently deleted. We never use payload data to train models. Secrets stored encrypted, never exposed in logs.

Pro/Scale: overage billed at $0.90 / 1,000 events. Set a monthly spending cap ($5–$50) in Settings — once reached, events stop until the next cycle. You can also toggle overage per-app so only critical apps keep flowing.

Free: 3,000/mo + 100/day cap. Overages queue for the next cycle — no surprise bills.

→ Overage billing details

Yes — two approaches:

1. Set your destination to a tunnel URL (ngrok, cloudflared, localhost.run). AnyHook forwards webhooks there just like any other endpoint.

2. Even better: let AnyHook capture real production events, then replay them to your localhost whenever you need. No need to trigger events manually — test against real data, unlimited times.

→ Local development guide

Yes — fully. AnyHook works with any HTTP POST webhook, not just the 20+ providers we auto-detect.

For unsupported or custom sources, select "Generic" when creating your App. AnyHook will:

1. Accept and queue every inbound POST — no signature check required.

2. Forward the original headers and body byte-for-byte to your destination.

3. Attach an AnyHook-Signature header (timestamped HMAC-SHA256) so your endpoint can verify the request came through AnyHook.

If your custom source uses HMAC-SHA256, you can configure a signing secret under Generic — AnyHook will verify it at the edge. Otherwise, skip it and let AnyHook act as a secure, logged relay.

→ Edge verification & supported sources

Yes — per-event limits by plan:

Free: 512 KB · Pro: 2 MB · Scale: 5 MB · Enterprise: custom.

Oversized requests get 413 Payload Too Large at the edge — not silently dropped, not queued, not billed. You see the rejection in your event log with full headers for debugging.

These limits cover 99%+ of webhook payloads. Stripe events are typically 2–8 KB. Even AI-heavy payloads (summaries, embeddings) rarely exceed 1 MB. If you need more, Enterprise plans support custom limits.

→ Plan limits & payload specs

Three layers:

1. Original provider headers (Stripe-Signature etc.) forwarded intact — your existing SDK verification works without changes on first delivery.

2. Custom headers (Authorization, x-api-key) attached per-destination. Secrets encrypted at rest.

3. AnyHook-Signature header on every request — timestamped HMAC-SHA256 with a per-destination secret. Recommended for production.

→ AnyHook-Signature verification guide

You can — on the first delivery. But retries will fail.

Provider signatures include a timestamp. Most providers reject signatures older than 5 minutes to prevent replay attacks. AnyHook's retry schedule (5 min → 30 min → 2 h → 12 h) means retries carry the original timestamp from hours ago — your server's signature check will reject them.

AnyHook's solution: we verify the original signature once at the edge, then re-sign every delivery (including retries) with a fresh AnyHook-Signature and current timestamp. Your server checks one header — it never expires, even on the 5th retry.

Trust chain: Provider → AnyHook verifies → AnyHook re-signs → your server verifies AnyHook. You trust AnyHook, AnyHook trusts the provider.