Why Use Webhooks?
| Approach | Pros | Cons |
|---|---|---|
| Polling | Simple to implement | Wastes resources, delayed updates |
| Webhooks | Real-time, efficient | Requires endpoint setup |
Quick Start
1. Create a Webhook Endpoint
Build an HTTP endpoint that accepts POST requests:2. Register the Webhook
3. Verify Signatures
Always verify that webhooks are from Bota. See Signature Verification below.Event Types
| Event | Trigger | Common Use Case |
|---|---|---|
recording.created | Recording entry created | Track new recordings |
recording.uploaded | Audio upload completed | Trigger processing |
recording.deleted | Recording deleted | Clean up cached data |
transcription.started | Transcription begins | Show processing status |
transcription.completed | Transcription finished | Display results to user |
transcription.failed | Transcription failed | Alert, retry, or fallback |
summary.started | Summary generation begins | Show processing status |
summary.completed | Summary generated | Update UI, send notifications |
summary.failed | Summary generation failed | Alert or retry |
Payload Structure
All webhook payloads follow this structure:| Field | Description |
|---|---|
id | Unique event identifier (use for deduplication) |
type | Event type string |
created_at | When the event occurred (ISO 8601) |
data | Event-specific payload |
Signature Verification
All webhooks are signed using HMAC-SHA256. Always verify signatures to ensure requests are from Bota.Signature Header
Verification Code
Retry Policy
Bota retries failed deliveries with exponential backoff:| Attempt | Delay After Failure |
|---|---|
| 1 | Immediate |
| 2 | 1 minute |
| 3 | 5 minutes |
| 4 | 30 minutes |
| 5 | 2 hours |
| 6 | 8 hours |
What Counts as Failure?
- Non-2xx HTTP response
- Request timeout (30 seconds)
- Connection refused
- TLS/SSL errors
Best Practices
Respond quickly (< 5 seconds)
Respond quickly (< 5 seconds)
Return a
200 response immediately, then process the event asynchronously. Long-running processing in the request handler will cause timeouts.Handle duplicates with idempotency
Handle duplicates with idempotency
The same event may be delivered multiple times due to retries. Use the For production, store processed event IDs in a database.
id field to deduplicate:Use HTTPS endpoints only
Use HTTPS endpoints only
Bota only delivers webhooks to HTTPS URLs. HTTP endpoints are rejected for security.
Handle out-of-order delivery
Handle out-of-order delivery
Events may arrive out of order. Don’t assume
recording.uploaded arrives before transcription.completed. Check object state via API if order matters.Log webhook payloads
Log webhook payloads
Log incoming webhooks for debugging. Include the event ID, type, and any processing errors.
Monitor webhook health
Monitor webhook health
Track your webhook success rate. Frequent failures may indicate endpoint issues.
Testing Webhooks
Local Development
Use a tunneling service like ngrok to receive webhooks locally:Trigger Test Events
Create a recording and transcription in test mode to trigger events:Managing Webhooks
List Webhooks
Delete a Webhook
Update Events (Delete and Recreate)
To change which events a webhook receives, delete it and create a new one.Troubleshooting
Not receiving webhooks
Not receiving webhooks
- Verify the webhook is registered:
GET /webhooks - Check that your endpoint is publicly accessible
- Ensure you’re returning 2xx status codes
- Check your server logs for incoming requests
- Verify the events you’re subscribed to match what you expect
Signature verification failing
Signature verification failing
- Ensure you’re using the raw request body, not parsed JSON
- Check that you’re using the correct webhook secret
- Verify you haven’t modified the payload before verification
Duplicate events
Duplicate events
This is expected behavior. Implement idempotency using the event
id field.Events arriving out of order
Events arriving out of order
This is expected. Don’t rely on event ordering. Check resource state via API if needed.

