Canonical ID
A stable internal identifier that survives supplier or channel changes. Channel-specific IDs should map into the canonical model through adapters.
Why it matters
The same physical travel entity can appear with different IDs, names and metadata across suppliers. If identity resolution is wrong, correct price and availability data can still be attached to the wrong property or product. Canonical identity, source identifiers and mapping confidence need to be designed together.
What does it look like in practice?
An Expedia property ID and a Booking.com property ID can represent the same physical hotel. Internal canonical identity should connect them using evidence and confidence.
Implementation questions
- How is the canonical entity defined?
- Are source-specific IDs retained?
- Which signals drive matching?
- Is there a manual-review path for ambiguous matches?
Common mistakes
- Mapping from name similarity alone
- Overwriting manual overrides
- Creating duplicates after rebrands
Where does it appear in the travel stack?
Canonical ID commonly appears across identity layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.
Related terms
Related technical guides
Canonical Hotel Entity Model
Design a canonical hotel identity layer that maps multiple supplier property records into one traceable entity with provenance and merge history.
Explore →Hotel Rebrand / Rename Reconciliation Playbook
Preserve canonical hotel identity across name and brand changes while managing aliases, source mappings and downstream invalidation.
Explore →How to Diagnose Room & Rate Mapping Problems
Troubleshoot hotel room and rate-plan mapping failures using canonical identity, occupancy, meal, policy and contradiction evidence.
Explore →Canonical Offer, Order and Booking State Model
Design canonical Offer, Order and Booking lifecycle boundaries with an explicit booking state machine for travel integrations.
Explore →Travel Payment Ownership: Merchant of Record, Seller of Record and Collect Models
Separate Merchant of Record, Seller of Record, agency collect, hotel collect and pay-at-property models across booking and reconciliation.
Explore →Travel PII and Passenger Data Boundaries
Design safe boundaries for passenger identity, contact, payment and travel-document data across search, booking, logging and provider integrations.
Explore →