Getting started with the travel.tech API

travel.tech is BizAway's traveler-facing REST API for searching and booking
flights, stays, cars, and trains. This guide walks you through making your
first authenticated request against the /v1 surface.

Prerequisites

• A BizAway tenant with API access enabled.
• A registered consumer with a signing secret (see
  Authentication).
• A traveler bearer token for the person you are acting on behalf of,
  issued by BizAway sign-in (see
  Authentication § Obtaining a token).
• The travel.tech API base URL. Production is https://api.travel.tech
  (export it as TRAVELTECH_BASE_URL for the examples in these guides).
  Reach out to your BizAway integration contact if you do not yet have
  credentials or need a non-production host.
• A REST client (curl, HTTPie, Bruno, Postman, or your language's HTTP
  library of choice).

API versioning

All endpoints documented in the API Reference
are versioned under /v1. New versions, when introduced, are published
under /v2 without breaking /v1. See
Errors for the compatibility
policy.

Authentication

Every request is authenticated on two axes:

1. Consumer HMAC (primary) — a signature that identifies your client
   application, sent as the TravelTech-Consumer, TravelTech-Timestamp, and
   TravelTech-Signature headers.
2. Bearer token — the traveler's identity JWT in the Authorization
   header.

The full signing algorithm, worked examples in bash/Python/TypeScript, secret
rotation, and troubleshooting live in the
Authentication guide. A minimal signed request looks
like this:

curl "$TRAVELTECH_BASE_URL/v1/profile" \
  -H "TravelTech-Consumer: $CONSUMER" \
  -H "TravelTech-Timestamp: $TIMESTAMP" \
  -H "TravelTech-Signature: $SIGNATURE" \
  -H "Authorization: Bearer $TRAVELER_JWT"

If the consumer signature is missing or invalid, the API returns 401 with a
CONSUMER_AUTH_REQUIRED error envelope. If the bearer token is missing,
expired, or invalid, it returns 401 with the standard error envelope.

Your first request

Fetch the authenticated traveler's profile (a GET, so the signed body hash is
the SHA-256 of the empty string). See
Authentication for how CONSUMER, TIMESTAMP, and
SIGNATURE are computed.

curl

curl "$TRAVELTECH_BASE_URL/v1/profile" \
  -H "TravelTech-Consumer: $CONSUMER" \
  -H "TravelTech-Timestamp: $TIMESTAMP" \
  -H "TravelTech-Signature: $SIGNATURE" \
  -H "Authorization: Bearer $TRAVELER_JWT"

Python

import httpx

response = httpx.get(
    f"{TRAVELTECH_BASE_URL}/v1/profile",
    headers={
        "TravelTech-Consumer": CONSUMER,
        "TravelTech-Timestamp": TIMESTAMP,
        "TravelTech-Signature": SIGNATURE,
        "Authorization": f"Bearer {TRAVELER_JWT}",
    },
)
profile = response.json()

TypeScript

const response = await fetch(`${TRAVELTECH_BASE_URL}/v1/profile`, {
  headers: {
    "TravelTech-Consumer": CONSUMER,
    "TravelTech-Timestamp": TIMESTAMP,
    "TravelTech-Signature": SIGNATURE,
    Authorization: `Bearer ${TRAVELER_JWT}`,
  },
});
const profile = await response.json();

A successful response returns the traveler's profile record as JSON — see
Managing traveler profiles for the full field
reference:

{
  "id": "018f2c1e-9b3a-7c44-8b2e-1a2b3c4d5e6f",
  "userId": "018f2c1e-9b3a-7c44-8b2e-1a2b3c4d5e6f",
  "accountId": "018f2c1e-9b3a-7c44-8b2e-1a2b3c4d5e6f",
  "email": "[email protected]",
  "firstName": "Ada",
  "lastName": "Lovelace",
  "preferences": {
    "language": "en",
    "currency": "EUR",
    "cabinClass": "economy",
    "seatPreference": "aisle",
    "mealPreference": null,
    "notificationsEnabled": true,
    "preferredAirlines": ["BA"],
    "preferredStayChains": [],
    "dietaryRestrictions": [],
    "allergies": [],
    "preferredTrainCarriers": []
  },
  "insights": {
    "bookingCount": 12,
    "avgLeadTimeDays": 18.5,
    "topSegmentType": "flight"
  },
  "loyaltyPrograms": [
    { "program": "BA_EXECUTIVE_CLUB", "membershipNumber": "1234567890", "tier": "Gold" }
  ]
}

The booking flow at a glance

Every travel vertical follows the same four-step shape:

1. Search — POST /v1/{vertical}/search streams normalised solutions back
   as Server-Sent Events.
2. List fares — POST /v1/{vertical}/fares streams the bookable fares for a
   chosen solution.
3. Build fare — POST /v1/{vertical}/fares/build locks a specific fare and
   returns a fareId.
4. Book — POST /v1/{vertical}/bookings creates the booking from the built
   fareId.

What's next

See What you can build with travel.tech for outcome-oriented
guides into quickstart, authentication, core concepts, and each vertical.

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.