Multi-Vendor API Orchestration for a National Loyalty Programme
Replaced fragile point-to-point vendor integrations with an event-driven API orchestration layer. Reduced integration failures from 15/week to under 2.
Challenge
National loyalty programme integrating with 6 vendors (POS, CRM, email, mobile, analytics, payments) through point-to-point connections — brittle and unmanageable.
Solution
API orchestration layer with event-driven architecture, contract testing per vendor, and centralized monitoring and alerting.
Result
Integration failures dropped from 15/week to under 2, new vendor onboarding time reduced from 8 weeks to 2 weeks.
The Problem
A major retail group had built a national loyalty programme that touched every part of the customer experience — earning points at the POS, tracking in the CRM, personalised emails, mobile app redemptions, analytics dashboards, and payment processing for point-to-cash conversions. Each of these capabilities was provided by a different vendor, and each vendor integration had been built as a direct point-to-point connection.
The result was a web of 15 individual integrations, each with its own authentication method, data format, retry logic, and failure mode. When the POS vendor changed their API version, it broke the points-earning flow. When the email vendor had an outage, the mobile app started throwing errors because they shared a data dependency. There was no central place to see what was working and what wasn't.
Integration failures averaged 15 per week, and each one required a developer to manually diagnose which vendor, which endpoint, and which payload was responsible. The loyalty programme — a strategic differentiator for the business — was being undermined by its own technical foundation.
What I Did
I designed an API orchestration layer that decoupled every vendor integration from every other. The architecture was event-driven: business events (point earned, reward redeemed, member enrolled) were published to a central event bus, and vendor-specific adapters consumed the events they cared about.
Each vendor adapter handled translation from the canonical event format to the vendor's specific API contract. This meant a vendor API change only affected one adapter — not the entire system. Adapters included built-in retry logic, circuit breakers, and dead-letter queues for failed messages.
I introduced contract testing for every vendor integration. Each adapter had a suite of tests that validated the vendor's API still behaved as expected. These ran daily and alerted the team immediately if a vendor made a breaking change — before customers noticed.
Centralized monitoring was a key deliverable. We built a dashboard showing real-time health for every vendor integration: success rates, latency, error rates, and queue depths. Alerts fired when any metric crossed a threshold, and the on-call team could see exactly which vendor and which event type was affected.
I managed the migration carefully — we ran the orchestration layer in parallel with the existing point-to-point integrations for four weeks, comparing results before cutting over. Each vendor was migrated individually, with rollback capability at every step.
The Outcome
Integration failures dropped from 15 per week to fewer than 2. When failures did occur, mean time to resolution fell from 4 hours to 30 minutes because the monitoring system pinpointed the exact vendor and event type immediately.
New vendor onboarding time decreased from 8 weeks to 2 weeks. When the business decided to add a seventh vendor for push notifications, the team built the adapter and had it running in production within 10 days. The orchestration layer turned vendor management from a liability into a competitive advantage — the loyalty programme could now evolve at the speed of business decisions rather than integration timelines.