How Bitrix24 and Redmine Synchronization Works

How Bitrix24 and Redmine Synchronization Works

Part of your team works in Redmine — they're used to it, have their workflow tuned, and don't want to migrate. The other part sticks with Bitrix24 because it has CRM, telephony, and chats. The result: tasks get duplicated manually, statuses diverge, and when you need to compile a project report, you have to open both systems and merge data in a spreadsheet. Our engineers — certified specialists with 10+ years of experience — offer a turnkey solution: middleware for bidirectional synchronization. You stop wasting time on manual transfers and get a unified view of your project. Evaluate your project: write to us, and we will prepare a work plan within one day.

Integration Architecture

The integration works via Redmine REST API and Bitrix24 REST API. Redmine provides JSON/XML API for managing issues, projects, users, and time entries. Redmine does not have built-in webhooks — the middleware uses polling to track changes.

Bitrix24 (task event) → Webhook → Middleware → Redmine REST API → Issue Redmine (polling) → Middleware → Bitrix24 REST API → Task 

Polling works as follows: the middleware every 30–60 seconds requests GET /issues.json?updated_on=>=<last_check_time>&status_id=* — it retrieves all issues updated since the last check. For Bitrix24, standard webhooks via event.bind are used.

Field Mapping

Redmine uses Textile (by default) or Markdown for descriptions. The middleware converts HTML from Bitrix24 to the required format: headings, lists, links, and emphasis.

Why Status Mapping Matters

Redmine allows arbitrary statuses and transitions (workflow). The middleware supports flexible mapping:

Critical nuance: Redmine validates allowed status transitions via workflow. Before updating, the middleware requests available transitions and performs intermediate steps if a direct transition is not possible.

Custom Fields

Redmine heavily uses custom fields. The middleware supports mapping arbitrary fields:

• Text (string/text) ↔ UF_CRM_* string fields in Bitrix24.
• List ↔ select fields in Bitrix24. The middleware maps values by ID or name.
• Numeric (int/float) ↔ numeric fields in Bitrix24.
• Date ↔ date fields in Bitrix24.
• Boolean (bool) ↔ checkboxes in Bitrix24.

Mapping configuration is stored in the middleware and editable via an admin panel.

Project Synchronization

Redmine projects are mapped to Bitrix24 projects (groups):

The Redmine tracker (Bug, Feature, Support) determines the task type. The middleware can map the tracker to a tag or custom field in Bitrix24.

Linking Tickets to Tasks

The middleware stores a mapping table b24_task_id ↔ redmine_issue_id. When a task is created in one system, a corresponding entry is automatically created in the other. The synchronization criterion is membership in a mapped project.

Comments (journals in Redmine) are synchronized bidirectionally:

• From Redmine: the middleware parses journals with notes during polling and creates comments in the Bitrix24 task.
• From Bitrix24: upon the ONTASKCOMMENTADD event, the middleware calls PUT /issues/{id}.json with the notes field.

Initial Migration

Before enabling synchronization, the middleware transfers existing data:

1. Export issues from Redmine via GET /issues.json?project_id={id}&limit=100&offset={n}.
2. Create tasks in Bitrix24 via tasks.task.add with full field mapping.
3. Reverse export tasks from Bitrix24 that do not exist in Redmine.
4. Populate the mapping table.

What's Included in the Work

• Ready-to-use middleware configured for your projects
• Mapping of statuses, fields, trackers, and custom attributes
• Migration of task history and comments
• Testing and debugging of synchronization
• Operation documentation and team training
• 1-month warranty support

Unlike custom scripts, our solution handles status conflicts and data duplication automatically. Over 50 successful Bitrix24 integrations confirm the reliability of the approach. Contact us for a consultation and accurate project estimate.

How the Middleware Handles Synchronization Conflicts?

Conflicts arise when the same task is simultaneously modified in both systems. The middleware uses a "last-write-wins" rule with timestamps. For each update, the middleware compares updated_on from Redmine and CHANGED_DATE from Bitrix24. If the difference is less than 5 seconds, the task is flagged for manual resolution — the administrator receives a notification. This minimizes data loss risk. In our practice over the course of operation, less than 0.5% of updates caused conflicts, and all were resolved automatically.