API Technical Reference

This page covers the technical fundamentals for working with the Open API V2 — authentication, base URL, request/response format, and V2-specific conventions.

Authentication

All endpoints require a valid API key passed in the Authorization header using the Bearer scheme:

Authorization: Bearer your_api_key_here

Requests with a missing or invalid API key are rejected with a 403 Forbidden response. API keys are configured in the ExpoPlatform back-office and are scoped to a specific account.

Base URL

All endpoints are relative to your event's domain:

https://your-event-domain.com/api/v2/

Replace your-event-domain.com with the domain of the specific event you are integrating with.

Request format

POST endpoints accept multipart/form-data, unless otherwise specified. The notifications/send endpoint uses application/json.
GET endpoints accept parameters as URL query string parameters.
DELETE endpoints accept parameters as URL query string parameters.

Response format

All responses follow a consistent JSON envelope:

JSON

{
  "code": 200,
  "errors": null,
  "data": { ... },
  "response_id": "1700000000.12345"
}

Field	Description
`code`	HTTP status code of the response
`errors`	Top-level error message for hard failures; `null` on success
`data`	The response payload. On success this contains the created/updated record or the requested list. On some endpoints it also contains a nested `errors` array for non-fatal field-level issues
`response_id`	A unique identifier for the request, useful for support and debugging

Non-fatal errors: Several endpoints return HTTP 200 even when some fields could not be processed (e.g. an unrecognised country name, an invalid image URL). In these cases, the operation still succeeds and a nested errors or data.errors array describes what was skipped. Always inspect this field in your integration.

V2-specific conventions

IDs come from GET endpoints

Most write operations (POST/DELETE) require internal IDs — for categories, halls, stands, tracks, types, exhibitors, and so on. These IDs must be retrieved from the corresponding GET endpoints before making a write request. Each how-to guide includes a What you'll need before starting table that lists the exact endpoint to call for each required ID.

Upsert behaviour

Several POST endpoints (account/set, exhibitor/set, sessions/set, news/set, product/set) operate as upserts: they create a new record if no match is found, or update an existing one if a match is found. The lookup strategy varies by endpoint and is documented on each reference page.