I integrate 1C with web services while keeping the accounting system authoritative for its data and preventing external interfaces from depending on the thick client. A typical setup may include an HTTP service or OData in 1C, a TypeScript/Node.js intermediary, a retry queue, and a React or Astro interface. The stack is secondary to an entity map and an unambiguous owner for every field.

Every exchange defines an external identifier such as externalId, a version or modification date, an idempotency key, and repeated-delivery behaviour. Without them, a retry can become a second order and a temporary outage can turn into manual database comparison. Structured logs must identify the object, result, attempt count, and operator action.

Scope depends on ownership of the accounting rules. It may include 1C HTTP services and scheduled jobs, an intermediary API, portal, report, or messenger adapter. Accounting-policy changes, configuration upgrades, and 24/7 server administration are separate. Acceptance uses test entities and failure cases: repeats, missing fields, unavailable peers, and recovery.

An established connector is preferable when both systems and fields are standard and the vendor maintains it. Custom integration is justified for non-standard documents, several sources, special deduplication rules, or a dedicated operations view. For commerce inventory and orders, start with 1C warehouse and order sync.