Why the Standard Event Log Isn't Enough
An integration stops working. Data doesn't arrive from an external system, deals aren't updated, the webhook stays silent. A developer asks, "Did the request even reach the server?"—and there's no answer because there are no logs. Without API request logging, debugging an integration becomes guesswork. We've encountered this dozens of times. Our engineers offer turnkey API request logging: proxy logger, middleware, monitoring, and alerts. We evaluate your project within one day and guarantee transparent debugging. You need to see: what request came in, with what parameters, what Bitrix24 returned, and how long the response took. Only then can you pinpoint the problem—whether it's on the Bitrix24 side, the integration side, or the network. This approach cuts diagnosis time from hours to minutes.
The Limitations of the Built-In Event Log
The built-in Event Log (Settings → Tools → Event Log) records system events: logins, configuration changes, module errors. For API requests, it captures:
- REST API errors —
QUERY_LIMIT_EXCEEDED,ACCESS_DENIED,INVALID_TOKEN - Application installation and removal
- Event handler triggers
Limitation: the event log does not log successful API calls—only errors and system events. For full logging, additional tools are required.
Logging Incoming and Outgoing Webhooks
Webhooks are the most popular integration method, and the hardest to debug. Incoming webhooks (URLs that call Bitrix24 from outside) are not logged by default. Outgoing webhooks (Bitrix24 calls an external URL on an event) are logged in the business process log only if triggered from a BP.
For incoming webhooks, the solution is on the integration side:
- Proxy logger — an intermediary service between the external system and Bitrix24. All requests pass through the proxy, which records the request body, headers, Bitrix24 response, and execution time. It can be implemented on nginx (access log + request body logging) or at the application level. A proxy logger provides 90% more information than the event log.
- Middleware in the application — if the integration is written in PHP, Node.js, or Python, add middleware that logs every outgoing request to the Bitrix24 API to a file or database.
For server applications (OAuth) in the Bitrix24 Marketplace, there is a section "Developers → REST API Call Log" that shows call counts, errors, and method statistics. It is only available for published applications.
For custom applications (not from the marketplace), we recommend logging at the HTTP client level:
| What to Log | Example |
|---|---|
| API method | crm.deal.update |
| Parameters | {id: 123, fields: {STAGE_ID: "WON"}} |
| HTTP status | 200, 503 |
| Response body | {result: true} or {error: "..."} |
| Request time | 2024-01-01T12:00:00Z |
| Duration | 340 ms |
Comparison of Logging Methods
| Method | Detail Level | Complexity | Recommendation |
|---|---|---|---|
| Event log | Errors only | Low | Quick diagnostics |
| Proxy logger | Full | Medium | Incoming webhooks |
| Middleware | Full | Medium | Server applications |
| REST API call log | Statistics | Low | Marketplace apps |
Monitoring and Alerting
Logs are only useful when analyzed. Recommendations:
-
Error counter — track the number of API errors in the last hour. A rise in
QUERY_LIMIT_EXCEEDEDindicates exceeded limits. A rise inACCESS_DENIEDsuggests token expiry. - Response time — if the average response time jumps from 200 ms to 2 seconds, the problem is likely on the Bitrix24 side (load, maintenance).
- Alerts — send notifications via Telegram/email when: 5+ consecutive errors occur, 0 successful calls in the last 30 minutes, or the daily limit is 80% exhausted.
For centralized log collection, we use ELK (Elasticsearch + Logstash + Kibana) or Grafana Loki. Logs from middleware are sent to the system where dashboards and alerts are configured.
Example log structure
{ "method": "crm.deal.get", "params": {"id": "123"}, "response": {"result": {}}, "time": "2024-01-01T12:00:00Z", "duration_ms": 340 } What's Included in Our Service
- Setup of a proxy logger for incoming webhooks: recording requests and responses
- Middleware logging for server applications (PHP, Node.js, Python)
- Structured logs: method, parameters, status, time, duration
- Connection of logs to a monitoring system (ELK, Loki, Grafana)
- Alerts for API errors, limit overruns, timeouts
- Log rotation and retention policy
- Documentation and team training
Our Process and Timelines
- Data gathering — understand your integration flow and logging needs.
- Analysis — identify all API call points (incoming webhooks, outgoing requests, scheduled tasks).
- Design — choose the appropriate tools (proxy logger, middleware, or both).
- Estimation — provide a fixed price based on complexity.
- Implementation — deploy logging infrastructure.
- Testing — verify that all calls are logged correctly.
- Launch — go live with monitoring and alerts.
Timelines:
- Basic logging (proxy logger or middleware): 1–2 days
- With monitoring and alerts: up to 3 days
A Real-World Case: Cutting Debug Time by 90%
On a recent project with a high-traffic CRM integration, the client was spending up to 8 hours debugging failed webhooks. After implementing a proxy logger with structured logs and Grafana dashboards, they could identify issues in under 15 minutes. The key was seeing the actual request payload and response side-by-side. This reduced the average time to resolve integration incidents from hours to minutes.
With over 10 years of Bitrix24 experience, we guarantee a transparent and maintainable logging system. Contact us to discuss your project and get a consultation within 24 hours.