Connecting a supplier feed looks trivial on day one - pull a file, loop over the products, done. The trouble starts on day thirty, when prices drift, a product is renamed, and nobody can explain why a tour disappeared from your site. A feed integration is mostly about the unglamorous parts: mapping, scheduling, validation and reconciliation. Here is how to do it so it keeps working.
1. Map to your own model, not the supplier's
The single most important decision is to translate the feed into your internal product model immediately, rather than letting supplier fields leak across your codebase. Build a thin adapter that converts each feed product into your canonical shape:
supplier product -> adapter -> your canonical Product
{ code, title, (mapping) { id, name, durationISO,
duration, net, priceNet, currency,
pickup, rules } pickupPolicy, cancelRules }
When the supplier adds a field or renames one, you change the adapter - not fifty call sites.
2. Decide your refresh cadence honestly
Feeds are a snapshot, not a stream. Match the pull frequency to how fast the data actually changes:
- Descriptions and product structure change rarely - a daily pull is plenty.
- Net rates change more often - pull these more frequently, or confirm price at booking time.
- Availability is the one thing a feed should not be trusted for in real time - verify it with a live call before you confirm.
Use the feed for what is stable (catalogue) and a live call for what is volatile (availability and final price).
3. Validate before you publish
Never let a feed write straight to production. Run every pull through validation and treat failures as a signal, not a surprise:
- Reject products missing required fields instead of publishing half a record.
- Flag suspicious deltas - a price that moved 80% overnight is probably an error.
- Detect disappearances: a product that vanished may be retired, or the feed may be truncated.
- Keep the last good snapshot so a bad pull never wipes your catalogue.
4. Reconcile what you sold against what you booked
Because a feed is a snapshot, there is always a window where your data and the supplier's diverge. Close it with a confirmation step: when you place a booking, the supplier's response - not your cached feed - is the source of truth for price and confirmation. Store that reference and reconcile against it.
5. Make the integration observable
You cannot fix what you cannot see. Log each pull: how many products, how many changed, how many were rejected, and how long it took. A simple dashboard of "last successful sync" saves hours of debugging when something looks off.
A sensible target architecture
[supplier feed] --pull--> [validator] --ok--> [adapter] --> [your catalogue]
| |
reject log live availability
check at checkout
Done this way, a tour-and-transfer feed becomes a low-maintenance backbone for your catalogue, while a thin real-time call handles the volatile last mile. That is the pattern Mokan Travel Connect is built around: a clean inventory feed for catalogue sync, and a live endpoint for the availability and confirmation that a feed should never guess at.