Connect supported websites, ERP, accounting, payments, logistics, messaging, CRM, identity, BI and specialist systems through APIs, webhooks, scheduled synchronisation or controlled file exchange—without turning every external platform into a competing source of operational truth.
Integrations is the ongoing system-to-system connection layer after go-live. It is distinct from Data Migration, which establishes the opening data state, and from Marketplace Connections, which handles marketplace-specific catalogue, stock and transaction exchange.
The integration method should match the external system’s capability and the business need. Real-time exchange is not always necessary, and batch exchange is not always sufficient.
Use supported APIs and webhooks for near-real-time events, status changes and controlled data exchange.
Exchange approved datasets at defined intervals when continuous real-time synchronisation is unnecessary or unsupported.
Use structured imports and exports where APIs are unavailable or a controlled batch process better fits the external system.
An integration should be treated as an operating contract between systems: what moves, who owns it, how often, under which credentials, and what happens when the exchange fails.
Define systems, authoritative fields, event direction, identifiers, frequency, dependencies and acceptance rules.
Configure authentication, permissions, endpoints, webhooks, schedules and secrets using the minimum required access.
Map records, preserve identifiers, exchange events and compare source and destination state without silent divergence.
Track connection health, latency, failures, retries, rate limits, schema changes, permissions and audit activity.
Start with the complete integration architecture, then move through system ownership, field and event contracts, authentication, webhooks, schedules, mapping, incremental sync, duplicate protection, reconciliation, health, failures, retries and provider changes.
Integration design should begin with business ownership, not endpoints. For each connected field, record or event, the implementation should define which system is authoritative and whether the exchange is inbound, outbound or genuinely two-way.
Two-way synchronisation should not be used as a default. Where both systems can change the same field, conflict and precedence rules need to be explicit.
Define which platform owns each operating domain.
Specify exactly what data moves and what triggers the exchange.
Keep systems aligned without relying on names as identifiers.
Define how often synchronisation occurs and what happens when values differ.
Connectivity should use the supported security model of the external platform and avoid exposing secrets in user-facing screens, logs, screenshots or ordinary exports.
Credentials should be scoped and rotated according to the applicable provider and client policy. Where possible, different environments should use separate credentials and endpoints.
Use the supported connection method with only the permissions required.
Receive external events securely and prevent duplicate processing.
Support controlled batch integration where event-driven APIs are unsuitable.
Keep sensitive connection material separate from normal operational access.
Ongoing synchronisation should know what changed, what has already been processed, which external record corresponds to the internal record and whether both sides still agree on the expected state.
Where an external system is not authoritative, a conflicting value should not silently overwrite Commerce OS. The conflict should follow the agreed precedence or review rule.
Move only the records or events that need to change when supported.
Prevent retried events from creating duplicate business records.
Compare systems and surface divergence before it becomes operationally damaging.
Retain enough history to explain where a value or status came from.
Integrations can degrade even when neither business system is down. Expired credentials, schema changes, throttling, partial provider outages or malformed records can leave data stale or incomplete.
The operations view should make failures visible, preserve the internal authoritative state and provide controlled retry, remediation or escalation.
Know whether each connection is functioning within the expected window.
Keep failed exchange visible until it has a safe outcome.
Detect when an integration contract changes outside Commerce OS.
Keep technical changes attributable and reviewable.
The integration should not enter production until system ownership, mapping, security, failure handling and acceptance tests are understood.
Choose system ownership, fields, events, direction, identifiers, frequency and acceptance criteria.
Configure supported credentials, endpoints, webhooks, schedules or file exchange with minimum access.
Define record relationships, field mappings, status translations and conflict rules.
Run controlled events or batches, compare both systems and validate retry and failure handling.
Enable the approved connection scope and monitor early production activity closely.
Review latency, failures, provider changes, mapping drift, throughput and ongoing business need.
Data Migration establishes the opening Commerce OS state from legacy data. Integrations maintain continuing exchange between live systems after go-live.
Marketplace Connections is the marketplace-specific connector layer. Integrations covers other supported business systems such as finance, payments, logistics, messaging, ERP, identity and analytics.
The implementation should identify who owns each connected business domain, who authorises credentials and which capabilities remain controlled by the external provider.
Each connection should be evaluated individually for supported APIs, ownership, frequency, security and whether real-time exchange is operationally necessary.
The final design depends on the external provider’s API or export capability, account permissions, security model, data ownership, expected volume, latency requirements and business-critical failure scenarios.
No. Data Migration establishes the opening Commerce OS state from legacy data. Integrations maintain ongoing exchange between live systems after go-live.
No. Marketplace Connections is the marketplace-specific connector layer. Integrations covers other supported systems such as finance, payments, logistics, messaging, ERP, identity and analytics.
Not automatically. Integration depends on the external system exposing a usable API, webhook, structured export/import or other supported interface and on the approved implementation scope.
No. The correct frequency depends on business need and external capability. Some events may need near-real-time exchange, while other data can safely synchronise on a schedule.
Yes, where appropriate, but two-way sync should define field ownership, precedence and conflict handling. It should not allow both systems to overwrite each other without rules.
Where supported, the integration can use external identifiers, event keys, idempotency controls and previously-processed checks so retries do not create duplicate business records.
The failure should remain visible with retry and escalation logic appropriate to the connection. Internal validated state should not be discarded merely because the external system is unavailable.
Credentials, tokens and secrets should be stored in protected configuration with restricted administrative access and should never appear in public pages, screenshots or ordinary exports.
Yes. The operations layer can track last successful exchange, failure volume, latency, stale-data thresholds, credential state and other health indicators where configured.
The integration may require remapping, code changes or a revised connection scope. Provider-controlled changes should be detected, tested and released through the normal change process.
We will map system ownership, fields, events, identifiers, direction, frequency, authentication, APIs, webhooks, schedules, file exchange, reconciliation, conflicts, retries, monitoring and provider-change risks.
Login