|
|
Introduction
Use the API to read, create, update and delete supported ExhibitDay records from your internal systems or other software. You will need a working knowledge of REST APIs.
Prerequisite
An API key is required for the data endpoints. Find your workspace's key in ExhibitDay (under Workspace Settings > API & Integrations > API Access). API access must be enabled for the workspace.
Methods and Parameters
The API accepts parameters in a JSON request body, request headers or the query string:
You can combine these locations. For example, send api_key in a header and update parameters in the JSON body. Send each parameter in one location to avoid ambiguity: when the same parameter appears in more than one location, the API reads its header value first.
Documented parameter values are text, numbers, true/false or null. Arrays and objects are rejected with 400 (error_code invalid_request), with two supported array forms: event_tags accepts tag names, and amount_cost_center_breakdown accepts the allocation array described by that parameter. A request body can be at most 10 MB; JSON bodies also have a limit of 1,000 values.
Updating and Clearing Values
When updating a record, send only the parameters you intend to change. Omitted fields are normally preserved, but documented dependent-field rules still apply. For example, moving a task to another event resets its section unless a valid section for the new event is supplied, reversed event dates are swapped, and converting an expense to a credit (or back) clears the previous type's payment details.
Example: remove the due date of task 12345; the empty details value leaves its details unchanged.
curl -X PATCH https://api.exhibitday.com/v1/tasks -H "Content-Type: application/json" -d "{\"api_key\":\"YOUR_API_KEY\", \"id\":\"12345\", \"due_date\":null, \"details\":\"\"}"
Response:
{
"status_code": 200,
"status": "OK",
"message": "Task Update Successful. Task properties that were changed: due_date",
"errors": [],
"warnings": [
"details was empty, so it was left unchanged. To clear it, send null."
]
}
Note: when you add an object (e.g., with a POST call), passing in null is the same as leaving the parameter out.
Empty Values in Responses
When a value is not set, the API returns it as follows:
A few fields don't follow these rules (they stay as they are, so existing integrations keep working):
For the unset response values described above, handle both null and "". When sending an update, keep their different meanings: null clears a supported field, while an empty string leaves it unchanged.
Response Status Codes
Error Codes
API-generated error responses have an error_code (a stable code your integration can check instead of reading the message), error_params (the parameters the errors refer to; [] when the API cannot tell) and a request_id. The API also sends the request id in X-Request-Id; include it when contacting support. New codes may be added, so handle a code you don't know by its HTTP status.
{
"status_code": 400,
"status": "Bad Request",
"message": "Error retrieving event(s)",
"errors": [
"Invalid value for the event_id parameter: abc. The event_id parameter must be the numeric id of an event."
],
"error_code": "invalid_request",
"error_params": [
"event_id"
],
"request_id": "3f2c9a7e4b1d4c8e9f0a1b2c3d4e5f60"
}
Paging and Changed Records
A list returns every matching record unless you ask for a page. On Retrieve Events, Retrieve Tasks, task comments, miscellaneous expenses/credits, event costs and annual expense costs, pass $limit (the most records to return) and $offset (how many to skip). In the response, records_found is the number of records in it, total_records counts every match and has_more is true while more pages follow; the X-Total-Count header carries the total too. In a URL, write $ as %24.
curl "https://api.exhibitday.com/v1/events?%24limit=100&%24offset=0" -H "api_key: YOUR_API_KEY"
To get only what changed, pass filter_by_last_update_timestamp_greater_than_or_equal_to with the latest last-update timestamp you received (on events, tasks, task comments and miscellaneous expenses/credits). Sync Events and Tasks to Another System shows the whole loop.
Retrying Safely and Conditional Requests
Send an Idempotency-Key header (for example a UUID) with a create (POST). Keep the same key, URL, body and parameter headers for each retry of that logical create. Once a successful response is stored, an identical retry within 24 hours returns it with Idempotent-Replayed: true instead of creating another record. Reusing a key for a different request is refused with error_code idempotency_key_reused, and a retry while the first request is still running gets 409 (idempotency_key_in_use). If an earlier request stopped before it finished and its outcome is unknown, a retry gets 409 (idempotency_key_indeterminate) instead of risking a duplicate — check whether that request succeeded, then retry with a new Idempotency-Key.
curl -X POST https://api.exhibitday.com/v1/tasks -H "api_key: YOUR_API_KEY" -H "Idempotency-Key: 5f0c2a8e-7d1b-4c3a-9e6f-2b8d4a1c7e90" -H "Content-Type: application/json" -d "{\"name\":\"Order booth carpet\",\"event_id\":12345}"
Successful GET responses from the data endpoints have an ETag header. Send it back in an If-None-Match header: while the data is unchanged, the API answers 304 Not Modified without a body.
Guides
|