Build your Webhook Relay with AI in under 5 minutes

Build a Pipedream-style webhook receiver with HMAC-SHA256 signature verification, replay-window protection, body-size caps, multi-vendor signature header support (Stripe / GitHub / generic), and a deliveries dashboard — generated from a single prompt.

Como funciona

Passo 1

Descreva a sua ideia

Escreva um prompt em texto simples descrevendo o que pretende.

Passo 2

A IA cria

O FloopFloop gera código pronto para produção instantaneamente.

Passo 3

Implementar e lançar

O seu projeto é alojado no seu próprio subdomínio em minutos.

Por que criar com IA em vez de contratar um programador?

	FloopFloop	Programador tradicional
Tempo até ao lançamento	Menos de 5 minutos	2 a 8 semanas
Custo	A partir de 0 $	5.000 $ - 50.000 $+
Manutenção	Incluída	Retainer contínuo

What is a webhook relay api?

A webhook relay is the glue that connects systems that emit events to systems that need to act on them, with retries, signature verification, and a viewable history that beats 'check the CloudWatch logs'. Pipedream, n8n, and Zapier dominate the no-code-integrations space; svix and Hookdeck specialise in webhook infrastructure. Building your own relay makes sense for two reasons: you're paying SaaS for what is effectively a thin router (and your volume justifies skipping the per-event tax), or you need security guarantees (HMAC verification, replay protection, body-size caps) that the off-the-shelf tools either hide behind enterprise tiers or implement looser than your compliance team will accept. The shape is simple: receive POST, verify the signature, log it, route to downstream targets with retry-on-failure, expose a delivery dashboard.

Common features

Per-source webhook endpoint with HMAC-SHA256 verification
Replay-window check — rejects timestamps older than N minutes
Body-size cap so a misbehaving sender can't OOM the worker
Per-event log — timestamp, source, payload, verification result
Routing rules — match event type, forward to downstream URL
Retry policy with exponential backoff
Dead-letter queue for events that exhaust retries
Delivery dashboard with filter and search
Replay-from-dashboard — pick a logged event, resend
Per-source rate limiting

Real-world examples

Stripe → CRM relay

Stripe webhooks land on the relay, get verified, get routed to the CRM with retries. Dashboard shows delivery status; failures dead-letter to a Slack alert.

GitHub → Slack with filtering

GitHub webhooks filtered to only push events for a specific repo + branch combo, then forwarded to a Slack channel with custom formatting.

IoT device callback receiver

Devices in the field POST status to the relay endpoint. HMAC verified, body-size capped, replay-protected. Dashboard shows latest status per device.

Why FloopFloop fits webhook relay api projects

Pipedream and Zapier charge per event. For low-volume relays the cost is fine; for anything above hobby-scale the per-event tax stacks up to 'just build it' territory. The real reason to roll your own is security: HMAC verification, replay protection, body-size caps, and the audit log of what arrived when are first-class concerns, not features behind a paywall. FloopFloop ships a relay that fails closed by default (rejects on missing signature, rejects on bad timestamp), logs every event with verification result, and gives you a dashboard you can hand to a compliance reviewer. The downstream routing rules are yours to evolve as the integration set grows.

Experimente estes prompts

Copie qualquer prompt abaixo e cole-o no FloopFloop para começar.

Build a webhook ingest endpoint that authenticates incoming Stripe webhooks. Verify the `stripe-signature` header against the WEBHOOK_SECRET env var with HMAC-SHA256 + a 5-minute replay window. Cap the body at 1MB before JSON.parse. Persist every successful delivery to a `webhook_events` table with the event type, body, and received-at timestamp; the dashboard shows them in reverse-chronological order.

Create a multi-vendor webhook receiver. Accept Stripe (`stripe-signature`), GitHub (`x-hub-signature-256`), and generic (`x-webhook-signature`) header conventions; auto-detect which by header presence and use the matching HMAC algorithm. Per-vendor WEBHOOK_SECRET via separate env vars so a leak of one doesn't compromise the others.

Design a webhook fan-out relay. Single inbound endpoint receives the event, then fans out to 3 configured downstream URLs (your dev environment, your prod environment, your analytics service). Per-destination retry-with-exponential-backoff on 5xx responses. Delivery log shows the outcome of each fan-out leg.

Build a low-friction webhook ingest that's open by default (no signature required) so the operator can wire a sender quickly during local dev, but fails CLOSED in production with a 503 + actionable error message if WEBHOOK_SECRET is unset. Dev mode emits a console.warn on every unsigned delivery so the operator notices before shipping.

Perguntas frequentes

How does signature verification work?

HMAC-SHA256 over the raw request body (or `timestamp.body` when a timestamp header is present, the Stripe convention). Constant-time compare so an attacker can't time-discriminate which byte of the signature was wrong. Three vendor header conventions auto-detected: `x-webhook-signature`, `x-hub-signature-256`, `stripe-signature`.

What stops replay attacks?

When the sender includes a timestamp header (`x-webhook-timestamp` or `stripe-timestamp`), the verifier rejects deliveries with a timestamp older than the replay window (default: 5 minutes). The timestamp is bound into the HMAC payload so an attacker can't just rewrite it. Senders without a timestamp header fall through to body-only HMAC — replay protection requires the timestamp.

Will it fail closed if I forget to set WEBHOOK_SECRET?

Yes in production — the iter-82 hardening landed exactly this fix. With NODE_ENV=production and an unset WEBHOOK_SECRET, the POST handler returns 503 with an actionable error pointing at Project Settings → Secrets. In dev / preview the route still accepts unsigned requests (it's useful while wiring up a sender) but emits a console.warn on every delivery so the operator notices before promoting to production.

How big can a webhook payload be?

Default cap is 1MB, checked via `content-length` header AND a streaming-reader byte count (so a hostile client lying about its length can't slip through). Caps before JSON.parse so a 100MB-of-nested-arrays payload can't burn Lambda memory.

Where do the delivered events get persisted?

The default template inserts every successful delivery into a `webhook_events` table (id, vendor, event_type, body jsonb, received_at). For high-volume webhooks refine with 'partition the table by month + drop partitions older than 90 days via a daily cron'.

Can it fan out to multiple destinations?

Default ships single-destination (just persist). For fan-out refine with 'add a webhook_destinations config table + per-event POST to every active destination URL with retry-on-5xx using exponential backoff (1s, 2s, 4s, 8s, capped at 4 retries)'. Pipedream charges per outbound delivery; FloopFloop's runs on your own Lambda.

How is it different from /api/webhooks/stripe in the FloopFloop monorepo?

That's the receiver for FloopFloop's own Stripe billing webhooks — fixed to Stripe, fixed to the FloopFloop pricing tables. The webhook-relay template is general-purpose: any vendor, any consumer schema, any backing table. Use it for your project's webhook ingest, not for FloopFloop platform events.

Construtores relacionados

Explorar mais categorias

Pronto para criar?

Comece a criar o seu projeto agora — sem necessidade de programação.

Gerar isto para mim