Integration work is judged on the day it fails, not the day it ships. We build the connections between your storefront and your back office so that when a system is slow or down, orders queue rather than disappear.
Diagnosis first
Where integrations actually go wrong
Almost never in the happy path. These are the four failure modes that cost real money, and all four are design decisions rather than accidents.
An order reached the store but never the ERP
A write with no retry and no dead-letter queue. The webhook fired once, the receiving system was restarting, and nothing recorded the loss.
Stock says two, the warehouse says zero
Two systems both believing they own inventory. Fixable only by naming one source of truth per field and making the other read it.
The same order shipped twice
A non-idempotent endpoint plus a retry. The second call looked like a new order because nothing carried a stable key.
Nobody noticed for three days
No alerting on the integration itself. Monitoring the store tells you the store is up; it tells you nothing about the queue behind it.
Why this is the risky part of a build
In our experience the storefront is almost never what delays a project. Integration is, for a simple reason: it is the only part of the work where you do not control both ends.
A theme change is yours to make. An ERP connector depends on another team’s release schedule, another vendor’s rate limits, and a sandbox that may or may not exist. That is why we map systems first and why integration scope, not design scope, drives the timeline on most of our builds.
One source of truth per field
The single most useful decision in any integration project is also the least technical: write down which system owns each piece of data.
Not each system — each field. Your ERP may own price and stock while your PIM owns product copy and the storefront owns nothing but presentation. Once that is agreed, most arguments about sync direction answer themselves, and the ones that remain are genuine business decisions rather than engineering preferences.
Get it wrong and you get the failure everyone recognises: two systems confidently disagreeing about stock, a nightly job that overwrites yesterday’s fix, and no way to tell which number was right.
Where this sits
This is the plumbing. If you are building or rebuilding the storefront it sits on, that is eCommerce development. If you are moving platforms, integrations get re-pointed as part of platform migration rather than rebuilt from memory.
Any competent team can make two systems talk on a good day. The work worth paying for is what happens when the ERP is mid-upgrade, the carrier API is rate limiting you, or a payload arrives twice. We specify that behaviour before writing the integration, because retrofitting it means replaying a week of lost orders by hand.
Every payload defined and versioned, so a change on either side is a deliberate act rather than a surprise discovered in production.
Idempotent writes
Stable keys on every operation that creates or changes something, so a retry cannot duplicate an order, a refund or a stock movement.
Retries and a dead-letter queue
Transient failures retry with backoff. Anything that still fails lands somewhere a human can see it and replay it, rather than vanishing.
A named source of truth per field
Price, stock, product copy, customer record — each owned by exactly one system, with the direction of travel written down.
Alerting your team will act on
Alarms on queue depth, failure rate and sync lag, routed to whoever is actually on call. An alert nobody owns is decoration.
A sandbox you can test against
Wherever the vendor offers one. Where they do not, a stubbed environment, so releases are not first exercised against live orders.
How it runs
From first call to live.
Systems map1–2 weeks
What exists, what it owns, how it authenticates, what its rate limits are, and which undocumented spreadsheet is load-bearing.
Contract design1–2 weeks
Payloads, directions, triggers and failure behaviour agreed in writing with the people who own each system — before any code.
Build4–10 weeks
Built against sandboxes with the failure paths exercised deliberately: timeouts, malformed payloads, duplicate deliveries, auth expiry.
Parallel run2–3 weeks
New and old paths running together, outputs compared. Discrepancies get resolved here rather than argued about after switchover.
HandoverOngoing
Runbooks, dashboards and replay procedures, so your team can diagnose a stuck queue without calling us. Support retainer if you would rather we held it.
Frequently asked questions
Can you work with our existing ERP?
Almost certainly. The question is not whether it can be integrated but how — whether it has a supported API, a middleware connector, or only a file drop on an SFTP server. All three are workable; they differ in cost and in how quickly errors surface. We establish which during the systems map.
Do we need middleware, or can we connect directly?
Direct connections are simpler and cheaper for two or three systems. Middleware earns its cost once you have several systems, need to transform payloads between them, or want retries and replay in one place rather than implemented separately in each connection.
How do you handle inventory across multiple channels?
By naming one system the owner of stock and making everything else read from it, with a buffer for the lag that will exist no matter how good the sync is. Two systems that both believe they own inventory will drift — that is arithmetic, not a bug to be fixed later.
What happens when an integration fails at 2am?
The operation retries with backoff. If it still fails it lands in a dead-letter queue, an alert fires to whoever is on call, and nothing is lost — the work can be replayed once the cause is cleared. That behaviour is designed up front, not added after the first incident.
Can you take over integrations someone else built?
Yes, and it is common. We start by documenting what actually exists, which is usually the first time anyone has. Expect the audit to find at least one connection nobody knew was running and one that has been failing silently.
Want to talk through Custom API Integration for your store?
Tell us where it hurts. We will tell you honestly whether we are the right
people for it.
We use analytics cookies (Google Analytics) to understand how the site is used. Choose whether to allow them;
you can change this any time from Cookie settings. We do not use advertising cookies.
Privacy Policy
