Native 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 ticket

GET/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"

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.

Listing eventsThe catalog endpoint in full.Inventory & seat holdsHold lifetimes and the oversell guard.Any backendSigning samples for every stack.Embedding the webviewThe hosted alternative, for comparison.