Certification Cases

A guide for customers integrating against the TTDbooking API platform.

Overview

Every new integration is certified before it is switched on for production. Certification confirms that your implementation drives the booking flow correctly, returns sound data, and satisfies the requirements our suppliers impose on downstream systems. Clearing it is what unlocks production credentials.

The exercise is there to confirm that your integration can:

• Run the complete TTDbooking booking flow from search through to cancellation
• Meet the mandatory supplier requirements, which we validate automatically
• Behave predictably and accurately for the travellers using it

We assess functional correctness only — how your interface looks is not part of the review.

Test Environment Information

All certification work is carried out against the TTDbooking test environment.

Test Credentials

appKey: ttdbooking_api_demo
appSecret: ttdbooking_api_demo

Test Hotel IDs

With the shared credentials above, use these four test hotels. They are simulated — every one is named DO NOT BOOK, and no real reservation is ever made — and between them they cover every room, occupancy, meal plan and cancellation policy you need to certify. Their rates are stable: the same search returns the same rooms, prices and policies on any date you choose.

Search them by ID — hotelList with "hotelIds": ["TTD-TEST-HOTEL-1", "TTD-TEST-HOTEL-2", "TTD-TEST-HOTEL-3", "TTD-TEST-HOTEL-4"] — and leave maxRatesPerHotel unset to see every rate. IDs are strings: send them quoted.

Reading a ratePkgId. Each test rate id says what it is: TEST<hotel>-<room>-<meal plan>-<policy>, for example TEST1-FAM-BB-FREE7 (hotel 1, family room, bed & breakfast, free cancellation until 7 days before check-in). Policies are FREE7, FREE1, LADDER (stepped), PART (refundable less one night) and NRF (non-refundable).

The certification scenarios on the test hotels.

• Scenario 1 — search TTD-TEST-HOTEL-1 with the three rooms. Only the Family Room takes 2 adults and 2 children, and TEST1-FAM-BB-FREE7 is the refundable ("full") bed & breakfast rate: one ratePkgId covers all three rooms, totalRate is the price of all three and rate the price of one.
• Scenario 2 — search TTD-TEST-HOTEL-1 with one room for 2 adults and pick TEST1-DBL-HB-NRF, the non-refundable ("no") half-board rate.

Book at least 15 days ahead to see every cancellation policy exactly as described. A stay that starts inside a policy's free period is quoted as the band that applies now — free-until-7-days becomes non-refundable inside 7 days, and the stepped policy charges one night inside 14 days — just as a real hotel would quote it.

Any other hotel ID — MOCK-HOTEL-1, or IDs of your own in hotelIds — still returns a generic simulated hotel with a single bed & breakfast rate, priced per room per night and refundable until 7 days before check-in. Like a test hotel rate, one ratePkgId covers every room you search.

Test Environment Notes

• What is available in test will not necessarily match production
• With the shared credentials, rates and inventory are simulated, and no real hotel is ever booked
• The simulator produces stable, repeatable rate data, so repeated runs stay consistent
• checkAvail confirms the price hotelList quoted, on the four test hotels and on the generic simulated hotel alike — except the -PRICEUP and -GONE rates on TTD-TEST-HOTEL-4, which exist to show a price change and an unavailable rate
• Everyone using the shared credentials shares one account: use a unique customerReferenceNo per booking, and do not send real guest details
• Hotel content (hotelStaticDetail) is not available for simulated hotels, and callbackUrl is not accepted on the shared credentials — poll queryOrders, or ask for your own test credentials to exercise callbacks

Certification Scenarios

Certification is assessed on complete end-to-end booking scenarios rather than on individual API calls in isolation. Each scenario checks that your integration carries every required step of the booking flow through consistently.

Core Scenarios

Between them, the two scenarios below cover the booking patterns you are most likely to encounter.

Test Core Booking Flow

For each scenario, capture and submit the JSON request and response files for the full API sequence set out below:

Additional Self-Testing Scenarios

Submit for Certification

When you have worked through every scenario, send us the complete set of raw JSON request and response files for review, following the requirements below.

File Requirements

File Type

• Everything you submit must be in .json format
• Raw logs, Postman exports, and server traces are all fine

File Naming Convention (Mandatory)

Name every certification file according to this pattern:

<scenarioPrefix>_<rq|rs>_<apiName>.json

Where:

• scenarioPrefix = s1 or s2
• rq = request
• rs = response
• apiName = hotelList, hotelRates, checkAvail, book, queryOrders, cancel

Example Files (Scenario 1)

Submission Method

Send the finished files to us by email:

• Email: integrations@ttdbooking.com
• Email Subject: Integration Review – [Your Company Name]
• Attachments: every JSON file, named as described above

Final Certification Outcome

Once we have been through your submitted JSON files, we will come back to you with one of these three results:

Appendix: Sample Request/Response Templates

Scenario 1: HotelList Request

{
  "hotelIds": ["1", "2", "3"],
  "checkIn": "2026-02-15",
  "checkOut": "2026-02-17",
  "roomOccupancies": [
    {
      "adultCount": 2,
      "childrenAges": [5, 7]
    },
    {
      "adultCount": 2,
      "childrenAges": [4]
    },
    {
      "adultCount": 2,
      "childrenAges": []
    }
  ],
  "nationalityCode": "US"
}

Scenario 1: Expected Rate Matching

In Scenario 1, the rate you select needs to look like this:

{
  "refundableMode": "full",
  "board": {
    "boardId": "BB"
  }
}

Scenario 2: HotelList Request

{
  "hotelIds": ["4", "5"],
  "checkIn": "2026-02-15",
  "checkOut": "2026-02-17",
  "roomOccupancies": [
    {
      "adultCount": 2,
      "childrenAges": []
    }
  ],
  "nationalityCode": "US"
}

Scenario 2: Expected Rate Matching

In Scenario 2, the rate you select needs to look like this:

{
  "refundableMode": "no",
  "board": {
    "boardId": "HB"
  }
}

Frequently Asked Questions

Q: Can I use any hotel for testing?

A: Yes. The hotel IDs we list are recommendations that give you a stable baseline, but any hotel that returns availability in the test environment is acceptable for certification.

Q: What if the test hotel shows no availability?

A: The listed test hotels are set up to return availability at all times. If one does not, write to integrations@ttdbooking.com and we will look into it.

Q: How do I maintain the same session-id across API calls?

A: HotelList returns the session-id in its response. Pass that same value on to HotelRates, CheckAvail, and Book as the Session-Id request header.

Q: What currencies are supported in the test environment?

A: USD is used by default. EUR, GBP, CNY, and the other major currencies can also be tested by setting the Currency header.

Q: How long is the test data valid?

A: Test data is generated on the fly from the parameters you send. For the most reliable results, use a check-in date at least 7 days ahead.

Working through this certification is what gives both sides confidence that an integration is ready for live traffic. Pass it, and we will issue your production access.

Full API reference: developer.ttdbooking.com/hotel-api/docs

Last Updated: December 2025 Version: 1.0