Versioning

The Easol API uses date-based versioning. Send the version you built against in the Easol-API-Version header:

curl https://api.myeasol.com/bookings/bk_123 \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Easol-API-Version: 2026-11-01"

The header is optional. Use a fully-qualified YYYY-MM-DD date (for example 2026-04-01).

When omitted, requests run against the version your API key is pinned to — not the latest release — so a newly shipped version can't introduce breaking changes to your integration. Send the header to run a single request against a different version — for example, to test a new version before repinning your key.

We release additive changes without creating a new API version. These changes can include new optional fields, new endpoints, or new values for response fields. Clients should allow for response values they do not recognise.

An unknown or unsupported version returns 422 — see Errors.

Endpoint pages do not repeat the version header in their parameter tables, but their code examples and Test panels still include Easol-API-Version so requests are complete.

Changes by version

Each version lists the breaking changes it made.

2026-11-01

• A booking's custom_fields is an array of answers, in the same shape as a guest's. Each answer has custom_field_id, key, type, value and option. Earlier versions return a map of each custom field's key to its value.
• PATCH /bookings/{id} takes custom_fields as an array of answers. Earlier versions take a map of key to value, and also accept an array.

2026-08-01

• Reports and report runs use flat objects, prefixed IDs and the standard list envelope.
• Reporting errors return error.code. Earlier versions return error.id.