Webhooks & Events
Push-based event delivery means you never poll. Every transaction, every policy decision, every budget threshold — delivered to your endpoint the moment it happens.
Event Catalog
Every event Reins fires, with trigger conditions, schemas, and example payloads. Click to expand.
Configuration
From zero to receiving live events in five steps.
In the Reins dashboard, go to Settings → Webhooks → Add Endpoint. Enter your HTTPS URL. HTTP is rejected — all endpoints must use TLS. Your endpoint must return a 2xx within 30 seconds.
Select which events to subscribe to. You can toggle individual events on/off per endpoint. Start with transaction.blocked and budget.exceeded — the highest-signal events.
Reins generates an HMAC-SHA256 signing secret (whsec_...). Store it securely — you'll use it to verify every incoming payload. Never expose it in client-side code.
Click Send Test Event in the dashboard to fire a synthetic payload at your endpoint. Check that your handler returns 200 and logs the event correctly. Use the Payload Builder below to craft custom test events.
The Delivery Logs tab shows every attempt: status code, response time, retry count, and payload preview. Green means delivered. Red means your endpoint returned an error or timed out.
Security
Every webhook includes an X-Reins-Signature header. Verify it before processing.
Replay attack prevention: Each payload includes a X-Reins-Timestamp header (Unix seconds). Reject any payload older than 5 minutes to prevent replay attacks. Compare Math.abs(Date.now()/1000 - timestamp) > 300.
Reliability
6 retry attempts with exponential backoff. Every delivery is logged.
Idempotency: Every event includes a unique id field. Store processed event IDs and skip duplicates. Retries send the same event ID, so your handler must be idempotent.
Try It
Select an event, fill in values, and see the generated webhook payload in real time.
Integration
Full working examples for Python and Node.js. Copy, paste, deploy.
Debugging
Every delivery attempt is logged with status, response time, and payload preview. Inspect failures, replay events, and debug from the dashboard.
| Timestamp | Event | Endpoint | Status | Retries | Latency |
|---|---|---|---|---|---|
| 2026-05-14 14:23:11 | transaction.blocked | https://api.acme.co/webhooks | 200 | 0 | 142ms |
| 2026-05-14 14:21:07 | transaction.approved | https://api.acme.co/webhooks | 200 | 0 | 98ms |
| 2026-05-14 14:18:55 | budget.exceeded | https://hooks.slack.com/abc | 200 | 1 | 210ms |
| 2026-05-14 14:15:33 | alert.triggered | https://api.acme.co/webhooks | 500 | 3 | 30012ms |
| 2026-05-14 14:12:01 | agent.throttled | https://ops.internal/reins | 408 | 2 | 30000ms |
| 2026-05-14 14:09:44 | transaction.approved | https://api.acme.co/webhooks | 200 | 0 | 87ms |
Failed deliveries show a Replay button. Click to re-send the exact same payload with a new delivery ID. All replays are logged separately.
Limits
Plan-level limits for webhook delivery. Enterprise plans are customizable.
| Limit | Value |
|---|---|
| Max webhooks per second | 100 |
| Max payload size | 64 KB |
| Max concurrent connections | 50 |
| Max endpoints per organization | 10 |
| Delivery log retention | 30 days |
| Max retry attempts | 6 |
| Timeout per delivery attempt | 30 seconds |
Best Practices
Ship a reliable webhook consumer with these patterns.
Use idempotency keys. Store processed event IDs. Retries re-send the same ID — skip duplicates to avoid double-processing.
Return 200 immediately. Acknowledge receipt, then process async in a background job. Slow handlers trigger unnecessary retries.
Verify every signature. Never skip HMAC verification, even in development. Unsigned payloads should be rejected with 401.
Monitor response times. If your endpoint consistently takes >5s, you risk timeouts. Offload heavy processing to a queue.
Store raw payloads. Log the original JSON before parsing. When something breaks, you have the exact payload for debugging.
Alert on failures. Set up monitoring on your webhook endpoint. Consecutive 5xx responses mean you are missing events.
Separate endpoints by concern. Use one endpoint for billing events, another for security alerts. Easier to debug and scale independently.
Test before going live. Use the Payload Builder above and the dashboard test-event button. Validate your handler end-to-end with synthetic data.
FAQ
Related