Setting up Bitrix24 integration with GitHub

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
8+Years of work900+Completed projects100+In house employees19+Partners
Offered services
Showing 1 of 1 servicesAll 1626 services
Setting up Bitrix24 integration with GitHub
Simple
~1 business day
FAQ
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1177
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    747
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976
Show more works

Setting up Bitrix24 Integration with GitHub

A manager asks for task status — developer says "in review." Manager doesn't understand what that means and goes to B24, where the task is still "In Progress." The pull request in GitHub is already merged, but the task won't close until the developer remembers. Between code and tracker — a manual bridge that breaks every day. Integration removes this bridge and connects commits, PRs, and deploys to B24 tasks directly.

Integration Architecture

The integration uses GitHub Webhooks and B24 REST API. GitHub sends POST requests on repository events. Middleware receives these requests, extracts data, and translates them to B24.

GitHub (push/PR/issue) → Webhook → Middleware → B24 REST API → Tasks/Chat
B24 (task event) → Webhook → Middleware → GitHub API → Issues/Labels

GitHub Webhooks are configured at the repository (Settings → Webhooks) or organization level. Content type — application/json. Each webhook is signed with HMAC-SHA256 via secret — middleware validates the signature.

Commit and PR Notifications in B24 Chat

Middleware routes GitHub events to B24 channels:

GitHub Event B24 Channel Message Format
push Project chat Author, branch, commit list with links
pull_request.opened Project chat PR name, author, branch, link
pull_request.merged Project chat + notification to responsible PR merged, who merged it
pull_request_review DM to PR author Review result: approved/changes_requested
issues.opened Project chat New issue, author, text
release.published General chat / releases channel Version, changelog, link

Messages are sent via im.message.add with BB-code formatting. Links to PRs and commits are clickable.

Linking Commits to Tasks

A developer specifies the B24 task ID in a commit message: fix: resolve layout issue [B24-1542]. Middleware parses the commit message, extracts the ID, and performs actions:

  • Adds a comment to the task via task.commentitem.add with commit text, author, and diff link.
  • If the commit contains keywords (close, fix, resolve), middleware can automatically move the task to "Completed" status.
  • All commits linked to a task are visible in the comment history — manager understands what's happening with the code.

Status Synchronization via PR

Pull request is the main trigger for updating task statuses:

  1. PR opened → task moves to "Under Review" status (tasks.task.update with new STATUS).
  2. PR gets approve → task moves to "Review Passed" (custom status).
  3. PR merged → task moves to "Testing" or "Completed" (configurable).
  4. PR closed without merge → task returns to "In Progress."

Middleware determines the task by branch name (for example, feature/B24-1542-user-auth) or from PR description text.

Deploy Tracking

GitHub Actions or other CI/CD systems send deployment_status events. Middleware translates them to B24:

  • Deploy to staging → comment in task: "Deployed to staging, link: {url}."
  • Deploy to production → notification in general chat + update task custom field UF_DEPLOY_DATE.
  • Deploy failed → notification to responsible with error log.

This lets managers and QA see when a feature is ready for testing, without chat questions.

Feedback: B24 Tasks → GitHub Issues

When a task of a certain type is created in B24, middleware automatically creates an issue in GitHub via POST /repos/{owner}/{repo}/issues. Mapping:

  • Task name → issue title
  • Description → body (HTML converted to Markdown)
  • Priority → label (priority:high, priority:medium)
  • B24 project → repository (via mapping table)

Reverse update: when an issue closes in GitHub, middleware closes the task in B24.

Security

  • GitHub: webhook secret to verify signature. API requests — via Personal Access Token or GitHub App (Installation Token with limited permissions).
  • B24: OAuth 2.0 with scope task,im,user.
  • Middleware checks X-Hub-Signature-256 header on each webhook. Invalid requests are rejected.

What We Implement

  • Middleware connecting GitHub repositories to B24 tasks and chats
  • Notifications about commits, PRs, and releases in B24 chats
  • Automatic commit linking to tasks by ID in commit message
  • Task status updates across PR lifecycle
  • Deploy tracking with B24 notifications
  • Bidirectional sync between B24 tasks and GitHub Issues
1C Bitrix presentation1C Bitrix24 presentation1C Enterprise presentation