Technical support for a Bitrix24 Marketplace app

Technical support for an application in the Marketplace: what breaks

Publishing in the Marketplace seems like the finish line, but for an application owner that is exactly where constant work begins.

The application lives in other people's portals: every client has their own rights, business processes, external services and configured connections, so the same code behaves differently even in similar deployments.

The main source of failures after a platform update is an unexpected contract change.

An event handler that worked fine yesterday stops receiving data in the expected form after the next Bitrix24 core update, and the scenario falls apart without an explicit error: empty fields, duplicate records, silently skipped actions. It is not the developer who notices this, but the client — already on their own production data.

The bottleneck of an integration is almost always at the junction with external systems: synchronization, export, queue.

A failure here grows like an avalanche — one unprocessed record blocks a batch, the batch accumulates retries, and the stream of client requests arrives simultaneously in support and in reviews, where the rating drops faster than the root-cause analysis progresses.

For a product owner, the cost of such a failure is not the hours spent fixing it, but lost installs and reputation: a client whose first launch crashed rarely gives a second chance.

Support for an application in the Marketplace is therefore built on anticipation rather than on handling complaints — below we break down how this is covered: from diagnostics and compatibility checks to the response procedure.

What a dedicated team delivers: the effect in measurable indicators

Handing an application from the Bitrix24 Marketplace over to maintenance changes not the code but the mode of operation: instead of a single author available when they can be, there is a scheduled on-call duty and a response procedure.

We take measurements twice — we monitor the application on the customer's side before the handover and repeat the measurements after it reaches operating mode, so the table contains not estimates but the dynamics of the same metrics.

These areas reinforce each other: the earlier a failure is noticed by monitoring, the shorter the downtime and the fewer requests reach support.

In total, the application moves from the mode of "works while the author is available" to a mode with a predictable response and planned updates.

Engagement formats: on-call duty, hour packages, full cycle

The maintenance format is chosen based on the application's load profile, not the size of the team. One product has a steady flow of installs and questions, another has a spike after a platform update or a Marketplace review.

The difference between the modes lies in who is responsible for the response time and how downtime is covered at the moment of an incident.

Below are four modes that are actually chosen between. They are not mutually exclusive: often an hour package is taken for development and on-call duty for incidents, and as the load grows the client moves to a full cycle.

To propose a mode, we look at the request log and install statistics for previous periods: they show the frequency of spikes and the share of incidents that cannot wait until morning. That is enough to agree on the format and the work plan.

How we implement maintenance: from audit to handover

Support for an application in the Marketplace begins not with on-call duty but with an analysis of how it lives in the client's environment.

Without a map of exchanges and external dependencies, closing tickets turns into guesswork — that is why the order of steps is fixed and the same for all projects.

1. Integration audit. We map the exchanges: which entities go into Bitrix24, what comes back through handlers and webhooks, where the queues are and what depends on external services. Separately, we note the scenarios in which the exchange fails silently.

2. Flow and failure point diagram. We mark the bottlenecks — timeouts, duplicates, export limits, manual administrator actions. Both fixes and on-call duty rely on this diagram later.

3. Test environment. We deploy a copy of the portal with depersonalized data: application updates and handler fixes are tested on it, not on live users.

4. Monitoring. We set up collection of exchange logs and metrics on delays and failed calls — the alert arrives before the user's request.

5. Escalation procedure. We fix priorities, response time and the communication channel, as well as who on the client's side confirms a release into the production environment.

6. Training failure drill. We run an incident from alert to recovery and refine the procedure based on the actual steps.

7. Handover to maintenance. We hand over configurations, the diagram, the decision log and accesses to the on-call shift — from there the work proceeds according to the agreed response times and planned releases.

What remains at the end is not a folder of documents but a working process: a clear exchange diagram, a test environment for changes and an on-call shift that knows the order of actions when an exchange fails.

The set of documentation and procedures at handover

The documentation set is assembled in the course of the work, not in the last week before handover — otherwise it describes intentions rather than the actual state of the application. Below is the list of artifacts that remain with the customer and are updated with every release.

• Integration diagrams — external services, queues, webhooks and outgoing requests, failure points and the degradation order if an external system is unavailable.
• Roles and access rights — the portal role matrix, the application's permission sets and token lifetimes, who can change what in the production environment.
• Maintenance documentation — extension points, core overrides, background tasks and agents, the migration order and the list of places that must not be edited.
• Recovery instructions — step-by-step rollback of an update, application reinstallation, actions for data desynchronization and contacts of the external system owners.
• Change log — what changed from release to release and why, which updates broke compatibility and how it was fixed.
• Release procedure — branches, the test portal, the rollout order to the production environment and the conditions for an urgent fix.
• Escalation order — criticality levels, response times and the list of tasks that support resolves without approval.

Such a set removes the main problem of handover: support does not reconstruct the application's logic from the code.

A new engineer or your team finds the answer to "why was it done this way" and "what to do in case of a failure" in minutes instead of days of digging.

Case study: how we eliminated the request flow after a platform update

We received an application from the 1C-Bitrix Marketplace — an integration with an external service and several thousand installs. There was no test environment, and no one kept a list of dependencies on the platform either.

After another update, support was hit with a flow of requests: the application failed for some clients, and every investigation started from scratch.

What the requests showed

We analyzed the statistics for a quarter: the first response averaged almost two days, about a third of the requests were repeat ones, for the same failure.

The bulk came from a single class of failures: an unprocessed response from the external service brought down the background task entirely, and support was putting out the consequences instead of the cause.

What we changed and what we came out with

We assembled a separate environment on data close to production, and checks that on every release run the installation, update and disabling of the application — those were exactly the paths that produced the most failures.

External calls were rewritten to retry with a delay and a clear message instead of the task crashing. Before platform updates we compare the calls in use against the changelog and ship a replacement before the old capability is disabled.

• first response on critical requests — hours instead of a day;
• the share of repeat requests dropped by roughly three times: an investigation ends with a fix, not a temporary workaround;
• the class of failures caused by unprocessed external service responses disappeared from the visible part of the application;
• the next platform update passed without a spike in requests.

How does application support differ from one-off improvements?

A one-off improvement ends with acceptance: the task is closed, the build is deployed, the report is delivered.

But the application continues to live in someone else's environment — the platform updates, Bitrix24 Marketplace requirements for permissions and moderation change, users come up with new scenarios. Ongoing maintenance is needed because nothing freezes after a release.

Application support is work that does not change requirements: monitoring availability, handling requests, reproducing failures in the test environment, shipping fixes and preserving the ability to roll back to the previous build.

It also includes checks after platform updates — some failures only appear on new versions of the environment, and finding them on your side is cheaper than receiving them from users.

The boundary between application support and improvements runs along requirements, not along the size of the fix. If the work restores the declared behavior, it is maintenance: a calculation error, a broken exchange, an incorrect response after a format change.

If the behavior changes — a new scenario, field, role, integration, permission extension — a separate task is created with a description, an estimate and acceptance.

Mixing the streams is unprofitable: improvements crowd out the procedural work, failures wait in a shared queue, and maintenance turns into a set of one-off requests.

That is why we keep a work log, maintain a separate change queue and follow a priority rule: a critical failure is handled out of the improvement queue. The share of requests closed without shipping new functionality and the response time show how stable the application is.

Frequently asked questions about maintenance and access

Support for an application in the Marketplace is not just code. Most of the questions before the start are about access to the production environment, boundaries of responsibility and reaction to changes in the platform's rules. Below are answers to the technical doubts that customer teams raise most often.

Who is responsible for a failure — the platform or the application?

We separate by source. If Bitrix24 fails — unavailability of events or exhaustion of call limits — we show this through logs and metrics, and the application continues to work in a degraded mode.

If the cause is in our code, diagnostics proceed by priority: recovery first, root-cause analysis after.

What if the Marketplace changes the rules?

We track moderation requirements and the platform's procedures, and compare the set of requested permissions with those actually used. A mismatch is a common reason for rejection during an update.

Improvements for new rules are estimated separately and put into the plan; the version in the test environment and in the publication are synchronized.

What does the work look like during a critical failure?

The on-call engineer receives the alert and confirms the problem within the agreed response window. Builds are versioned, the previous stable image is preserved — rollback takes one step, without a rebuild.

After recovery we send an analysis: what broke, why it was not caught earlier, which check covers this class of failures.

Let's discuss the task and come back with an estimate and a plan

If the application is already published in the Marketplace, half of the picture is provided by its operational history: client requests, failures after core updates, downtime.

To discuss the task substantively rather than in general terms, it is useful to gather for the conversation:

• access to the application card and the developer portal rights — we immediately see versions, licenses and the publication history;
• an export of support requests for several months and the error log — they show where it breaks most often;
• the list of interface embeds and event handlers that are currently running;
• the exchange diagram with 1C and external services: which methods are called and with what load;
• the release procedure: how a version is prepared and what is checked before publication;
• the list of things that have already had to be rolled back, and for what reason;
• the contact of the person on your side who makes product decisions.

Based on this data we fix the estimate and the work plan: what we cover first, which response and recovery times we commit to, in what order we ship versions.

In parallel we agree on the composition of the maintenance team — a first-line on-call engineer, a developer for the application core, and a person responsible for releases and pre-publication checks.

Describe the task and send whatever you already have at hand — we will come back with an estimate, a work plan and a proposal for the team composition.