The deliverable a client sees on day one is a new website, new app, or new internal system. The deliverable that decides whether the client is happy a year later is rarely the new system — it is whether the new system talks cleanly to the four or five systems the client was already running. ERP, payment gateway, logistics, accounting, CRM, e-invoicing, support desk. Get integrations right and the new system feels effortless. Get them wrong and the new system feels like extra work, regardless of how nice the UI is.
Our Third-Party API & System Integration service exists for exactly that gap. Below is the full pipeline we walk every client through, broken into five phases, with the deliverables and decision points at each stage.
Phase 1 — Integration Discovery (Week 1)
Before we touch any code, we sit with the client and inventory every external system the new product will need to read from or write to. The inventory includes more than just the obvious ERP and payment gateway. We ask for:
- All systems that hold customer data (CRM, MailChimp, Klaviyo, line@).
- All systems that hold transactional data (POS, ERP, accounting software, e-invoice platform).
- All systems that hold operational data (warehouse, logistics, courier APIs).
- All systems that hold communications (support desk, internal chat, SMS gateway).
For each system, we record: who owns the credentials, what the rate limits are, whether sandbox access exists, what the authentication model is (OAuth, API key, mTLS), and what data formats it expects. The deliverable is an Integration Map — a single page that lets the client see every wire that will need to be plugged in.
Phase 2 — Direction Of Flow & Conflict Resolution (Week 2)
The hardest integration question is rarely technical. It is: when two systems disagree about the same customer or order, who wins? We sit with the client and decide direction of truth for every shared entity. Common patterns:
- ERP wins on inventory, the new site is a follower — every stock change syncs from ERP outbound only.
- New site wins on customer profile, ERP syncs in — customer-facing UI lives where the customer experiences it.
- Bidirectional with conflict resolution — for orders, both can change them, but the rule is "latest timestamp wins, with audit log." Bidirectional is more expensive; we only recommend it when business actually requires it.
The deliverable is a Source-of-Truth Matrix that becomes the spec the engineering team builds against.
Phase 3 — Adapter Layer Build (Weeks 3–5)
We do not write integration code inline with business logic. Every external system gets its own adapter — a small module that translates between the external system's vocabulary and the new system's domain model. This isolation gives the client four wins:
- When the ERP vendor changes API versions (and they always do), only the adapter changes.
- When a courier swaps from XML to JSON, only the adapter changes.
- When a new business rule requires "send orders to both Courier A and Courier B," the adapter pattern handles the fan-out cleanly.
- When you want to swap one vendor for another, the adapter is the replaceable unit, not the entire backend.
The standard stack is Laravel queues for async work, Redis for rate-limit coordination, and a dedicated integration_logs table indexed on (adapter, direction, timestamp) so every call is auditable.
Phase 4 — Failure-Mode Design (Week 6)
Integration code that works on the happy path is the easy half. The other half is what happens when an external system is down, slow, or returns garbage. Our standard failure-mode protocol covers four scenarios:
- External system is down — queue the request, retry with exponential backoff, alert ops after the third failure.
- External system is slow — timeout at a conservative threshold (we default to 8 seconds), do not let the new system's user-facing requests block on it.
- External system returns unexpected data — validate against the adapter's schema, log the bad payload, surface a human-readable error in the admin panel, never crash silently.
- Two systems disagree mid-flight — use the Source-of-Truth Matrix from Phase 2 to resolve deterministically; log the resolution to the audit trail.
Phase 5 — Cutover, Reconciliation, And The First 30 Days (Weeks 7–8)
The cutover is rarely a "flip a switch" moment. We run integrations live for two weeks in shadow mode — the new system writes to its database and to the external systems, while the client's existing system also writes. Daily reconciliation reports surface any drift. Only when reconciliation is clean for five consecutive days do we cut the legacy system off.
Post-launch, we deliver:
- A live integrations dashboard (uptime, error rates, queue depth per adapter).
- A monthly integrations health report — which APIs are flaky, which need renegotiation with the vendor.
- A quarterly review of the Source-of-Truth Matrix as the client's business evolves.
Caveats — Three Conversations We Have Upfront With Every Client
First — "every system has an API" is a myth. Some systems have no API, some have undocumented APIs, some have APIs that are unusable in production. We do feasibility before we promise. Second — integration projects almost always reveal that the client's existing data is dirtier than they think. We budget a data-cleansing line item into every integration quote. Third — the maintenance cost of integrations is non-zero forever. APIs change, certificates expire, rate limits shift. Annual integrations maintenance runs 15–25% of original integration cost. Clients who do not budget for this end up with broken integrations within 18 months.
Integration is not a one-off project. It is a discipline. The clients we have served for five years are the clients whose Integration Map we are still updating today.