API Partners: building your own voucher instead of using the Headout URL? The Voucher API deep dive walks through every section of the voucher response — what each field holds, when it is null, and how it renders — so you can reproduce the voucher in your own UI.
Voucher URL — key points
- Acts as the single source of truth
- Shows booking status, ticket state, and experience instructions
- Can be Headout-branded or re-skinned by the partner by masking out the Headout logo and contact details
- Guides users clearly for delayed ticket generation
Default customer communication
By default, Headout sends customer-facing emails directly to the booking’s primary customer using Headout branding — booking confirmation, voucher link, and ticket delivery notifications. If you have your own customer communication flow ready and want Headout to stop sending these emails, this can be disabled on a per-partner basis. Contact your Headout SPOC to opt out. Do not flip this off until your own emails (or other channels) are wired up and tested end-to-end — once opt-out is active, customers will not receive any communication from Headout, so the entire ticket-handoff is your responsibility.Ticket types
How you need to handle ticket types depends entirely on which voucher flow you have implemented:- Using the Headout voucher URL directly — no additional handling needed. All ticket types are rendered correctly out of the box.
- Embedding the Headout voucher in an iframe — no additional handling needed. The voucher renders correctly inside your UI.
- Taking a screenshot of the Headout voucher to generate your own branded PDF — ⚠️ you must handle this carefully. For
PDF_URLandHTML_URLticket types, the Headout voucher renders a download button rather than the ticket inline. A screenshot will only capture the button, not the ticket. You must extract the URL from the API response and handle the download and rendering yourself.
tickets[] once status reaches COMPLETED. Each ticket object includes a type field:
Bookings with no tickets
tickets can be null or []. This isn’t an error, so don’t show the guest a missing-ticket message.
PENDING: tickets are still being generated. Fetch the booking again when the webhook reportsCOMPLETED. See Ticket generation.COMPLETED: the guest follows the redemption instructions. If the instructions include steps to generate or collect tickets, the guest must complete them. If they don’t, no ticket is required and the guest presents the voucher at the venue.
voucherUrl already shows the redemption instructions. If you build your own voucher from the Voucher API, always render instructions, and leave out the tickets section when ticketSection is null.
Multiple tickets per booking
Do not assume one ticket per guest, or one ticket type per booking. Some experiences need more than one code for the same guest. For example, a museum entry ticket with an included audio guide can return:- a
BARCODEticket, scanned at the entrance - a
QRCODEticket, used to unlock the audio guide
publicId identifies a ticket for support and lookup. It is not the code the venue scans, so do not render it as a QR code or barcode. For QRCODE and BARCODE tickets, show the image at url.
API Partners: building your own voucher? The Voucher API returns every ticket with its scannable
ticketCode and the url to render, including the code for TEXT tickets, which have no image.