Integrations · REST API · token service
An internal REST API on top of boxed Bitrix24 with a token service
Client:
Financial company, NDA
Category: Integrations
Stack: PHP 8, Bitrix24 D7, MySQL (separate token DB), Bearer tokens, bcrypt, Postman
Timeline: rolled out in stages
Problem
The CRM was connected to a credit system, a contact center, a mobile app, an AI bot and HR services. Handing each of them Bitrix24 inbound webhooks meant granting broad permissions with no record of who calls what, and no unified response contract.
Constraints
A boxed portal in production with live integrations — existing clients must not break; some endpoints run without the Bitrix core; the rules had to be clear to other teams without calls.
What I did
- A token service: Bearer and refresh tokens in a separate DB, team passwords in bcrypt, an admin panel for issuing and revoking tokens
- 25 endpoints by domain: contacts by IIN and phone, deals and the credit system, contact center, mobile chat, micro-business, HR, leads from the AI bot
- A unified format for success and error responses, an endpoint registry marked SAFE/DANGEROUS, versioning rules and a Postman test plan
- An endpoint scanner for administrators and an API call log as part of the audit trail
- July 2026: closed a token bypass on 6 endpoints — anonymous access is now possible only via an explicit flag in the code
Architecture
External service
→ Bearer token check
→ Call log
→ Domain endpoint
→ Bitrix24 CRM
Result
External teams got documented endpoints with their own tokens instead of portal webhooks: it is visible who called the API, and it is clear in advance what each call changes.
What can be reused
Bearer token service with refresh
Unified API response contract
SAFE/DANGEROUS endpoint registry and scanner