Partner APIblendapp.aiHow the integration works
This page is written for whoever has to approve the integration, not only for whoever builds it. No code is required to read it.
The division of responsibility
The simplest way to think about it: you own the customer and the money; Blend owns the inventory and the ticket.
| Concern | Owner | Why |
|---|---|---|
| The app experience | You | It is your app. Blend appears inside it, in your navigation. |
| The buyer relationship | You | You already know who they are; Blend receives only what you send. |
| Taking the payment | You | Your rail, your PCI scope, your settlement. Blend never sees card data. |
| Prices and totals | Blend | Computed server-side so your app and ours can never disagree. |
| Inventory and seats | Blend | One atomic source of truth; overselling is impossible by construction. |
| Ticket issuance | Blend | Signed QR, email, Apple and Google wallet passes. |
| Entry at the venue | Blend | Scanners, door staff, zone readers, capacity reporting. |
What runs where
Almost all of it runs on Blend. Your app opens a webview and Blend serves every screen inside it, so nothing about the buying experience depends on your infrastructure being up, fast, or built for ticketing traffic.
| Runs on | What |
|---|---|
| Blend | The catalog, the event page, the seat map, the checkout form, price and VAT calculation, discount codes, inventory, seat holds, the ticket, the QR, the email, the wallet pass, and the scanners at the door. |
| You | Two HTTP calls, and your own payment sheet. |
The two calls are POST /v1/channel/session before you open the webview, and POST /v1/channel/orders/confirm after you take the money. Neither is a system you have to build, each is one request with a JSON body.
Why those two cannot move to Blend
They are a security floor, not a limitation, and both exist to protect you.
The session call carries your secret, which is what proves a buyer really came from your app. If the app made that call instead, the secret would ship inside an app binary, downloadable, readable, and enough for anyone to open checkouts in your name. Keeping it server-side is what makes the buyer identity in every order trustworthy.
The confirm call reports that your payment rail took the money. Only your systems know that. Blend cannot observe a charge on Toters Pay, so nothing on our side could truthfully make that statement for you.
Everything else you might expect to build, availability polling, price recalculation, seat state, ticket delivery, refund handling at the door, has no counterpart on your side. There is nothing to keep in sync, because you never hold a copy of it.
What your users see
- They tap Events in your app
Your app asks your backend for a Blend session and opens the returned URL in a webview. To the user this is a screen in your app.
- They browse and pick
Blend renders the catalog you agreed, the event page, and the seat map if the event has one. Held seats are shown live and released automatically if they stop.
- They tap Pay
Blend reserves the order, then hands your app the amount to charge. Your own payment sheet opens, your branding, your saved cards, your flow.
- They get a ticket
Your backend tells Blend the charge succeeded. Blend issues the ticket and it appears in the webview immediately, and by email, and in their wallet.
What happens when something goes wrong
Failure handling is where ticketing integrations usually leak money. These are the cases that matter and how each is resolved.
| Case | Outcome |
|---|---|
| Buyer abandons the pay sheet | No charge, no ticket. Seat holds lapse on their own timer and the seats return to sale. |
| You charged, but the confirm call failed | Retry it. Confirm is idempotent, the same order cannot issue two tickets. |
Confirm returns CONFIRM_FAILED | The ticket could not be issued and the response says refundRequired. Refund the buyer; nothing was sold. |
| Two buyers race for the last seat | One wins atomically. The other gets a conflict before being charged. |
| Your confirm arrives late | The webview is still polling. When it lands, the ticket appears. |
| Network dies mid-checkout | Nothing is committed until confirm succeeds. The order simply expires. |
The one rule that protects both sides
Never charge the amount that arrives in the app from the webview. Always re-read the authoritative amount for that order from Blend, server to server, and charge that. The reasoning is in Taking the payment, it is short and it matters.
Powered by
Which events appear
Your catalog is agreed, not scraped. A Blend administrator adds specific events to your channel, and can order them, feature them, or switch one off. Nothing appears to your users that was not explicitly enabled.
This also means you never have to police the catalog. An event that is switched off stops being visible immediately, and its detail endpoint stops answering, see Which events you see.
Going live
Blend issues your credentials by email, a key, a secret, and a signing key for confirmations. They are never published here and never shown in this documentation. Rotation is immediate and does not require a release on your side for the signing key.
What you will receive
x-blend-key ck_live_. identifies your channel (safe to log)
x-blend-secret cs_live_. authenticates your backend (never log, never ship in an app)
signing key csig_live_. signs order confirmations (never log, never ship in an app)Nothing here belongs in your mobile app
The secret and the signing key stay on your servers. Anything shipped inside an app binary should be considered public, apps are downloaded, unpacked and read. Every call that needs those credentials is a backend call in this integration by design.