Order Emails
By default, bookingkit sends transactional emails to end customers on behalf of the supplier. Understanding this behaviour — and how it can be adjusted for your integration — is essential for avoiding duplicate emails and designing a consistent customer journey.
Supplier-facing notification emails are never affected by your API client settings. Suppliers will always receive their internal alerts (new orders, changes, cancellations) through bookingkit. These cannot be suppressed.
Default behaviour
When an order is placed or updated through your integration, bookingkit sends the following emails to the end customer:
- Order confirmation — sent immediately after a successful booking
- Order update — sent when an existing order is amended
- Order cancellation — sent when an order is cancelled
- After-sales / reminder emails — automated reminders sent by bookingkit before the event date
Disabling customer email sending
If your integration handles its own customer communication — for example, sending branded confirmation emails or delivering tickets through your own platform — you can request that bookingkit stops sending customer emails to avoid duplicates.
To disable email sending, contact bookingkit. It is configured per API client and per environment, so you can suppress emails in production while keeping them active in sandbox for testing purposes.
To disable customer email sending for your integration, reach out to your bookingkit contact. Please specify whether you'd like this applied to sandbox, production, or both environments.
What gets suppressed
When email sending is disabled for your API client, the following customer emails are suppressed:
| Triggered by | |
|---|---|
| Order confirmation | Successful booking |
| Order update notification | Order amendment |
| Order cancellation notification | Order cancellation |
| After-sales / reminder emails | Automated reminders sent by bookingkit before the event date |
Your integration is then fully responsible for sending these communications to end customers.
What is never suppressed
Supplier-facing notification emails are not affected by your API client settings. Suppliers will always receive their internal alerts (new orders, changes, cancellations) through bookingkit.
Handling ticket delivery
If you disable customer emails, your integration is responsible for ticket delivery. After a booking is confirmed, the API v3 order response includes participant-level ticket codes at:
tickets.participants.*.code
This path applies to the API v3 order response. In API v4, ticket codes are returned at a different path — refer to the API v4 documentation when it becomes available.
These codes can be used to generate:
| Format | Recommendation |
|---|---|
| Barcode | Recommended |
| QR Code | Recommended |
| Text code | Supported |
We recommend providing both a barcode and a QR code to maximise compatibility with venue scanning equipment.
Delivery options
As a partner, you have full freedom to design your ticket delivery experience. Common approaches include:
- Email tickets — send a styled HTML email containing the generated codes
- Physical tickets — print tickets with barcodes/QR codes at point of sale
- Digital wallets — issue Apple Wallet (
.pkpass) or Google Wallet passes - In-app tickets — display codes directly within your app or booking confirmation page