Technical support for the Bitrix24 marketplace app

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1173
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    745
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

Technical Support of Application in Bitrix24 Marketplace

After publishing an application in the marketplace, its operational life begins: user requests, incidents from Bitrix24 API changes, token expiration, conflicts with portal updates. Without organized support, the app rating will fall due to negative reviews.

What Breaks in Published Applications

Expired tokens. refresh_token lives for 180 days. If a user hasn't opened the application for six months — the token expired, re-authorization is impossible without manual intervention (reinstall or forced re-auth). Need monitoring of tokens by expires_at and proactive notification.

Bitrix24 REST API changes. 1C-Bitrix periodically deprecates methods: deprecated warning in documentation appears months ahead, but deactivation can be abrupt. Subscription to changelog dev.bitrix24.ru is mandatory.

Placement unavailability. If Bitrix24 changes interface structure, placement points can move or change context. Users see an empty tab or error.

Errors in specific portals. Non-standard portal configuration, custom user permissions, non-standard CRM statuses — all this causes errors only for some users. Without proper logging bound to member_id diagnosis takes hours.

Support Organization

Minimum set for supporting a published application:

  • Error monitoring — Sentry or equivalent with grouping by member_id and error type. Alert when error threshold exceeded in 15 minutes
  • API call logging — all calls to Bitrix24 REST with response code, execution time, member_id
  • Failed tasks queue — tasks with error status displayed in support dashboard with ability to restart
  • Requests channel — email, website form or chat, with SLA: response within 24 hours, critical incident resolution within 4 hours

Support works better if each user request contains the member_id of the portal — this ties the ticket to specific logs and tokens.

Planned Work

Besides reactive support — regular maintenance tasks:

  • Weekly check of Bitrix24 REST API changelog
  • Monthly check of expiring tokens (30 days before expires_at)
  • Monitor rating and new reviews in marketplace — respond publicly within 48 hours

Response time to critical incident (application won't open for all users): up to 2 hours during business hours.