Setting up Bitrix24 integration with Redmine

Bitrix24 and Redmine Integration Setup

Part of the team works in Redmine — familiar with it, configured workflow, doesn't want to migrate. Another part in Bitrix24 because of CRM, telephony and chats. Result: tasks duplicated manually, statuses diverge, and when trying to compile project report, you need to open both systems and reconcile data in a spreadsheet. You can connect Redmine and B24 via API and stop wasting time on manual transfer.

Integration architecture

Connection works through Redmine REST API and B24 REST API. Redmine provides JSON/XML API for working with issues, projects, users and time records. Redmine has no built-in webhooks — middleware uses polling to track changes.

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

Polling works: middleware every 30–60 seconds requests GET /issues.json?updated_on=>=<last_check_time>&status_id=* — gets all issues updated after last check. For B24, standard webhooks are used via event.bind.

Field mapping

Redmine uses Textile (by default) or Markdown for descriptions. Middleware converts HTML from B24 to needed format: headings, lists, links, emphasis.

Status mapping

Redmine allows creating custom statuses and transitions (workflow). Middleware supports flexible mapping:

Important nuance: Redmine checks allowed status transitions via workflow. Middleware before updating requests available transitions and performs intermediate steps if direct transition is impossible.

Custom fields

Redmine actively uses custom fields. Middleware supports arbitrary field mapping:

• Text (string/text) ↔ B24 string UF_CRM_* fields.
• Lists ↔ B24 select fields. Middleware maps values by ID or name.
• Numeric (int/float) ↔ B24 numeric fields.
• Date ↔ B24 date fields.
• Boolean ↔ B24 checkboxes.

Mapping configuration stored in middleware and edited through admin panel.

Project synchronization

Redmine projects map to B24 projects (groups):

Redmine tracker (Bug, Feature, Support) defines task type. Middleware can map tracker to tag or custom field in B24.

Ticket linking

Middleware maintains mapping table b24_task_id ↔ redmine_issue_id. When task created in one system, paired task automatically created in other. Sync criterion — belonging to mapped project.

Comments (journals in Redmine) sync both ways:

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

Initial migration

Before enabling sync, middleware transfers existing data:

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

Authentication

• Redmine: API Key (My Account → API access key). Passed in header X-Redmine-API-Key. API must be enabled in Administration → Settings → API.
• B24: OAuth 2.0 with scope task,user.
• Middleware stores keys encrypted. For self-hosted Redmine — middleware must have network access to server.

What we implement

• Middleware for bidirectional sync of B24 tasks and Redmine tickets
• Polling mechanism for tracking changes in Redmine
• Field, status, priority and custom field mapping
• Comment synchronization between systems
• Project and tracker mapping
• Initial migration of existing data