Developing Bitrix24 Integration with Marketplaces
Integration of Bitrix24 with Ozon, Wildberries, or Yandex Market is needed by companies that use CRM to manage customers and want to see marketplace orders in a single space. The typical problem: a manager works in Bitrix24, but views order data in the marketplace's personal account in a different tab. Integration eliminates this gap.
What Gets Integrated and Why
Bitrix24 is primarily a CRM and team collaboration tool, not a full-fledged e-commerce platform. So integration with marketplaces solves specific tasks:
Orders → CRM. Each marketplace order is created as a deal (crm.deal.add) or lead in Bitrix24. The manager sees the order, processes it, calls the customer — all within the CRM. Statuses sync in both directions.
Notifications. When a new order arrives or its status changes — notification to the responsible manager via im.notify.system.add or through a task/deal in the CRM.
Analytics. Data about marketplace sales goes into CRM reports. You can see the funnel by source, compare marketplaces with each other.
Communications. Messages from marketplace buyers (where the marketplace provides an API for correspondence, like Ozon) — in the activity stream of the deal in Bitrix24.
Architecture: Middleware Service
Bitrix24 and the marketplace are two independent APIs. There's no direct way to connect them. You need an intermediate service (middleware) that:
- Listens to webhooks from the marketplace (new orders, status changes)
- Translates marketplace data into Bitrix24 REST API format
- Creates/updates entities in Bitrix24 via REST
- In reverse: when a deal status changes in Bitrix24 — updates the order status on the marketplace
This service is a separate application that can be:
- Deployed as your own server (PHP/Node.js/Python)
- Formalized as an application for the Bitrix24 marketplace (then it's available to other users)
- Use ready-made no-code connectors like n8n/Make (for simple scenarios)
For serious load (hundreds of orders per day) you need your own service with queue and retry logic.
Data Mapping: Deal vs Order
The data from a marketplace order doesn't match the deal fields in Bitrix24 CRM. Mapping is needed:
| Marketplace Order Field | Bitrix24 CRM Field |
|---|---|
| order_id | UF_CRM_DEAL_* (custom field) or TITLE |
| buyer name / email | crm.contact (find or create) |
| product list | crm.deal.productrows.set |
| total_price | OPPORTUNITY |
| status | STAGE_ID (status mapping) |
| marketplace name | SOURCE_ID or custom field |
| created_at | DATE_CREATE |
| delivery address | CONTACT.ADDRESS or custom field |
Status mapping is a separate task. Marketplace statuses and Bitrix24 deal funnel stages need to be explicitly mapped in the integration configuration.
Working with Contacts: Deduplication
One buyer can place orders from different marketplaces and directly on the website. When creating a contact in Bitrix24, check for duplicates via crm.duplicate.find.by.comm (search by email/phone). If the contact already exists — link the deal to it, don't create a new one.
On marketplaces, buyer personal data is often hidden (WB doesn't expose email, Ozon — only on request). In this case, the external buyer ID on the marketplace is used as an identifier, stored in a custom contact field.
Status Synchronization
Reverse synchronization (Bitrix24 → marketplace) is needed when a manager changes the deal stage and it should reflect in the marketplace personal account. This works through:
- Subscription to the
ONCRMDEALUPDATEevent in Bitrix24 - When
STAGE_IDchanges — check if the deal is a marketplace order (by custom fieldUF_MARKETPLACE_SOURCE) - Call the appropriate marketplace API to update the status
For WB this is /api/v3/orders/{orderId}/status, for Ozon — /v3/posting/fbs/status/set. Not all statuses are available for external modification — marketplaces only allow transitioning orders from certain states to certain states.
Product Catalog: Is Synchronization Needed
Some companies want not just orders but also catalog synchronization: products from Bitrix24 (or from the website on Bitrix) should automatically upload to the marketplace. This is a separate, larger task (see 1C-Bitrix integration with marketplaces).
In the context of Bitrix24, the product catalog (crm.product.*) is often used for CRM products, not as a full-fledged e-commerce catalog. If the catalog is maintained there — synchronization is possible, but requires non-trivial mapping to marketplace attributes.
Development Timeline
| Scenario | Timeline |
|---|---|
| One marketplace, orders only → leads/deals in CRM | 3–5 weeks |
| One marketplace, bidirectional status synchronization | 5–8 weeks |
| Two marketplaces, common CRM integration with notifications | 8–12 weeks |
| Full cycle: orders + catalog + analytics, multiple marketplaces | 14–20 weeks |
Ready-Made Solutions and Their Limitations
The Bitrix24 marketplace has several connector applications for Ozon and WB. They cover basic scenarios and cost significantly less than custom development. Limitations: fixed mapping logic, inability to add non-standard fields, dependency on the application vendor's updates.
Custom development is justified when: specific order processing logic, integration with multiple systems simultaneously (marketplace + 1C + warehouse), reliability requirements higher than ready-made applications can provide.