Webhook Events
This page documents all webhook events sent by the B2A API.For webhook setup and verification, see the Webhooks Guide.
Event Types
| Event | Description | Trigger |
|---|---|---|
booking_confirmed | Booking successfully created | After /execute_booking completes |
voucher_delivered | Voucher email sent | After email delivery confirmed |
qr_verified | User visited venue | When QR scanned at venue |
booking_cancelled | Booking cancelled | On cancellation request |
booking_modified | Booking details changed | On modification |
Common Event Structure
All webhook events follow this structure:| Field | Type | Description |
|---|---|---|
id | string | Unique event identifier (for idempotency) |
event | string | Event type |
api_version | string | API version for payload format |
created_at | string | ISO 8601 timestamp |
data | object | Event-specific payload |
booking_confirmed
Sent immediately after a booking is successfully created.Payload
Use Cases
- Update your booking tracking system
- Trigger confirmation notifications
- Log booking analytics
voucher_delivered
Sent when the voucher email is successfully delivered.Payload
Use Cases
- Confirm voucher delivery to user
- Handle delivery failures (if no event received)
- Track email delivery metrics
Timing
Typically sent within 30 seconds of booking creation.qr_verified
This is the Ground Truth event - the most valuable for improving recommendations.
Payload
Use Cases
- Track conversion from recommendation to visit
- Measure AI agent recommendation quality
- Trigger follow-up engagement (review requests, etc.)
Why This Matters
Theqr_verified event closes the feedback loop, proving that your AI agent’s recommendation led to an actual visit.
booking_cancelled
Sent when a booking is cancelled.Payload
Cancellation Reasons
| Reason | Description |
|---|---|
user_requested | User cancelled via support |
venue_unavailable | Venue closed or unavailable |
weather | Weather-related cancellation |
system | System-initiated cancellation |
Use Cases
- Update booking status in your system
- Offer alternative recommendations
- Track cancellation patterns
booking_modified
Sent when booking details are changed.Payload
Use Cases
- Keep booking records in sync
- Notify users of successful changes
- Track modification patterns
Event Filtering
Configure which events to receive when setting up webhooks:Webhook Delivery
Retry Schedule
| Attempt | Delay |
|---|---|
| 1st retry | 5 seconds |
| 2nd retry | 30 seconds |
| 3rd retry | 2 minutes |
| 4th retry | 10 minutes |
| 5th retry | 1 hour |
Headers
Response Requirements
Return a 2xx status code to acknowledge receipt:Testing Webhooks
Test Endpoint
Send test events to your webhook:Available Test Events
All event types can be tested:booking_confirmedvoucher_deliveredqr_verifiedbooking_cancelledbooking_modified
"test": true in the payload.
Best Practices
Verify signatures
Verify signatures
Always verify the
X-Privetag-Signature header to ensure events are from PriveTag.Handle duplicates
Handle duplicates
Use the event
id for idempotency. Store processed IDs to avoid duplicate handling.Respond quickly
Respond quickly
Return 200 immediately, process asynchronously. Webhook timeout is 30 seconds.
Log everything
Log everything
Log all incoming webhooks for debugging. Include the full payload and your processing result.
Monitor failures
Monitor failures
Set up alerts for webhook delivery failures. Check the webhook logs in your dashboard.