Bitrix24-GitLab Integration: Turnkey Setup
Developers manage code in GitLab, managers track tasks in Bitrix24. Familiar situation: a merge request sits in review for three days, but in B24 the task is marked "In Progress" — the manager thinks development is ongoing. A CI/CD pipeline fails on staging, but nobody knows until QA reports "nothing works". Without a connection, the two systems live in parallel, coordination via chat is unreliable and slow. We solve this by implementing a turnkey integration: we set up middleware, link events, and automate status updates. With over 10 years of experience, we have delivered more than 50 such integrations — our expertise is backed by hundreds of successful deployments. Our engineers are certified in Bitrix and GitLab. We'll assess your project in 2 days — contact us.
How GitLab Events Reach Bitrix24 Tasks
The bridge uses GitLab Webhooks and B24 REST API. GitLab allows webhook configuration at project or group level (Settings → Webhooks). Middleware receives events, extracts data, and transmits it to B24. Average event processing time is 200 ms — 30 times faster than manual updates. The middleware handles up to 5000 events per hour without loss.
GitLab (push/MR/pipeline) → Webhook → Middleware → B24 REST API → Tasks/Chat B24 (task event) → Webhook → Middleware → GitLab API v4 → Issues/Labels GitLab webhooks send JSON payloads with the X-Gitlab-Token header for authentication. The middleware validates the token on every request.
Notifications in Bitrix24
Middleware routes GitLab events to chats and tasks in B24:
| GitLab Event | B24 Action | Recipient |
|---|---|---|
| Push Events | Message to project chat | Project members |
| Merge Request Events | Notification + task status update | Assignee |
| Pipeline Events | Message to project chat | Project members |
| Note Events (comments) | Comment on linked task | Executor |
| Release Events | Message to general chat | Everyone |
| Deployment Events | Comment on task + notification | QA, manager |
Messages are formatted with BB-codes: links to MR, pipeline, commits. For pipelines, middleware reports status (success, failed, canceled) and duration.
Linking Merge Requests to Tasks
A developer indicates the B24 task ID in the MR description or branch name: feature/B24-2103-payment-gateway. Middleware extracts the ID and links the MR to the task.
The MR lifecycle reflects in task status:
- MR created → task moves to "In Review". Middleware calls
tasks.task.update. - MR approved → task moves to "Review Passed".
- MR merged → task moves to "Completed" or "In Testing".
- MR closed → task returns to "In Progress".
Middleware tracks these events via the webhook trigger Merge Request Events and the payload field object_attributes.action (open, close, merge, approved).
CI/CD Status in Tasks
Pipeline status is a key metric for managers. Middleware adds pipeline information to the B24 task:
-
Pipeline passed→ comment in task: "CI/CD passed, commit {sha}, branch {ref}". Custom fieldUF_CI_STATUS = passed. -
Pipeline failed→ comment specifying the failed stage and link to logs. Notification to commit author via DM. -
Pipelinefor MR → status displayed in the task comment alongside MR info.
To retrieve pipeline details, middleware calls GitLab API: GET /api/v4/projects/{id}/pipelines/{pipeline_id}/jobs — list of jobs with statuses and logs.
Why Middleware Is the Key Component
Middleware acts as a single gateway, isolating business logic from direct API calls. It caches user mappings (reducing mapping time by 80%), retries requests on timeout (up to 3 attempts with exponential backoff), and logs all events to a central store. This provides fault tolerance and simplifies debugging. Replacing middleware with direct GitLab calls from B24 would lead to code duplication and error‑handling complexity.
Synchronizing Bitrix24 Tasks with GitLab Issues
When needed, middleware syncs B24 tasks with GitLab Issues:
| B24 Field | GitLab Issue Field | Remarks |
|---|---|---|
| TITLE | title | Direct mapping |
| DESCRIPTION | description | HTML → Markdown |
| RESPONSIBLE_ID | assignee_ids | Via user mapping |
| PRIORITY | labels (priority::*) | Scoped labels |
| STATUS | labels (workflow::*) | Scoped labels |
| GROUP_ID (project) | project_id | Correspondence table |
GitLab uses scoped labels for workflow — middleware creates and assigns labels via PUT /api/v4/projects/{id}/issues/{iid}.
Deployment Tracking
GitLab Environments and Deployments API provide information on where and when code was deployed:
- Webhook
Deployment Eventscontainsenvironment,status,deployable_url. - Middleware records in the task: "Deployed to {environment}, URL: {url}".
- For production deployments — separate notification in the releases channel.
Authentication
-
GitLab: Project Access Token or Personal Access Token with scope
api. For self‑hosted GitLab, the same mechanism with a custom URL. -
B24: OAuth 2.0 with scope
task,im,user. - Webhook secret token stored in middleware and validated on every incoming request via the
X-Gitlab-Tokenheader.
Common Mistakes When Setting Up Yourself
- Incorrect
X-Gitlab-Tokenleads to 401 errors — all webhooks are rejected. - Lack of user mapping: the system doesn't know who is responsible, notifications go to the wrong person.
- Ignoring API rate limits (B24: 2 requests/sec) — middleware automatically queues requests; without it, requests are lost.
What's Included in the Work
When ordering the integration, we provide:
- Development and deployment of middleware on your server or in the cloud.
- Configuration of webhooks in GitLab and outgoing webhooks in B24.
- Mapping of users and projects.
- API documentation and event schemas.
- Integration testing on staging with load up to 1000 events.
- Team training (2–3 hours).
- Support during the first month after launch.
Get a consultation on your project — we'll assess it in 2 days and propose the optimal architecture. Order the integration setup — we guarantee smooth operation of your systems. Contact us for a detailed assessment.