Bitrix24-Jira Integration
If your managers use Bitrix24 for planning and developers rely on Jira for execution, data inevitably diverges. Tasks are duplicated, statuses mismatch, and managers constantly switch between systems. Our middleware synchronizes both environments in real time: changes in Bitrix24 instantly reflect in Jira and vice versa. With over 5 years of Bitrix24 integration experience, we provide a reliable solution with zero data loss. The integration works for any version: cloud and on-premise Bitrix24, Jira Cloud, Server, and Data Center.
How Synchronization Works
The integration is built on bidirectional exchange via REST APIs of both systems. The middleware processes events and transforms data from one system's format to the other. A mapping table links task and user IDs — without it, the systems cannot communicate.
B24 Task → Webhook → Middleware → Jira REST API → Issue Jira Issue → Jira Webhook → Middleware → B24 REST API → Task Field Mapping
Fields differ between systems. The middleware translates them according to predefined rules.
| Bitrix24 Field | Jira Field | Notes |
|---|---|---|
| TITLE | summary | Direct mapping |
| DESCRIPTION | description | HTML ↔ ADF conversion |
| RESPONSIBLE_ID | assignee | Via user mapping table |
| CREATED_BY | reporter | Same |
| DEADLINE | duedate | ISO 8601 date format |
| PRIORITY | priority.id | Value mapping |
| STATUS | status.id | Configurable mapping table |
| GROUP_ID | project.key | Project to project |
| UF_* | customfield_* | Custom per project |
Description conversion is non‑trivial. Bitrix24 stores descriptions as HTML, Jira uses ADF (a JSON tree). The middleware parses HTML, converts it into ADF nodes, and vice versa.
Why Loop Happens and How to Avoid It
If the source is not tracked, an update from one system triggers an update in the other — infinitely. We solve this by marking: the middleware writes a flag UF_SYNC_SOURCE = "jira" to the Bitrix24 task or customfield_sync_source = "b24" to the Jira issue. Upon receiving a webhook, the middleware checks the flag and skips its own updates. The flag is cleared after 5 seconds by a cron job.
Status Mapping
Jira workflows and Bitrix24 stages are unique to each team. The middleware uses a configurable mapping table:
| Bitrix24 Status | Jira Status | Direction |
|---|---|---|
| New (2) | To Do | ↔ |
| In Progress (3) | In Progress | ↔ |
| Awaiting Control (4) | In Review | B24 → Jira |
| On Hold (6) | On Hold | ↔ |
| Completed (5) | Done | ↔ |
| — | QA Testing | Jira → B24 |
Jira transitions require calling POST /rest/api/3/issue/{id}/transitions with the specific transition ID. The middleware fetches available transitions and executes the appropriate one.
Webhook Subscriptions
On the Bitrix24 side, we register handlers via event.bind (see Bitrix24 REST API):
-
ONTASKADD— new task → create issue -
ONTASKUPDATE— update → update issue -
ONTASKCOMMENTADD— comment → comment on issue -
ONTASKDELETE— deletion → close/delete issue
On the Jira side, via system webhooks:
-
jira:issue_created→ new Bitrix24 task -
jira:issue_updated→ update task -
comment_created→ comment on task
Each webhook carries a full payload. The middleware extracts changed fields from changelog.items (Jira) or compares with a stored copy (Bitrix24, where changelog is unavailable).
Comment Synchronization
Comments are passed both ways with author attribution. From Bitrix24 to Jira: POST /rest/api/3/issue/{id}/comment with ADF conversion. From Jira to Bitrix24: task.commentitem.add with an author name prefix. Attachments are downloaded and uploaded via file APIs.
Initial Migration
Before enabling sync, we migrate existing tasks. A utility exports data from Bitrix24 in batches via tasks.task.list, creates issues in Jira using bulk API, then performs reverse export. After migration, webhooks are enabled for real‑time sync.
Concrete Case
On a project for a mid‑sized software company, we integrated 12 Bitrix24 projects with 8 Jira projects. The team had 30+ custom fields and complex workflow with 10 statuses. After implementing our middleware, task duplication dropped to zero, and status mismatch was eliminated. The daily time spent on manual synchronization (about 2 hours per project manager) was cut down to zero. The integration handled up to 500 task updates per hour without any delays.
What Our Work Includes
- Middleware deployment on your server or cloud
- Field and status mapping tailored to your workflow
- Integration with authorization systems (OAuth 2.0, tokens)
- Comment and attachment synchronization
- Loop protection
- Initial task migration
- User mapping between systems
- Monitoring and logging
- Documentation and team training
- Integration warranty
Timelines and Pricing
Basic integration setup takes 3 to 7 days. The duration depends on mapping complexity, number of fields, and required customizations. Cost is calculated individually after project assessment — reach out to us, and we'll send you a commercial proposal within 24 hours.
Automatic synchronization reduces data duplication effort by 10 times compared to manual entry. The project pays for itself within the first months of use. Our experience — over 5 years and 15+ Bitrix24 integration deployments — confirms the reliability of the solution. Contact us to discuss your task.