Contents

Integrating a website with 1C (the accounting and ERP system widely used in Russia and CIS countries) and a CRM removes manual copying of products, stock, prices, orders and customers between systems. A reliable integration rests on three decisions: every entity has a master system, the exchange runs through APIs and queues, and errors are visible immediately rather than a week later when a customer complains.

Here is which data is usually synced, which exchange methods exist and why integrations break.

Which data is synced between systems?

Typically products, prices and stock flow from 1C to the website, orders flow from the website to 1C and the CRM, and customers and statuses go both ways. To stop data overwriting itself, each entity has a predefined master system — the source of truth.

Data Master system Direction Frequency
Products and attributes 1C 1C → website Hourly or on change
Prices and stock 1C 1C → website Every 5–15 minutes
Orders Website Website → 1C, CRM Right after checkout
Order statuses 1C 1C → website On change
Customers and deals CRM Website ↔ CRM Immediately

Which exchange methods are there?

There are three main methods: scheduled file exchange, direct API calls and exchange through a message queue. Files are the oldest and still common approach for 1C, APIs suit modern CRMs, and a queue makes the exchange resilient to failures on either side.

  • file exchange — 1C exports XML on a schedule and the website imports it; simple but delayed;
  • 1C HTTP services — the website calls 1C's API in real time; fast, but 1C must handle the load;
  • CRM APIs — popular CRMs have documented APIs and event webhooks;
  • queue — events are written to a queue and a separate worker delivers them, retrying on errors.

We covered queues in job queues in a web application.

Tall shelves of boxes in a warehouse aisle Photo: Unsplash

How do you make the exchange reliable?

The exchange is reliable when the website does not depend on 1C and the CRM being available at the moment a user acts. An order is first saved on the website, and sending it to other systems happens in the background with retries — so the customer sees no error even if 1C is down for maintenance.

Rules for a reliable integration:

  1. Idempotency. Resending the same order does not create a duplicate — every event has a unique key. See idempotent payments and webhooks.
  2. Retries with backoff. If a system is unavailable, sending is retried at increasing intervals.
  3. ID mapping. Store the mapping between the website's internal IDs and IDs in 1C and the CRM.
  4. Partial updates. Stock and prices are updated separately from the catalogue — faster and safer.
  5. Exchange log. Every message and response is stored to investigate disputes.

Why do integrations break?

Integrations break because of changes on one side that the other never learns about: a required field added in 1C, a renamed pipeline stage in the CRM, a new product attribute. Without monitoring, such failures are noticed when orders have not reached the warehouse for days.

Common causes:

  • a 1C customisation was released without testing the exchange;
  • mismatched reference data: units, warehouses and statuses are named differently;
  • no error handling — a failed send is simply lost;
  • the exchange is started manually and depends on one employee;
  • a full catalogue export every time instead of changes, so the exchange runs for hours.

How do you monitor an integration?

Monitor an integration with a dashboard and alerts: how many events are queued, how many errors there are, when the last successful sync was. If stock has not updated for over an hour or an order has not reached 1C within 15 minutes, the owner gets notified.

  • exchange error alerts in the team messenger;
  • a report on orders that did not reach 1C or the CRM;
  • a resend button managers can use without a developer;
  • a 1C test environment to check changes before release.

More on monitoring in monitoring and logging, and on the economics of automation in business process automation ROI.

In short

  • Choose a master system — the source of truth — for every entity in advance.
  • Exchange runs through files, APIs and queues; a queue makes it failure-resistant.
  • The website must not depend on 1C being available when a user acts.
  • Idempotency, retries and an exchange log prevent duplicates and losses.
  • Monitoring the queue and the last sync time reveals failures immediately.

FAQ

  • How long does a 1C integration take?

    A typical exchange of products, stock and orders takes two to six weeks including testing. It depends heavily on how customised the 1C configuration is and whether you have a specialist on the 1C side.

  • Can a ready-made exchange module be enough?

    For standard configurations and common CMSs, yes — ready-made modules cover the basic exchange. With non-standard prices, discounts, warehouses or a customised 1C, the module will need work or a custom integration.

  • What if 1C is unavailable?

    The website should keep working: orders are saved locally and queued for sending, and stock is shown from the last sync. When 1C is back, the queue is sent automatically.