Warming up the decks…
Warming up the decks…
BlendPartner APIblendapp.aiBefore a buyer can see the Blend checkout inside your app, your server tells Blend who is about to buy. Blend answers with a private, one-time link. Your app opens that link in a webview, and from that moment Blend already knows the buyer's name and email, the checkout never has to ask, and nothing inside the webview can change who is buying.
Keyed call: send x-blend-key and x-blend-secret. Requires the orders.write scope. Rate limit: 60 requests per minute.
This call needs your secret. Your mobile app must never hold it. The app asks your backend for a session, your backend calls Blend, and the app receives only the resulting url.
| Body parameter | Type | Description |
|---|---|---|
| buyerName required | string | The buyer's full name. At most 200 characters. |
| buyerEmail required | string | Where the ticket is emailed. Must be a valid email address. At most 200 characters. |
| buyerPhone | string | Optional. At most 32 characters. |
curl -X POST https://api.blendapp.ai/api/v1/channel/session \
-H "Content-Type: application/json" \
-H "x-blend-key: ck_live_xxxx" \
-H "x-blend-secret: cs_live_xxxx" \
-d '{
"buyerName": "Nour Haddad",
"buyerEmail": "nour@example.com",
"buyerPhone": "+96170123456"
}'{
"success": true,
"data": {
"url": "https://blendapp.ai/channel/session?token=<64 hex characters>",
"expiresAt": "2026-09-04T12:30:00.000Z"
}
}| Response field | Type | Description |
|---|---|---|
| data.url | string | The link to open in the webview. The token query parameter is 32 random bytes encoded as 64 hex characters. It is a single-use handoff. |
| data.expiresAt | string (ISO 8601) | When the session stops working. Sessions live for 30 minutes. |
| Code | Type | Description |
|---|---|---|
| INVALID_BUYER_NAME | 400 | buyerName is missing or longer than 200 characters. |
| INVALID_BUYER_EMAIL | 400 | buyerEmail is missing, not an email address, or longer than 200 characters. |
| INVALID_BUYER_PHONE | 400 | buyerPhone is longer than 32 characters. |
data.url in a webviewOpen it as-is. Do not append parameters and do not reuse it across buyers or launches.
The page sets an httpOnly cookie scoped to /channel and then redirects to your catalog. The token in the URL has done its job.
Checkout, seat holds and order status inside the webview all run against /v1/channel/session/… paths and are authenticated by that cookie, not by a key. Your app never has to inject credentials into the page.
If the buyer is still browsing, mint a new session and reload the webview. Do not try to extend the old one.
Once a session exists, the buyer's name, email and phone come from that server-side session, never from anything the webview sends. When the checkout is submitted, any buyer fields present in the request body are overwritten by the session's values before the order is created.
Even if a script inside the webview rewrites the form, changes the request body, or replays a checkout call, the order is still issued to the buyer your backend named when it created the session. The webview holds no identity to forge.
This is also why the session endpoint is keyed. The only way to say “this buyer” to Blend is with your secret, and your secret lives on your server.
url only. It never sees x-blend-secret.expiresAt: after 30 minutes, mint a fresh session rather than reloading a stale URL.