Supplier mapping
The transformation layer that converts each supplier’s schema into the platform’s unified model and back, with versioning and validation.
Mappings translate supplier payloads into a stable offer and order model and back again. They reconcile concepts (fare families, ancillaries, board types, policies) and normalise identity so the same product looks consistent across sources.
Healthy mapping programmes pair validation with observability: contract tests, sample traffic replays, and drift detection when a supplier adds enum values or fields. Rollouts use versions and canaries so regressions can be reversed fast.
Mappings are not only for search. Servicing (exchanges, refunds, post‑ticket ancillaries) and finance (tickets, EMDs, statements) depend on accurate transforms and references.
Identity and normalisation are constant challenges: the same airline cabin or hotel board type may be named differently per supplier; time zones and currencies vary; rounding rules differ. Define canonical enums and conversion rules so clients never guess.
In the Elkanio platform, Synapse maintains versioned supplier mappings with capability flags and drift handling so clients keep one schema while suppliers evolve behind the scenes.
What teams often get wrong
-
Is mapping a one‑time project?
No. Suppliers evolve constantly. Treat mapping as an ongoing discipline with tests, alerts and safe deployments.
-
Should we hide differences entirely?
Expose meaningful differences through flags and typed fields so UIs and workflows behave correctly without leaking raw supplier schemas.
Explore connected concepts
Prefer a walkthrough?
See how the products fit together and discuss your use cases in a live demo.