Start with a canonical contract
Define the application-facing hotel, occupancy, money, policy, option and booking objects before building the second adapter. Supplier-native fields can be retained for traceability without leaking every provider difference into product code.
Separate connection readiness from connector availability
A connector may exist while a customer connection is not ready. Readiness can depend on credentials, environment approval, IP allowlisting and supplier-side activation.
- Connector implemented
- Customer account approved
- Credentials present
- Network requirements completed
- Test workflow verified
- Production access approved
Aggregate without losing provenance
Parallel shopping needs timeouts and partial-failure behavior. Results should retain the fulfilling supplier and native option identifiers so review and booking route back to the correct source.
Design support tooling at the same time
Store a request identifier, per-supplier attempts, normalized outcome, safe error details and booking events. Without that evidence, multi-supplier failures become guesswork during checkout and customer support.
Frequently asked questions
Should all suppliers use one timeout?+
Not necessarily. The aggregator needs an overall response budget and provider-specific behavior based on supplier characteristics, while clearly handling partial results.
How do I prevent duplicate hotels?+
Map supplier hotel IDs to canonical property IDs, preserve source mappings and group comparable options beneath the canonical property.
Can I add suppliers without changing frontend code?+
Yes, if the application integrates a stable canonical contract and supplier-specific fields remain behind adapters.