There are three main ways to integrate 1C with a web application: 1C HTTP services (a custom REST API built into the configuration), scheduled file-based exchange, or a message bus with queues. The choice depends on how fresh the data needs to be, the exchange volume, and whether the configuration can be modified. Whichever way you go, reliability comes down to three design decisions: a data contract with stable identifiers (GUIDs, not codes or names), idempotent message handling, and an exchange log that makes every error visible.
Contents
- Why connect 1C and a web application
- Ways to integrate 1C with a web application
- How to choose an exchange mechanism
- The data contract: the most expensive decision to change
- The usual pitfalls: encodings, locks, duplicates
- Exchange reliability: statuses, retries, a log
- Security: how to expose 1C to the outside
- A practical sequence of steps
Why connect 1C and a web application
For most companies in Kazakhstan, 1C is the core accounting system: product catalog, prices, stock levels, settlements, documents. The web application lives on the other side: catalog pages, customer accounts, orders, online payments. Integration exists so these two worlds stay in sync and managers stop re-entering data by hand.
Products, prices, and stock levels
- Direction
- go from 1C to the site
Orders, customers, and payment statuses
- Direction
- come back from the web application into 1C
Settlements and shipping documents
- Direction
- are shown in the customer account
Each flow has its own speed requirements: stock levels should ideally refresh within minutes, while settlements usually only need to sync once a day.
Ways to integrate 1C with a web application
“Integrating 1C via the web” usually means exchanging data through 1C HTTP services or the OData interface published on a web server: the website, CRM or app calls 1C over HTTP instead of using files and manual exports. Below are four mechanisms and how they differ.
Technically, the exchange is built on one of four mechanisms. They differ in delivery speed, in how much the configuration has to be modified, and in how well they tolerate one side being unavailable.
- 01Web application
- 02HTTP services · OData · files · queues
- 031C
1C HTTP services
- How it works
- From platform version 8.3 onward, the configuration can publish its own REST handlers: the web application requests stock levels or submits an order, and 1C responds with JSON
- Strengths and weaknesses
- The most flexible option: you expose a narrow, controlled API instead of the whole database. Requires modifying the configuration and publishing the infobase through a web server
The standard OData interface
- How it works
- Automatic REST access to configuration objects, enabled without any programming
- Strengths and weaknesses
- Convenient for reading reference data early on, but a poor fit for business logic: the interface is wide, queries are heavy, and access rights have to be restricted very carefully
File-based exchange
- How it works
- XML (including CommerceML) or CSV exports produced by a scheduled background job and transferred over SFTP or shared storage
- Strengths and weaknesses
- Slow, but easy to debug and resilient: the two sides do not have to be available at the same time. A sensible choice for nightly synchronization of large reference tables
A bus with message queues
- How it works
- 1C publishes data-change events to RabbitMQ or Kafka (directly or through an agent layer), and subscribers consume them at their own pace
- Strengths and weaknesses
- Justified when there are three or more systems — site, CRM, warehouse, mobile app — all needing the same data
How to choose an exchange mechanism
There is no universal answer — there is a set of criteria that lets you pick the mechanism in a single design session. A mistake at this step is expensive: migrating from file-based exchange to an event bus means rewriting both sides of the integration.
Order and payment statuses
- Freshness
- seconds to minutes
- Mechanism
- HTTP services or queues
Catalog and prices
- Freshness
- hours
- Mechanism
- a schedule
Settlements
- Freshness
- a day
- Mechanism
- file-based exchange is fine
- Volume: a catalog with hundreds of thousands of items cannot be transferred in full every time — you need change-based exchange, and the mechanism must support it
- Whether the configuration can be modified: a standard configuration under vendor support that must stay locked narrows the options — you are left with OData, configuration extensions, and external data processors
- Number of systems: two systems — a point-to-point integration; three or more — a candidate for a bus, otherwise the number of connections grows quadratically
- Tolerance for downtime: if 1C is regularly unavailable (maintenance, updates), synchronous HTTP calls from the web application must be wrapped in a queue with retries — or you should choose asynchronous exchange from the start
The data contract: the most expensive decision to change
A data contract is an answer, fixed before development starts, to four questions:
- Which entities take part in the exchange
- With which fields
- Which system owns each of them
- How the entities are identified
Transport can be swapped out; a broken contract can only be migrated away from, painfully, on both sides.
The same rule applies in the other direction: an order from the web application arrives in 1C with an external key, and 1C stores it in a document attribute. Then resending the same order finds the existing document instead of creating a duplicate.
Keep the field set to the minimum that is sufficient. Exporting "the whole object just in case" couples the systems more tightly than necessary: any change to a catalog in 1C starts breaking the parser on the web application side. Version the contract explicitly — with a version field in the message or a version in the HTTP service URL.
The usual pitfalls: encodings, locks, duplicates
Most incidents in 1C integrations repeat from project to project. They should be handled by design, before the first production launch, not through post-incident reviews.
Encodings
- What happens
- 1C historically outputs windows-1251 while the web stack expects UTF-8. Symptoms — unreadable product names, a BOM at the start of a file that breaks the parser, numbers like "1 234,56" with a non-breaking space and a comma
- Fix
- Fix the encoding, separators, and date format explicitly in the contract
Locks
- What happens
- Exporting "the whole database" during working hours holds a long transaction and competes with document posting — 1C users see the system hang
- Fix
- Change-based exchange (exchange plans or change registration), small batches, and heavy full exports moved to a night window
Duplicates
- What happens
- Redelivery without an external-key check creates a second order document or a second counterparty
- Fix
- Before creating a record, search by GUID or external code — write only after that
Dates and time zones
- What happens
- The 1C server and the web application may live in different zones; a document timestamp without an explicit offset shifts reporting by a day
- Fix
- Transmit time in ISO 8601 with an offset
Reference data drift
- What happens
- Renumbered codes, merged duplicate counterparties, renamed folders — all of this destroys a mapping built on codes and names
- Fix
- One more argument for GUIDs
Exchange reliability: statuses, retries, a log
An integration without observability is an exchange that "seems to work" until accounting finds a month-old discrepancy.
The minimum production level:
- Every message has a status (received, processed, error)
- Message bodies are stored in an exchange log
- Errors show up in monitoring — not just in server logs
Handle errors with retries at increasing intervals, and move messages that exhaust all attempts into a separate queue for review. That way a temporary 1C outage — a configuration update, a nightly backup — does not turn into lost orders: the exchange catches up on its own once the database is available again.
Security: how to expose 1C to the outside
The standard scheme:
- Publish it through a web server
- Put a reverse proxy or API gateway in front
- Open only the specific HTTP service endpoints to the outside — everything else stays closed
- HTTPS is mandatory
- Access is by key or token with rotation
Create a dedicated 1C user for the exchange with minimal rights: only the objects and operations the integration needs. An administrator account in the exchange settings is a standard audit finding and a direct path to leaking the entire database.
A practical sequence of steps
Integrating 1C with a web application is design work first and code second. The sequence that protects you from rework looks like this.
Inventory the flows
Which data, in which direction, with what acceptable delay.
Source of truth
Assign a source of truth for each entity and fix the identifiers (GUIDs plus external keys).
Transport
Choose the simplest sufficient transport for each flow: HTTP services, files, queues.
Data contract
Fields, formats, encoding, version — before the first line of code.
Handlers and log
Idempotent handlers, a status model, an exchange log, and retries.
QA and reconciliation
QA scenarios for redelivery, 1C downtime, and conflicting changes; daily reconciliation after launch.
The timeline and cost of such an integration depend on the state of the configuration, the number of data flows, and the freshness requirements — an estimate is prepared after a brief. The InterLAB team in Almaty designs and builds these exchanges as part of its enterprise systems integration service: from the data contract and 1C-side modifications to the exchange log and monitoring.
