B2B hotel API for travel businesses

What the API covers

The hotel flow follows the order a booking really happens in: search a destination, request live availability for a hotel, check out the chosen option (the price is re-validated with the supplier at this point), pay, confirm, and later list, retrieve or cancel bookings. Prices returned already include the markup configured for your agency.

The same API key also works for private transfers, including hourly chauffeur service, and for car rental. You integrate one authentication scheme, one error format and one usage log for all three products.

BASE="https://api.trekko.co/core"
AUTH="Authorization: ApiKey trk_test_xxxxxxxx:your_secret_here"

# 1) Search for the city
curl -sS "${BASE}/accommodation/search?query=Barcelona" -H "${AUTH}"

# 2) Live availability (prices already include your markup)
curl -sS -X POST "${BASE}/accommodations/get_accommodation_availability" \
  -H "${AUTH}" -H "Content-Type: application/json" \
  -d '{
        "accommodation_id": 1376114,
        "start_date": "2027-04-12",
        "end_date": "2027-04-15",
        "guests": [ { "id": 1, "age": 34 }, { "id": 2, "age": 30 } ],
        "guests_room_distribution": [ { "guest_ids": [1, 2] } ],
        "nationality": "ES",
        "currency_code": "EUR"
      }'

Built for production traffic

Booking APIs fail in expensive ways: a timeout during confirmation can create a duplicate reservation. The confirmation call accepts an Idempotency-Key header, so a retry with the same key returns the original response instead of booking twice.

Rate limits are applied per API key rather than per IP address, and each agency's limits are independent, so another partner's traffic never throttles yours. Errors share one envelope, and authentication errors follow the usual split between unknown credentials and valid credentials without permission.

Webhooks and automatic rebooking

Bookings made through the API are eligible for Trekko's automatic rebooking: while free cancellation is still open, the booking is checked every day for a lower rate on the same stay. When a rebooking happens, your booking keeps the same stable identifier, and your system receives a signed booking.rebooked webhook with the old and new price and the saving.

Webhooks are signed with HMAC so you can verify they come from Trekko, and delivery is at least once with automatic retries; each event carries an identifier you can deduplicate on. You can also opt out of rebooking for any individual booking through the API.

Sandbox first, live when you are funded

Sign up for the sandbox with your email, confirm the code we send, and you receive test credentials straight away. The sandbox runs the full booking loop on a fixed test catalogue, never calls a real supplier and never moves money, and it includes a rebooking simulator so you can test the webhook flow on demand.

Going live does not require a separate payment integration. You fund your Trekko account up to the minimum deposit by card top-up, bank transfer or an agreed credit line, then activate production to receive your live key. Code written against the sandbox runs in production by changing the key and base URL.

An integration checklist

Store the stable booking identifier returned at confirmation, not the supplier's confirmation number, which can change after a rebooking. Send an Idempotency-Key on every confirmation. Verify the signature on every webhook before acting on it, and deduplicate on the event identifier. Show your users the cancellation deadline returned with each offer.

Who integrates the Trekko API

Online travel agencies adding hotels to their own sites, tour operators feeding a dynamic-packaging engine, corporate booking tools that need stays and ground transport, and travel start-ups that want inventory without negotiating supplier contracts one by one.

Frequently asked questions