A reliable 1C integration: architecture for a site and business systems

A product, price, stock level, customer and order may each have a different owner. Without an agreement, the site and 1C overwrite values and hide divergence.

Create an object matrix: where it is created, who edits it, which external ID is used and what happens during a conflict. This is the foundation of the contract.

A network error, lock or temporary outage must not create a duplicate order. Store an operation key, status, attempt time and response, and make retries idempotent.

Use a queue and worker for long exchanges. Operators need an error list with a retry for one step, not a button that blindly synchronises everything.

Test volume, limits and locks against a copy of the data. A nightly schedule is not enough: an order can arrive between exchanges and a price can change during checkout.

Separate reads, writes and background work. Keep a discrepancy log so support can see the affected object, not only an error count.

Start with one object type and a limited order cohort. Reconcile counts, totals, statuses and retries before enabling the full catalog.

After launch, measure latency, error rate and recovery time. A reliable exchange is an observable process, not one successful import.

OData, HTTP services, EnterpriseData, CommerceML or a bus are tools, not architecture by themselves. The choice follows volume, freshness, 1C version, operating mode and data ownership.

Decide which actions must be online and which can run through a queue. That often matters more than the protocol name.

Show operators sent, accepted, rejected and pending objects. For an order, keep the discrepancy reason and a link to both sides of the operation.

A regular reconciliation should not require comparing two exports manually. The system should produce exceptions and a safe next action.

Restrict endpoints, use separate credentials and verify webhook signatures. Do not send unnecessary personal fields or store secrets in logs.

Test schema and schedule changes outside production first. Make contract version and activation date visible to support.

Zero errors are unrealistic in a distributed system. What matters is that every error is detected, explained and recoverable without a duplicate operation.

After stabilisation, measure freshness, manual hours and exception rate. These numbers define the next improvement.

Version, server or file deployment, extensions, exchange frequency and test-environment access shape the plan. “1C integration” can mean a nightly export or a critical online exchange.

Assign an owner for 1C configuration and releases. Compatibility cannot be guaranteed without a counterpart who owns changes.

Price and stock may update through a queue while order confirmation may need an immediate response. Define latency, retry and reconciliation for each object.

This avoids forcing every exchange to be synchronous and remains reliable during a 1C maintenance window.

Define what product, order, counterparty, warehouse and document mean in the project. Record required fields, identifiers, owners and allowed states.

A shared dictionary prevents ad-hoc mapping and gives the 1C owner, backend and support team one reference.

1C may own stock while the site owns a cart field. If both systems can edit a value, define priority, version and conflict resolution.

Decide what deletion and archiving mean too. Ignoring deletion leaves stale products or active counterparties in the storefront.

Use anonymized orders with multiple tax rates, partial payment, returns and different units. A single simple row will not expose rounding or dictionary mismatches.

Run an observation mode where values are compared but not published. This gives accounting and process owners time to validate results.

Prepare a retry queue, discrepancy report and a way to restore the previous source of truth. Assign a monitoring window and owners for each step.

After launch compare order counts, amounts and update delay. Early success is the ability to find and localize a mismatch quickly.

An exchange can run for months and fail after a configuration or extension update. Add contract checks to the 1C release routine and keep test data for repeatable validation. Compatibility is a process, not a one-time endpoint setting.

A customer and operator need a clear order state even when exchange is paused. A separate integration log keeps attempts, failure reason and next retry. This avoids searching 1C logs manually and speeds recovery.

Stock may tolerate a few minutes of delay while payment cannot. Record this in product requirements and show an honest timestamp or state. “Updated at 12:04” is better than silently displaying stale data.