A Shopify ERP integration is not complete when one successful test order reaches the ERP. It is complete when the flow can be operated, monitored and recovered under real conditions.
That requires business ownership and technical design to meet in the same document. This guide explains the decisions that make an integration dependable after the implementation team has moved on.
Start from business events, not endpoints
Before discussing APIs, identify the events the business needs to support:
- a product becomes sellable in a market;
- a price or customer-specific term changes;
- inventory is reserved, released or adjusted;
- a customer places, edits or cancels an order;
- fulfilment and tracking information becomes available;
- a refund or return changes the financial state.
For every event, record the source system, destination, required timing, acceptable delay and the consequence of failure. A field list without that context cannot define reliability.
Assign one source of truth per data domain
“Both systems update each other” is not an ownership model. Decide which system is authoritative for each domain and which changes are allowed elsewhere.
| Data domain | Questions to resolve |
|---|---|
| Products | Who creates the identifier, status, options and market availability? |
| Content | Does PIM or Shopify own descriptions, media and translations? |
| Pricing | Are prices public, market-specific, customer-specific or contract-driven? |
| Inventory | Which locations count as sellable stock and when is stock reserved? |
| Customers | Does Shopify, CRM or ERP own identity and account changes? |
| Orders | At what point is an order accepted by the operational system? |
| Fulfilment | Which system creates fulfilments, tracking and cancellations? |
Channel-specific content can belong in Shopify even when core product records originate in ERP. Ownership can differ by field, but that makes the data contract more important, not less.
Define an explicit data contract
The contract should describe more than a sample payload. Include:
- stable identifiers and mapping rules;
- required and optional fields;
- accepted formats and enumerations;
- validation and rejection behaviour;
- transformation and rounding rules;
- units, currencies, tax treatment and time zones;
- versioning and backward compatibility;
- handling for deletion, archival and reactivation.
Put business-readable explanations beside technical schemas. A price calculation or inventory rule needs to be reviewable by the person accountable for the outcome.
Choose the sync pattern by operational need
Common patterns include:
Event-driven
An event or webhook triggers work soon after a change. This is useful when delay affects customer promises or operations, but it requires duplicate handling, ordering decisions and a recovery path.
Scheduled synchronisation
A job processes changes at a defined interval. It can be easier to reconcile and control, but the business must accept the delay and understand what customers see between runs.
On-demand lookup
Shopify or an extension requests data when it is needed. This can keep information current but makes the customer journey depend on the availability and latency of another system.
Many real architectures use a combination. “Real time” should describe an agreed service need, not act as a default sales promise.
Design for duplicates and retries
Networks time out. Suppliers throttle requests. A response can be lost after the destination has already completed the operation.
Important write flows therefore need idempotency: repeating the same logical request should not create another order, payment or fulfilment. Use stable source identifiers and record processing state so retries can be safe.
Retries also need boundaries. Permanent validation errors should not loop forever. Separate recoverable failures from records that require data correction or human review.
Make failure visible
Logging is not the same as monitoring. An operational integration should answer:
- Is the flow running?
- How far behind is it?
- Which records failed?
- Has the failure been retried?
- Is customer-facing data now unreliable?
- Who needs to act?
Useful controls may include metrics, structured logs, alerts, a dead-letter queue and a reconciliation view. The appropriate level depends on the business consequence of the flow.
Reconciliation closes the reliability gap
An integration can report success and still produce a wrong result. Reconciliation compares meaningful totals or records between systems.
Examples include:
- Shopify orders accepted by ERP during a time window;
- quantities by order line;
- fulfilments and tracking references;
- inventory balances for selected locations;
- active products and price lists by market.
Define tolerances and ownership. Someone needs to know whether a difference is expected, delayed or an incident.
Test real operational cases
The test plan should cover:
- a normal order and a duplicate delivery attempt;
- partial fulfilment and partial refund;
- cancellation before and after ERP acceptance;
- missing or invalid customer and product identifiers;
- inventory reaching zero during an order;
- rate limiting and source-system downtime;
- replay after a prolonged outage;
- a schema or business-rule change.
Use non-production environments where the vendors support them, but recognise differences in data and capabilities. A production activation still needs controlled validation.
Document operating responsibility
Write down who owns:
- ERP data and API access;
- Shopify configuration and extensions;
- integration infrastructure and secrets;
- monitoring and first response;
- business-data correction;
- vendor escalation;
- release approval and change communication.
If several suppliers are involved, define the evidence each one must provide before handing an incident to another team.
Plan for change from day one
APIs, ERP versions, Shopify capabilities and business rules change. Use version control, separate environments, reviewable configuration and automated tests where the risk justifies them.
Shopify’s Admin GraphQL API documentation is the primary reference for supported Shopify operations. The exact source-system documentation and contracted access are equally important.
The architecture test
A sound Shopify ERP integration has clear sources of truth, documented contracts, safe retries, visible failures, reconciliation and named operational owners. If one of those is missing, the implementation may transfer data but it is not yet dependable.
Explore Growly’s Shopify integration service or review the migration checklist if the integration is part of a wider replatforming programme.