Bitrix24 API Request Logging Setup
Integration stopped working. Data not coming from external system, deals not updating, webhook silent. Developer asks: "Did the request even reach?" — no answer because there are no logs. Without API request logging, debugging integration is guessing. You need to see: what request came, with what parameters, what B24 returned, how long did answer take. Only then you can understand where problem is — on B24 side, integration, or network.
Bitrix24 Event Log
Built-in logging tool — Event Log (Settings → Tools → Event Log). It records system events: authorizations, setting changes, module errors. For API requests, log records:
- REST API errors —
QUERY_LIMIT_EXCEEDED,ACCESS_DENIED,INVALID_TOKEN - Application installation and removal
- Event handler triggering
Limitation: event log does not log successful API calls — only errors and system events. For complete logging, additional tools needed.
Webhook Logging
Webhooks are most popular integration method, and most difficult to debug. Incoming webhook (URL to call B24 from outside) doesn't log calls by default. Outgoing webhook (B24 calls external URL on event) logs result in business process log if webhook called from BP.
For logging incoming webhooks, solution on integration side:
- Proxy logger — intermediate service between external system and B24. All requests pass through proxy, which records request body, headers, B24 response and execution time. Can be implemented on nginx (access log + request body logging) or at application level.
- Middleware in application — if integration written on PHP/Node.js/Python, add middleware that logs each outgoing API request to B24 in file or DB.
REST API Logging (Server Apps)
For server applications (OAuth) in B24 marketplace there is Developers → REST API Call Log section — shows call count, errors, method statistics. Available only for published apps.
For own applications (not from marketplace), logging recommended at HTTP-client level:
| What to log | Example |
|---|---|
| API method | crm.deal.update |
| Parameters | {id: 123, fields: {STAGE_ID: "WON"}} |
| HTTP response status | 200, 503 |
| Response body | {result: true} or {error: "..."} |
| Request time | 2024-01-15 14:32:07 |
| Duration | 340 ms |
Monitoring and Alerts
Logs are useful when analyzed. Recommendations:
-
Error counter — track API error count over last hour. Rise in
QUERY_LIMIT_EXCEEDEDerrors — signal of limit exceedance. Rise inACCESS_DENIED— tokens possibly expired. - Response time — if average API response time grew from 200 ms to 2 s — problem on B24 side (load, maintenance).
- Alerts — notification in Telegram/email when: 5+ errors in row, 0 successful calls over last 30 minutes, daily limit exhausted 80%.
For centralized log collection use ELK (Elasticsearch + Logstash + Kibana) or Grafana Loki. Logs from middleware sent to system where dashboards built and alerts configured.
What We Configure
- Proxy logger for incoming webhooks: recording requests and responses
- Logging middleware for server applications (PHP/Node.js/Python)
- Log structure: method, parameters, status, time, duration
- Connection of logs to monitoring system (ELK, Loki, Grafana)
- Alerts on API errors, limit exceedance, timeouts
- Log rotation and retention policy