Warming up the decks…
BlendPartner APIblendapp.aiNative UI, no webview
Yes, you can render everything yourself. The same API that powers Blend’s own screens is available to you directly, so if you want events to look like the rest of your app rather than a webview inside it, nothing stops you.
This is the same set of credentials and the same catalog. The only difference is who draws the pixels. You can also mix the two: many partners list events natively, because that is the screen their users browse, and hand off to the webview for checkout, because that is the screen with the seat map and the money in it.
What you get, headless
Every one of these takes your x-blend-key and x-blend-secret and needs no buyer session.
| Endpoint | What it gives you |
|---|---|
| GET /v1/channel/events | Your catalog, paged and filterable. Cards with title, image, venue, date, price from, sold out. |
| GET /v1/channel/events/:id | The full event: ticket types and prices, add-ons, custom questions, branding, showings. |
| GET /v1/channel/events/:id/seats/config | The seat map layout, for events that have one. |
| GET /v1/channel/events/:id/seats/availability | Which seats are free right now. |
| POST /v1/channel/events/:id/seats/hold-token | Opens a hold session for one buyer. |
| POST /v1/channel/events/:id/seats/hold | Holds specific seats, atomically, all or nothing. |
| POST /v1/channel/events/:id/seats/hold/:token/extend | One extension, for a payment attempt. |
| POST /v1/channel/events/:id/seats/release | Gives seats back immediately. |
| POST /v1/channel/events/:id/quote | Server calculated totals: subtotal, discount, fee, VAT, total. |
| POST /v1/channel/events/:id/checkout | Reserves the order and returns an orderId and amount. |
| POST /v1/channel/orders/status | The authoritative amount and paid state. |
| POST /v1/channel/orders/confirm | Signed confirmation once you have taken the money. |
| POST /v1/channel/events/:id/access/validate | Checks an access code for a gated event. |
The flow, natively
Identical to the webview flow, minus the webview. Your backend still makes the calls that carry the secret; your app talks to your backend, never to Blend.
Headless lifecycle
1. Your backend GET /v1/channel/events
-> render your own list screen
2. Your backend GET /v1/channel/events/:id
-> render your own event screen and ticket picker
3. (seated only) POST /v1/channel/events/:id/seats/hold-token
GET /v1/channel/events/:id/seats/availability
POST /v1/channel/events/:id/seats/hold
4. Your backend POST /v1/channel/events/:id/quote
-> show the total Blend calculated, never your own
5. Your backend POST /v1/channel/events/:id/checkout
-> { orderId, amount, currency }
6. Your app charge on your own rail
Your backend POST /v1/channel/orders/confirm (signed)
-> Blend issues the ticketGET/v1/channel/events
curl "https://api.blendapp.ai/api/v1/channel/events?limit=20" \
-H "x-blend-key: ck_live_xxxxxxxxxxxxxxxx" \
-H "x-blend-secret: cs_live_xxxxxxxxxxxxxxxx"Powered by Blend
What you take on
Being honest about the trade, because it is a real one. Going headless means you own these, and each is a place a webview would have been correct for free:
| You now own | Why it matters |
|---|---|
| Price display | Always show the total from /quote. Never add up line items yourself: discounts, fees and VAT are calculated server side and a total you compute will eventually disagree. |
| Sold out states | Your list is a snapshot. A card can go stale between render and tap, so handle the 409s in Errors rather than trusting soldOut. |
| Hold timers | A seat hold shows 600 seconds. If your UI does not count it down, buyers lose seats with no explanation. |
| The seat map | The layout and availability are yours through the API, but drawing an interactive, zoomable seat map that stays correct under contention is the single biggest piece of work here. |
| Custom questions and add-ons | Events can require answers or offer extras. In a webview these render themselves; natively you build each form. |
| Ticket delivery UI | Blend still issues the ticket, emails it and makes the wallet pass. If you want it shown in-app, you render it. |
The hybrid most partners land on
List events natively, because browsing is your app’s look and feel and the catalog endpoint is easy to render. Hand off to the webview at the point the buyer picks a ticket, because that is where the seat map, the questions, the add-ons and the money live, and all of it stays correct without you maintaining it.
You get your own storefront and none of the checkout surface area.
Buyer identity is yours in this mode
With a webview session, Blend takes the buyer name and email from the server-side session and ignores anything the client sends. Headless, there is no session, so the buyer details on /checkout are whatever your backend sends. Send them from your authenticated user record, never from a field the app controls.