Setup Guide
This guide walks you through setting up webhook subscriptions, handling incoming events, verifying signatures, and managing your event delivery.
Creating a Subscription
Register your endpoint to start receiving events:
Response:
You can optionally provide a custom secret (minimum 24 characters) for signature verification. If not provided, a secure secret is auto-generated.
Handling Incoming Events
Your endpoint receives POST requests with event payloads. Here’s how to handle them:
Respond quickly! Return 200 OK immediately and process the event asynchronously. If your endpoint takes too long (30s timeout), the delivery will be marked as failed and retried.
Signature Verification
Every webhook delivery is signed. Verify signatures to ensure requests actually come from Airweave and haven’t been tampered with.
Get Your Signing Secret
First, retrieve your subscription’s signing secret:
The response includes a secret field in the format whsec_.... Keep this secret secure.
Verify the Signature
Events include three headers for verification:
Recommended: Use the official Svix verification libraries in production. They handle edge cases, timestamp validation, and replay attack prevention automatically.
Managing Subscriptions
List All Subscriptions
Get a Specific Subscription
This also returns recent delivery attempts for debugging.
Update a Subscription
Change the URL, event types, or disable/enable delivery:
Disable a Subscription
Temporarily pause delivery without deleting:
Enable a Subscription
Re-enable a disabled subscription, optionally recovering missed messages:
The recover_since parameter is optional. If provided, Airweave will retry all failed messages from that timestamp.
Delete a Subscription
Permanently remove a subscription:
This action cannot be undone. Pending deliveries will be cancelled.
Retrieving Message History
Get All Messages
Retrieve recent webhook messages sent to your organization:
Filter by Event Type
Get a Specific Message
Include Delivery Attempts
See exactly what happened during delivery:
Recovering Failed Messages
If your endpoint was down or had issues, you can replay failed messages:
This triggers a recovery task that replays failed messages in chronological order.
Best Practices
Respond fast, process async
Return 200 OK immediately after receiving a webhook. Queue the event for background processing rather than doing heavy work inline. This prevents timeouts and ensures reliable delivery.
Implement idempotency
Webhooks may be delivered more than once. Use the event_id or job_id field to deduplicate. Store processed event IDs and skip duplicates.
Always verify signatures in production
Don’t skip signature verification. It protects against:
- Spoofed requests from attackers
- Replay attacks (Svix timestamps help prevent this)
- Data tampering in transit
Use HTTPS endpoints
Webhook URLs must use HTTPS in production. This ensures the payload is encrypted in transit. HTTP is only allowed for local development.
Log everything
Log incoming payloads, processing results, and any errors. This makes debugging much easier when something goes wrong.
Handle all event types gracefully
Even if you only care about sync.completed, your handler should gracefully ignore unknown event types rather than failing.
Sample Application
A complete sample application demonstrating webhook handling, signature verification, and event processing is coming soon.