Setting Up Logging for Bitrix24 API Requests

API logging in Bitrix24: where requests get lost

Most often, requests to external services are lost not because of server failure, but because of silent degradation: a response arrived but contained an error; the handler crashed after writing to the database; a retry did not happen.

From the outside, this looks like a data discrepancy — the deal is closed, but there is no invoice in the accounting system.

Data exchange with external systems runs across several loops: instant calls triggered by user action, scheduled background tasks, and bulk exports. Each has its own failure point — background tasks time out, while bulk exports apply only part of a batch.

Without a log, an integration failure is visible only by its consequences, and diagnosing data exchange turns into a blind search.

API logging in Bitrix24 shifts analysis onto facts: the method, entity ID, call time, request and response body, error code and message, and duration are recorded.

A log entry immediately answers whether the call went out, whether it reached the external side, and what it returned.

There is also a flip side: the log grows quickly and contains personal data. That is why we define rules — retention period, truncation of sensitive fields, separate storage — so that records do not take up space on the portal and do not create data protection risks.

This is where managed exchange support begins: first visibility, then elimination of causes and re-running lost operations.

The effect of end-to-end logging: failure analysis and exchange stability

The end-to-end request log links a single user action to an entire chain of calls: an event in Bitrix24 → webhook → REST method → queueing → handler → external system response. Each request is assigned an identifier that goes into our log, the queue record, and the response body.

Using this identifier, the picture is restored in full: what was sent, what was received, how long we waited, and at which step it broke.

Incident analysis time is reduced because manual context assembly disappears. Previously, a complaint that “the export did not arrive” meant going through three sources — CRM logs, the queue server, and the handler — and matching them by timestamps by eye.

Now it is a single query by identifier: call body, headers, response code, processing duration, exception text. Analysis takes minutes and does not depend on which engineer is on shift.

A separate class of “silent” failures that do not produce an explicit error is also covered.

A timeout without a retry, a retry without idempotency that leads to a duplicate entity, a response with a success code but without an actual record change — all of this is visible in the log as a discrepancy between request and result. Such cases used to surface weeks later, once the desynchronization had accumulated.

Integration observability turns from a feeling into a set of measurable values: share of successful calls per method, latency distribution, number of retries, queue depth, number of events waiting longer than usual for processing.

Threshold alerts on these metrics arrive before a user notices the failure — degradation is visible on the chart before the outage.

For support, this changes the very conversation with the client: the argument “is it on your side or on the service side” is closed by exporting the log for a specific request, not by a series of guesses.

Logging options: built-in tools and external collection

The standard event log covers initial diagnostics: you can see which calls to modules and API methods returned an error, and who called them and when.

The limitations of logging appear later — retention depth is fixed, cleanup follows the platform’s general rules, and at a high call rate the log grows faster than it can be read.

Choosing a log collection mode comes down to two questions: how long to store records and what export volume the portal can handle. Below are the options that are actually chosen between.

The common limitation of any mode is the cost of detail: the more fully the request and response are written, the higher the volume and the risk of leakage. Therefore field masking and retention period are set before collection is enabled, not after.

Implementation stages: from exchange audit to handover of regulations

API logging in Bitrix24 is not a switch but a sequence of work where the order of stages matters more than speed. If you start with setup, logs will appear but will not answer the main question: which call led to the data discrepancy and at which step it was lost. That is why we go from exchange inventory to regulations that remain with your team.

1. Audit of integration points. We collect all places where external services are called and all incoming calls: webhooks, applications, exchange with 1C, background jobs. We record access owners and frequency — this determines where logging is needed first.
2. Log collection scheme. We determine where to store records and in what form: who called, which method, time, response code, duration. Here we also set rotation and retention so the log does not fill the disk.
3. Implementation of logging. We embed a single recording point into the call layer without rewriting business logic: the working exchange continues to work, and every request leaves a trace.
4. Testing logging on a real stream. We run it under working load and intentionally break individual calls — we make sure that failures and resends get into the log, not just successful operations.
5. Analysis regulations. We describe how to find the cause of a failure from the log, which events raise an alert, and who reviews accumulated records.
6. Handover of materials. We hand over the collection scheme, configuration, instructions for reading logs, and train the team — support stops depending on us.

Handover package: flow diagrams, retention and access rules

We hand over not an archive of settings but a working package by which your team itself changes detail level, rotates logs, and analyzes incidents without us.

We check each item on a staging environment: your engineer performs an action according to the instructions and gets the expected result.

• Flow map: which Bitrix24 and 1C calls are written to the log, in what order they pass, and where they settle — from the outgoing request to the record in storage.
• Handover of logging settings: profiles for the production loop and debugging, list of recorded fields, detail level for each integration method, procedure for enabling and disabling.
• Log retention rules: timeframes by record type, rotation and archiving, what goes to cold storage and what is deleted, how quickly the needed interval can be found.
• Masking of sensitive data: lists of fields under the mask (tokens, personal data, details), at which step the rule triggers, how it is checked that the mask has not leaked.
• Incident analysis regulations: steps from alert to cause, which slices to pull first, whom to escalate to, and within what time localization is expected.
• Instructions for on-call staff: typical scenarios (“method access error,” “log stopped being updated,” “storage volume grew”) with commands and checkpoints.
• Acceptance checklist: how to make sure logging is enabled on all loops, and how to notice that rules were reset after a module update.

Case study: how exchange with external systems stopped failing

Before logging was implemented, exchange with external systems behaved like a black box: requests did not appear in the accounting system, order statuses did not go back, and the engineer was left with only correspondence with the external service owner and guesses.

Finding the cause took from a day to a week, and half of the requests were closed with the wording “the problem is on the external system side.” The cost was not so much downtime as lost trust in the exchange: managers stopped relying on automation and duplicated data by hand.

We enabled end-to-end call logging in Bitrix24: for each call, the method, request and response body, response code, execution time, and a label linking the chain of calls for one business event are saved.

The log has a retention period, access is restricted, and search by order number, customer ID, and date is added. We separately configured an alert for a spike in unsuccessful responses — the responsible person gets a signal before a manager writes about the failure.

Metrics before and after

Failure localization time dropped from 6–8 hours to 20–30 minutes: the cause is visible in the log without reproducing the situation.

The share of requests analyzed down to the root cause grew from 40% to 95% — the rest are closed with a precise reference to the external side rather than a general wording.

Repeat incidents of the same class of integration almost disappeared: an analyzed cause turns into a validation rule, and the same error does not reach the exchange.

The main effect is not in the volume of records, but in the fact that a failure is no longer an event with an unknown outcome.

The exchange is visible in full, analysis proceeds by facts rather than versions, and support no longer depends on the engineer who “remembers where this broke” last time.

How an event log differs from a full exchange protocol

The event log answers the question “what happened,” while the full exchange protocol answers the question “why it turned out exactly this way.” The log includes call time, method, initiator, object ID, and response code: this is enough to notice a spike in errors and link a failure to a specific exchange, but the content of the requests is not in such a record.

The full exchange protocol adds the request and response body, headers, composition of transmitted fields, and time of each processing step.

From it you can see exactly what went to the adjacent system, which filter was applied, and at which field the response diverged from the expected one. Such volume is needed when analyzing data discrepancies and errors that do not reproduce on the first try.

Choosing the level of detail is a trade-off between storage volume and analysis speed.

A full protocol for all methods around the clock bloats the database and increases the risk of leaking sensitive fields; a brief log without details leaves a picture where the incident is visible but the cause is not.

The working scheme is two-tier: the event log is enabled permanently, and the full protocol is raised selectively — for individual methods, integrations, or an analysis window.

Logging depth is set before exchange starts: each level has its own retention period, its own personal data masking, and its own shutdown procedure.

Then during an incident it is enough to enable detailed mode on the needed segment and return to the usual volume, rather than look for traces in what has already been overwritten.

Technical concerns: retention, load, access

Before enabling log collection in the production loop, the engineering team asks the same questions: will response time drop, who will see the content of requests, and what will happen to archives in six months.

API request logging in Bitrix24 is no exception — all three concerns are addressed by settings, not by abandoning collection.

Below are the answers we give before work starts: they determine the rotation parameters, storage placement, and role model.

Will logging create load on the server?

Recording is asynchronous, in a separate thread, and does not block processing of the requests themselves: if storage is unavailable, the integration continues to work.

Request and response bodies can be written truncated — only metadata and response codes — and the log volume drops several times over.

How is access to logs restricted?

Roles: a developer sees their own integrations, an administrator sees all. Personal data is masked on input, access is granted by account, and exporting the log is a separate permission. Request content does not become common property of the team.

How does archive cleanup work?

By schedule, by age and volume: we keep the last N periods, the rest is deleted automatically. The registry stops growing indefinitely, while rollback to the needed window remains possible.

Let’s discuss the task: we’ll select a scheme for your exchange loop

To come back with an estimate of the scope of work rather than general words, we need initial data on integrations: which exchanges are running now, what exactly breaks, and how you find out about it.

The more accurate the input data, the faster the logging implementation plan turns into concrete steps with owners and timelines.

What is worth sending about your loop:

• List of integrations and exchange direction — 1C, website, external services, custom scripts: who initiates the call and on what schedule it runs.
• How failures are recorded now: files, tables, emails to the administrator, or nothing — this determines whether we extend the log or build from scratch.
• Approximate call frequency and number of objects per day — this is how we calculate load and record volume.
• Requirements for storage and access: how long to keep history, who needs exports, whether there are restrictions on personal data.
• Deployment environment: cloud portal or own server, what access and change approval rules apply.
• Critical exchanges that cannot be stopped even during setup — we will take them into account when choosing the scheme.

Next we compare this against typical failure points and propose a scheme for your case. The output is a stage-by-stage logging implementation plan and an estimate of the scope of work.

Describe the task and send initial data on integrations — we will come back with an estimate and a plan.