Most integration projects do not fail because two APIs cannot exchange data. They fail because nobody decided which system owns each piece of data.

The storefront, the ERP, the CRM and the PIM each hold part of the commercial truth. When those parts overlap without rules, the business ends up with two prices, two stock levels and two versions of a customer. Integration is therefore a design problem before it is a technical one.

At a glance

  • Define a single owner for every entity before writing code.
  • Separate master data from transactional data.
  • Choose sync patterns per dataset, not one pattern for everything.
  • Design for failure: retries, idempotency and observability.

What each system usually owns

Different businesses draw the lines differently, but a common default looks like this:

System Typical ownership
ERP Stock, invoices, commercial conditions, accounting
CRM Leads, relationships, account ownership, pipeline
PIM Product content, attributes, media
Ecommerce Buying experience, cart, orders, customer accounts

The exact split matters less than writing it down. Once each entity has one owner, conflicts become implementation questions instead of business arguments.

Start with a data-ownership map

Before integration work, produce a map for every important entity:

Customer → which system owns it?
Account  → which system owns it?
Product  → which system owns it?
Price    → which system owns it?
Stock    → which system owns it?
Order    → where is it created?
Invoice  → where is it generated?

This map is the contract the whole integration is built against. It prevents the classic failure where stock is decremented in two systems and neither agrees.

Master data versus transactional data

Integration is easier to reason about when you separate two categories.

Master data changes slowly: products, attributes, customer records, payment terms. It usually flows from the authoritative system outward and tolerates eventual consistency.

Transactional data changes constantly: orders, payments, stock movements, invoices. It needs stronger guarantees, clearer ordering and better error handling.

Treating both with the same mechanism is a common architectural mistake.

Sync patterns and when to use them

There is no single correct synchronisation model. Choose per dataset:

Pattern Good for Watch out for
Real-time API Price and stock checks at purchase time Latency and availability
Event-driven (webhooks) Order and fulfilment events Delivery guarantees
Batch Catalog and price imports Staleness windows
Scheduled reconciliation Detecting drift Hidden conflicts

Most mature setups combine several. The question is not which is modern, but which matches the freshness the business actually needs.

The order flow is the critical path

Order handling is where integration quality becomes visible to the customer. A reliable flow is explicit at every step:

Order placed in storefront
↓
Order transmitted to ERP
↓
Availability / pricing confirmed
↓
Fulfilment and invoice generated
↓
Status returned to the customer

Each hop needs an owner, a retry policy and a way to detect when it fails. An order silently lost between the storefront and the ERP is worse than an order that visibly fails and can be recovered.

Design for failure, not for the happy path

Integrations break in predictable ways: timeouts, duplicate events, out-of-order messages, partial failures and schema changes. Good systems plan for them:

  • Idempotency so a repeated message does not create a duplicate order.
  • Retries with backoff instead of silent drops.
  • Reconciliation to detect drift between systems.
  • Dead-letter handling so failed messages are inspected, not lost.

These are delivery concerns, not theoretical edge cases. Shopify documents that failed webhook deliveries are retried eight times over four hours and that duplicate deliveries can occur; consumers should deduplicate deliveries using the webhook ID and make event handling safe to repeat (Shopify webhook delivery guidance). Those retry numbers apply to Shopify webhooks, not every integration provider.

A system that only works when everything succeeds is not finished.

Observability makes integration maintainable

You cannot fix what you cannot see. Log order flow across systems with correlation identifiers, expose sync status, alert on failures and track reconciliation results. Without observability, integration problems surface as customer complaints rather than alerts.

Security and access

Integration touches customer, pricing and payment data, so it inherits the strictest access rules. Use scoped credentials, encrypt in transit, limit what each integration can read and write, and keep secrets out of source control. The integration boundary is often the weakest link in an otherwise secure system.

Sequencing the work

A pragmatic order avoids a big-bang migration: define ownership, integrate one entity end to end, prove the order flow, then expand. Each step should be independently valuable and reversible. The same discipline applies whether the commerce layer is Shopify, a custom portal or the wider B2B commerce architecture.

An integration checklist

  1. Does every entity have exactly one owner?
  2. Is master data separated from transactional data?
  3. Is the sync pattern matched to each dataset?
  4. Are retries, idempotency and reconciliation in place?
  5. Can you trace an order across every system?
  6. Are credentials scoped and secrets managed?
  7. Can a new system be added without redesigning everything?

Integration is not plumbing. It is how the business decides where the truth lives.

Continue reading

Integration and connected systems sit in B2B Systems and Product Systems at FRN.Q. To map your current systems, start on the contact page.