Mapping GIATA and Bedbank codes

If you already run a hotel business you already have identifiers — a GIATA catalogue, an Bedbank property list, or your own internal codes built on top of them. You should not have to throw those away to add a supplier.

The lookup

ApiXV resolves external codes in-API. Send the identifier you hold and receive the corresponding identity in the ApiXV mapping network — the unified layer where every supplier record for a real property resolves to one entry.

Supported today:

• GIATA property codes
• Bedbank property identifiers

The network itself is built by sophisticated AI processing across supplier records, and is grounded against Google CID legal-entity business identifiers at a 98.8% match rate. That external anchor is what makes a resolved identity meaningful rather than merely internally consistent.

Support arrived in version 0.10.x. Before it, integrations needed to know which supplier a code belonged to; now the supplier is resolved from the UID and you do not send it at all.

Why this matters more than it sounds

Without in-API mapping, every aggregator integration means building and maintaining a mapping table: a job that is never finished, because properties open, close, merge and rebrand continuously. Teams routinely staff this permanently.

With it, the mapping is the vendor's problem. You send what you have.

Working with the result

A resolved lookup gives you a hotel_uid:

{
  "hotel_uid": "AXH-qCzrQmMQvRPa",
  "name": "Hotel Marés de Palma"
}

Everything downstream — content, availability, booking — uses that UID.

Each entry also carries full geocoding: country, area, state, city, geographic coordinates and a Google Plus Code.

Two constraints worth designing around:

1. UIDs are temporary. Do not build a persistent local mapping table of ApiXV UIDs. Resolve them as part of your request flow.
2. One request, one code, for now. Batching multiple external codes into a single lookup is on the roadmap but not yet released. Content requests already accept multiple hotel_uids.

Unmatched codes

Not every external code resolves. A property may not exist in our supply, or may not have reached the confidence threshold for an automatic match. Handle the empty result as a normal case rather than an error — and tell us, because unmatched codes are how the matching improves.