Skip to main content

What you’ll build

A webhook handler that receives signed payment events from Request Network, verifies the signature, and triggers your downstream systems β€” order fulfillment, invoice closeout, accounting entries, customer email. Polling-free, idempotent, retry-safe. Audience: any backend integrating Request Network where payment events drive state changes downstream.

The 14 events

secure_payment.user_event is best-effort browser telemetry, and the stream is intentionally incomplete: the payer’s browser can fail to reach the API, and retries begin only once the API has accepted the event. A missing event is not evidence that the payer skipped the step, so do not drive drop-off, notification, or reconciliation logic off its absence. For the full payload schemas, see the Webhooks reference.

Setup

1

Get a Client ID

Complete steps 1–3 of the Quickstart. Note your clientId.
2

Register your webhook URL

POST https://auth.request.network/v1/webhook with header x-client-id: <yours> and body { "url": "https://yourapp.com/webhooks/request-network" }.Save the returned secret immediately β€” it’s only shown once.
3

Test delivery

Fire a test event from the auth API docs with body { "eventType": "payment.confirmed" }. The request will arrive with header x-request-network-test: true.

Handler β€” reference implementation

A signature-verifying Express handler. It verifies against the raw body, uses constant-time comparison, passes the delivery ID to business handlers as their idempotency key, and lets Request Network retry a failed handler.
Webhook delivery is at least once, not exactly once. Each business operation must atomically record the delivery ID with the state it changes, then make a repeat delivery a successful no-op. If an operation calls another service, pass the delivery ID as that service’s idempotency key too. A process can fail after a side effect but before it returns 200.

Headers reference

Retry policy

After 4 total attempts (initial + 3 retries) the delivery is dropped. Triggers: any non-2xx response, timeout, connection error. Default request timeout is 5s.

Common patterns

Idempotency

The same payment.confirmed event might arrive twice (network blip, retry overlap). Use x-request-network-delivery as the idempotency key. Record it atomically with the business update in your durable store; do not use a check-then-act cache lookup, because overlapping deliveries can both pass the check. For a local database update, add a webhook_deliveries table with a unique delivery_id column, then insert that ID in the same transaction as the business update:

Routing by Client ID

If your platform has many merchants, give each their own Client ID. The webhook payload includes clientId so you can route events to the right tenant.

Slack alerts on failure

Crypto-to-fiat status tracking

The payment.processing event includes a subStatus field that progresses through initiated β†’ pending_internal_assessment β†’ ongoing_checks β†’ sending_fiat β†’ fiat_sent. Surface this in your UI so the payee sees real-time offramp progress.

Local development

Use ngrok to expose localhost during development:
Local URLs (localhost, 127.0.0.1) are accepted by the auth API for testing. HTTPS is required in production.

Webhooks reference

Full payload schemas for every event type.

Webhooks & Events

High-level concepts and event categories.
Last modified on August 19, 2026