What youโll build
A webhook handler that receives signed 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 or onboarding events drive state changes downstream.Current event catalog
secure_payment.user_event is best-effort browser activity. Its absence does not show that the payer skipped a step, so use payment.confirmed for settlement and reconciliation.
For delivery headers and currently documented payload examples, see the Webhooks reference. For events retained for older API integrations, see Legacy integrations.
Orchestrators: Register and test your endpoint with
x-orchestrator-key in the orchestrator webhook setup. The handler below works for both roles; use the signing secret returned for the endpoint you registered.Set up a platform webhook
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. The business functions in the example are placeholders: replace them with your own durable application logic.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 samepayment.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 you are an orchestrator managing multiple linked platforms, useclientId to identify the platform for each event.
Slack alerts on failure
Local development
Use ngrok to expose localhost during development:localhost, 127.0.0.1) are accepted by the auth API for testing. HTTPS is required in production.
Related
Webhooks reference
Delivery setup, recipient routing, headers, and documented payload examples.
Webhooks & Events
High-level concepts and event categories.