1 ▸ I don’t support some optional content types—what happens?
Hotel Trader activates your integration only for compatible properties, i.e. whose data you already handle. Unsupported objects are omitted, so you’ll never receive payloads you can’t parse. As you expand your coverage, simply enable the new content types on your side—no contract change is required.
2 ▸ Where can I see full sample requests (including optional fields)?
The API reference contains copy-and-paste payloads for every optional attribute—look under Tax API and Products API. Each sample shows realistic use-cases for conditions, seasonal meal plans, and cancellation rules.
3 ▸ What response should a client return?
-
Validate every required field.
-
If validation fails, respond with an appropriate HTTP error code (4xx).
-
If validation succeeds, return 200 OK (or 202 Accepted) and process the payload asynchronously.
ℹ️ Find additional details about this topic in our article on Status objects.
4 ▸ Do retries use exponential backoff?
No. Hotel Trader retries each message three times with a fixed 20-second interval.
5 ▸ Will retries create duplicates?
Yes—the identical messageId is sent again. Implement idempotency checks on messageId to prevent double-processing.
6 ▸ What should we log?
Record the messageId, metadata type, timestamp, and processing result for every message. This makes support and reconciliation fast.
7 ▸ How are rateplans or room types disabled if DISABLE / ENABLE aren’t used?
Hotel Trader controls availability through ARI (Availability, Rates, Inventory) updates. We “close” or “open” the entity instead of sending a DISABLE or ENABLE.
8 ▸ What do we do with a metadata object that has DISABLE?
Mark the entity inactive—or remove it from sale—according to your system’s design.
9 ▸ Will cancellation policies ever be sent with DISABLE / ENABLE?
No. Cancellation policies are only delivered as NEW or UPDATE. When a policy is obsolete, it simply stops appearing in rateplan references.
10 ▸ Is updateType always present?
-
Most metadata APIs: Yes—use it to decide whether to create, update, disable, or enable.
-
Products API: No—each payload contains the complete product state for the rateplan; you determine create/update/delete from that snapshot.
11 ▸ How is product data packaged for a rateplan?
Every request carries the full list of products for the rateplan, with every field populated. No partial updates are sent.
12 ▸ Which age categories are supported?
CHILD and ADULT today. Future versions may split CHILD into finer bands (e.g., Infant 0-5 yrs, Child A 5-12 yrs, Child B 13-18 yrs).
Both minAge and maxAge are inclusive.
13 ▸ What are “mapping providers”?
Third-party services (e.g., GIATA, VERVOTECH) that align property codes across systems. If you use one, we include its codes; otherwise, we send your master property IDs.
14 ▸ Are images delivered?
Not at this time. Images are currently omitted from all API responses.
15 ▸ What is a seasonalPolicy?
A date-specific override of the base cancellation policy, defined by name, code, and a start/end date range.
16 ▸ What does rateplanType mean?
It lists the channel(s) for the rateplan (e.g., B2B_Package, B2C_Package). null means no restriction.
17 ▸ Can we create many rateplans in one call?
Yes—the POST endpoint supports multiple entities. Hotel Trader currently sends one rateplan per request but may batch them in the future, so your implementation should already accept an array.
18 ▸ How often are audit APIs invoked?
-
On first push of any entity, to determine its
updateType. -
After every subsequent metadata push for that entity.
The cadence is managed by Hotel Trader.
19 ▸ What can go wrong if metadata drifts?
-
Invalid bookings
-
Over- or under-booking
-
Pricing errors
-
Tax or rule violations
-
Lost revenue—for both sides
20 ▸ How does Hotel Trader react to a mismatch?
-
Send an alert to the partner
-
Re-push the correct metadata
-
Temporarily disable the affected property or rateplan
-
Escalate to your support team for an urgent fix