Event detail & tickets

Everything needed to render an event page and start a purchase, in one request.

The catalog list gives you a card. This endpoint gives you the whole event: the ticket types and their prices, optional add-ons, the questions a buyer must answer, the organiser’s branding, and the payment methods that apply. It is the same payload that powers the event page on Blend itself, so what your customer sees in your app matches what they would see on ours.

You can address an event three ways and they all resolve to the same record. Once you have the payload, the next step is to open a buyer session and reserve an order.

Requires the catalog.read scope and the same two headers as every other call; the base URL is https://api.blendapp.ai/api/v1.

The identifier

:id accepts any of the three identifiers you receive on a catalog card. You do not need to tell the API which one you are sending.

Request

curl "https://api.blendapp.ai/api/v1/channel/events/8fK3qLp" \
  -H "x-blend-key: ck_live_xxxxxxxx" \
  -H "x-blend-secret: cs_live_xxxxxxxx"

Response

A successful call returns 200 with the standard envelope and the full event page payload in data. The payload is large by design; the keys below are the ones an integration typically depends on. The list is representative rather than exhaustive, and your code should ignore keys it does not recognise rather than reject the response.

{
  "success": true,
  "code": null,
  "message": null,
  "data": {
    "tickets": [ ... ],
    "addonItems": [ ... ],
    "customQuestions": [ ... ],
    "sponsors": [ ... ],
    "showings": [ ... ],
    "branding": { ... },
    "whishAvailable": ...,
    "blockedPaymentMethods": [ ... ],
    "codOffered": ...,
    "membership": ...,
    "metaPixelIds": [ ... ],
    "organizerId": ...,
    "allowedDomains": [ ... ]
  }
}

Keys you will use

• tickets: the ticket types on sale. This is what you render as the price list and what a buyer chooses from at checkout.
• addonItems: optional extras that can be added to an order alongside tickets.
• customQuestions: questions the organiser requires a buyer to answer before purchase.
• showings: the individual showings or sessions, for events that run more than once.
• branding: the organiser’s presentation settings for the event page.
• sponsors: sponsor entries to display with the event.

Keys that describe how payment works

• whishAvailable: whether Whish is offered for this event.
• codOffered: whether cash on delivery is offered for this event.
• blockedPaymentMethods: payment methods the organiser has switched off for this event.
• membership: membership settings attached to the event.

Other keys present

• organizerId: the organiser that owns the event.
• metaPixelIds: the organiser’s Meta pixel identifiers.
• allowedDomains: domains the organiser has permitted for the event.

Stock is a status, not a number

Blend does not publish sales, stock or capacity figures. Each entry in tickets and addonItems carries three status fields instead, computed on the server:

These replace the earlier remaining count, and the lottery entry count is no longer returned. The server still enforces every limit at checkout, so treat a 409 from Errors as the final word.

Errors

Three outcomes other than success are possible. Each is signalled by the HTTP status and, in the body, by code.

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "success": false,
  "code": "EVENT_NOT_FOUND",
  "message": "Event not found."
}

The general envelope and every other code the API can return are on the Errors page.

Powered by

A hidden event looks exactly like a missing one

Blend hosts events for many organisers and many partners. Your catalog is the subset Blend has granted to you. When you request an event that exists on Blend but is not in your catalog, the API returns a 404 EVENT_NOT_FOUND that is byte-identical to the one for an identifier that has never existed: same status, same headers, same body.

This is deliberate. If a hidden event answered differently from a non-existent one, even by a single character or a few milliseconds of latency in the body, the endpoint could be used as an existence oracle: a script could walk short IDs or guess slugs and build a map of every event on the platform, including ones an organiser has not announced. Making the two cases indistinguishable closes that door for every partner, including you.

# An event that does not exist anywhere on Blend
curl -i "https://api.blendapp.ai/api/v1/channel/events/does-not-exist" \
  -H "x-blend-key: ck_live_xxxxxxxx" \
  -H "x-blend-secret: cs_live_xxxxxxxx"

# A real event that Blend has not added to your catalog
curl -i "https://api.blendapp.ai/api/v1/channel/events/someone-elses-event" \
  -H "x-blend-key: ck_live_xxxxxxxx" \
  -H "x-blend-secret: cs_live_xxxxxxxx"

# Both print the same status line, the same headers and the same body,
# byte for byte. Diff them if you like.

Handling each outcome

1. 200: render the page

   Use tickets for the price list and addonItems for extras. Honour blockedPaymentMethods when you build the payment step.

2. 404 EVENT_NOT_FOUND: forget the event

   It is either gone or was never yours. Drop it from your cache and from any deep link you were about to open. The catalog list will already have stopped returning it.

3. 403 EVENT_CANCELLED: say so

   The event is real and the customer may have heard of it, so a “this event has been cancelled” state is more helpful than a generic error.

4. 403 EVENT_NOT_AVAILABLE: hold

   The event is embargoed. Do not show its details; it will become available when the organiser lifts the embargo, and it will appear in the list at that point.

Next