Versioning and changelog

What this covers

The compatibility guarantees travel.tech holds within /v1, how a breaking
change is shipped without surprising you, and the dated changelog of changes
made to the /v1 surface.

How it works

Versioning policy

All endpoints are versioned under /v1. Within a version, travel.tech holds
these guarantees:

• Response fields are not removed, renamed, or narrowed in type.
• No new required request field is added.
• Enum values are not removed from a response field.

New optional request fields, new response fields, new enum values on a
response, and entirely new endpoints can land in /v1 at any time — tolerate
fields and enum values you do not recognise rather than rejecting the
response.

A change that cannot be made this way is shipped one of two ways instead of
mutating /v1 out from under you:

1. Deprecate, then remove. The operation or field is marked deprecated
   in the published OpenAPI reference and carries
   an x-sunset date extension — the earliest date it may be removed, always
   at least 90 days out from when the deprecation was announced. It keeps
   working, unchanged, until that date.
2. A new path version. When the change cannot be expressed as
   deprecate-then-remove (a restructured response shape, an incompatible
   request contract), the new behaviour ships under a new path prefix (for
   example /v2) alongside the still-working /v1 endpoint, which is then
   deprecated on its own sunset schedule.

How you learn about a change

• The published reference is the live contract. An operation or field
  that is scheduled for removal shows deprecated: true and its x-sunset
  date directly in the OpenAPI reference —
  check there before you integrate against anything you have not used before.
• The changelog below lists every change made to the /v1 surface,
  dated, in plain language, newest first.

Changelog

Scheduled

These are announced, not yet in effect. The deprecated shape keeps working
until its date.

• 2027-01-31 — GET /v1/human-tasks, GET /v1/human-tasks/{taskId},
  POST /v1/human-tasks/{taskId}/decisions, and
  GET /v1/workflow-runs/{workflowId}/human-tasks will be removed. Migrate to
  GET /v1/tasks, GET /v1/tasks/{taskId}, and
  POST /v1/tasks/{taskId}/decisions, which return the same shape. Responses
  from the old paths already carry Deprecation and Link headers naming the
  replacement.
• 2026-11-30 — the top-level timezone field on
  GET /v1/trips/{tripId}/segments/{segmentId}/realtime will be removed; read
  departureAt.timezone instead (see
  Bookings and trips).
• 2026-11-30 — accountId on GET /v1/profile will be removed; use
  userId, which carries the same value. (accountId on
  GET /v1/profile/identity, GET /v1/profile/policy, and GET /v1/me is a
  different, unrelated field — your account's identifier, not a deprecated
  alias — and is not affected by this change.)

Recent changes

• 2026-10-08 — the train change-of-date/change-of-itinerary request
  body's operationType on POST /v1/trains/bookings/{bookingId}/operation-quotes and .../operations now
  also accepts change_itinerary alongside change_datetime; every request
  that was valid before is still valid.
• 2026-09-18 — GET /v1/profile/colleagues now returns null for an
  entry's email when the colleague has none on file, instead of requiring a
  string.
• 2026-08-07 — POST /v1/auth/login, POST /v1/auth/login/otp-initiate,
  and POST /v1/auth/otp were removed without a deprecation window (a live
  authentication-bypass fix). travel.tech does not issue bearer tokens itself;
  travelers authenticate through BizAway sign-in, and your integration
  presents the resulting token (see Authentication).

Update process

The BizAway integration team adds an entry to this page for every change made
to the /v1 surface, before the change ships:

• A deprecation or a new path version gets its changelog entry in the
  same change that adds the deprecated flag and x-sunset date (or the new
  path) to the reference — so the entry, the sunset date, and the live spec
  are never out of sync.
• An additive change (new endpoint, new optional field, new response
  enum value) gets its entry once the change is live.

What you need to handle

• Tolerate unknown fields and enum values on any response — additive
  changes do not bump the version and are not individually announced ahead of
  time.
• Do not branch on /v1 never changing. Read the
  OpenAPI reference for deprecated and
  x-sunset on anything your integration depends on, and watch this page for
  new entries.
• A deprecated operation or field keeps working exactly as documented until
  its x-sunset date. You do not need to migrate immediately, but migrate
  before that date — the deprecated shape is removed on or after it, not
  before.

Related guides

• Errors — the error envelope and recovery
  actions.
• Pagination — the current paging styles, which a
  planned clean-up (noted on that page) is expected to unify in a future
  change announced here.
• Getting started — the API base URL and your first
  signed request.

Reporting issues

This page is maintained by the BizAway integration team. To request changes or
report an error, contact your BizAway integration contact. Edits made directly
in the ReadMe dashboard are overwritten on the next publish.