What actually passes between systems
Almost every commerce integration moves the same six objects. Scope is really a question of which of them you need, in which direction, and how quickly.
- Orders: checkout to ERP or OMS, with tax, discounts, gift cards, currency and channel of origin preserved
- Inventory: available-to-promise per location, which is not the same number as on-hand
- Products and variants: identifiers, attributes, media and channel-specific overrides
- Customers and accounts: including B2B hierarchies, credit terms and consent state
- Fulfillments and returns: shipments, tracking, partial shipments, RMAs and credits
- Financials: payments, payouts, fees and settlement reconciliation
Source of truth, decided before tooling
The most expensive integration failures are not technical. They happen because two systems were both allowed to write the same field, and the last write won at random.
Our first deliverable is normally a one-page data contract: for every synchronized field, which system is authoritative, which direction it flows, how often, and what happens on conflict. It takes days rather than weeks and it removes most of the failure modes below before anyone writes code.
Reliability and error handling
An integration is defined by how it behaves on its worst day, not its first. These properties are what separate the ones still running in three years.
- Idempotency, so a redelivered webhook cannot create a duplicate order
- Backpressure and queueing, so peak-season volume waits instead of overwhelming the slower system
- Visible failure: errors reach a human with enough context to act, rather than retrying into silence
- Scheduled reconciliation that proves both systems agree and alerts when they drift
- Replay, so a failed window can be reprocessed without hand-editing records
- A documented data contract, so the next change does not require reverse engineering
Security and access
Integrations move customer and financial data, so access is scoped per system with least-privilege credentials, secrets held in a managed store rather than in code or environment files, and API access logged.
Where the data crosses jurisdictions or includes payment information, we will tell you what that implies for your obligations. We are not your compliance advisor, but we will not build something that quietly creates a problem for you.
How engagements run
Audit the current architecture, design the target state, build with monitoring from the first deployment, migrate with rollback and parallel running, then operate or hand over with runbooks.
Most engagements start with one urgent symptom. We will fix that first, then sequence the rest by what is costing you most, not by what is easiest to sell.
Common questions
- What is ecommerce integration?
- Connecting your commerce platform to the other systems that run the business — ERP, CRM, PIM, OMS, WMS, accounting and shipping — so orders, inventory, customers, products and financial data stay consistent without anyone moving them by hand.
- How do you decide which system owns a field?
- Field by field, written down before any code. ERP normally owns cost, purchasing and inventory ownership; the commerce platform owns the customer-facing catalog and checkout; PIM owns descriptive attributes. Conflict arises where two systems both claim price or availability, so those get an explicit owner and direction.
- Do you use middleware or build custom?
- Whichever survives contact with your operating model. Boomi, Workato, Patchworks and Prismatic all work well for standard flows. Custom is justified when the logic is genuinely unusual. The platform choice matters far less than whether the integration has ownership, monitoring and a reconciliation story.
- Can you take over an integration someone else built?
- Yes, and it is a common starting point. We audit what it does, what depends on it and where it fails, then decide with you whether to stabilize it or replace it. Replacing is not automatically the answer and we have no incentive to pretend otherwise.