Documentation lives in Notion, deals and tasks in Bitrix24. A manager closes a deal, then manually goes to Notion to update the project table. A developer records requirements in Notion, then duplicates them into a Bitrix24 task. A month later, both systems show different pictures—versions diverge. Manual copying guarantees desynchronization, and each mistake costs team time. We automate data exchange: two-way synchronization via middleware that eliminates losses and duplicates. Savings on manual operations reach 75% of labor costs, and the integration pays for itself within 2–3 months.
How to set up two-way synchronization between Bitrix24 and Notion?
The connection works through Notion API and Bitrix24 REST API. Notion provides v1 API for working with databases, pages, and blocks. Bitrix24 offers webhooks for subscribing to CRM, tasks, and business process events. Between them is a middleware server on PHP 8.1+ that listens to events from both sides and transmits data. The middleware-based connection is 3 times more reliable than direct REST requests due to error handling and rate limits.
Bitrix24 (CRM/task event) → Webhook → Middleware → Notion API → Database/Page Notion (polling/webhook) → Middleware → Bitrix24 REST API → CRM/tasks Notion API does not yet support native webhooks for tracking changes. Middleware uses polling—querying the Notion database with a last_edited_time filter every 30–60 seconds. For Bitrix24, standard webhooks via event.bind work.
Synchronization of Notion databases with CRM
The main scenario is mirroring CRM records to a Notion database. We configure field mapping:
| CRM Bitrix24 Field | Notion Database Property | Type |
|---|---|---|
| TITLE (deal name) | Name (title) | title |
| STAGE_ID | Status | select |
| OPPORTUNITY | Amount | number |
| ASSIGNED_BY_ID | Responsible | people / rich_text |
| COMPANY_ID → TITLE | Company | rich_text |
| DATE_CREATE | Date created | date |
| UF_* (custom fields) | Custom properties | per type |
When a deal stage changes in Bitrix24 (ONCRMDEALUPDATE event), middleware updates the corresponding entry in Notion via PATCH /v1/pages/{page_id} with the new select property value. In the reverse direction—when the status changes in Notion, middleware calls crm.deal.update.
What difficulties arise when integrating Bitrix24 with Notion?
Rate limits. Notion API limits 3 requests per second per integration. Middleware queues requests and maintains the interval. On 429 Too Many Requests—exponential backoff. Payload size: a maximum of 100 blocks per POST /v1/pages. For large documents, middleware splits content into multiple PATCH /v1/blocks/{block_id}/children.
Data drift. Middleware stores a mapping table b24_entity_id ↔ notion_page_id. On update, it checks the source to avoid loops: Bitrix24 updates deal → middleware sets sync_source = "b24" and updates the Notion page. On next polling, middleware sees the change but compares timestamps—if the update occurred within 10 seconds after the middleware write, it is skipped. For text fields—last write wins strategy; for statuses—configurable priority (master system can be specified).
Comparison of approach with and without middleware
| Criterion | Direct REST requests | Middleware |
|---|---|---|
| Reliability | Low—packet loss | High—queue and retry |
| Errors | Rate limit blocks | Exponential backoff |
| Mapping | Manual in each script | Centralized config |
| Audit | No | Logging of every request |
| Maintenance complexity | High | Low—single component |
Creating pages from CRM events
When an event occurs in Bitrix24, middleware automatically creates a page in Notion with pre-filled content:
- New deal → page in the "Projects" database with client details, amount, responsible. Page body contains a template: sections "Requirements", "Timeline", "Contacts".
- Won deal → page in the "Active Projects" database with automatic transfer of data from the deal card.
- New task → entry in the Notion kanban base linked to the project.
Creating a page is a POST /v1/pages call with parent.database_id and an array of properties. Content is passed as a block array: paragraph, heading_2, to_do, table.
Technical details of batch processing implementation
When synchronizing large volumes (more than 100 records), middleware uses a queue: the list of changes is accumulated and sent in batches with an interval. Each batch is confirmed, on error—repeat after 5 seconds. For Notion, sequential calls with a pause are used since the bulk method is not yet available.
How is data consistency ensured during simultaneous editing?
Middleware uses timestamps: if both sides change the same object almost simultaneously, the last write wins rule applies, with the ability to set a priority system. All conflicts are logged, and the administrator receives a notification. Additionally, manual confirmation mode can be enabled for critical fields.
What is included in the integration setup
- Audit of current processes and data structure (Notion Database, CRM, tasks).
- Prototype middleware on PHP 8.1+ with a proven stack (Laravel or Symfony, PDO, Redis for queues).
- Development of field mapping between CRM and Notion properties.
- Configuration of Bitrix24 webhooks and Notion polling with custom intervals.
- Operational documentation and disaster recovery procedures.
- Team training (1-hour session).
- 2 weeks of post-launch support.
Why trust our team with the integration?
We are engineers with 5+ years of experience in the 1C-Bitrix ecosystem and Notion. We have 50+ successful integrations for companies from the CIS and Europe. We understand how internal mechanisms work: infoblocks, HL-blocks, tagged caching, CommerceML, exchange with 1C. We use only stable middleware versions and test under excessive loads. Order a consultation—we will analyze your data scheme and propose the optimal integration architecture. Contact us to discuss the details of your project.