Certification of Application for Bitrix24 Marketplace
The term "certification" in the context of the Bitrix24 marketplace is passing an official check of the application by the 1C-Bitrix team before publication in the catalog. This is not receiving a separate certificate document, but a process of technical and content review, after which the application receives "Approved" status and becomes available for installation.
What the Bitrix24 Team Checks
The review is conducted on several fronts, and understanding the criteria allows you to prepare in advance and avoid iterations.
Technical criteria:
OAuth flow correctness. All scenarios are checked: installation, uninstallation, reinstallation after deletion. The application must correctly store and update tokens, should not crash with expired access_token — only silently refresh via refresh.
Requested scopes. Each declared scope (crm, tasks, disk, im, user, etc.) must actually be used. Extra scopes — direct reason for rejection. The reviewer opens the permissions list on install and looks: if the application requests disk and telephony but the description says nothing about files and calls — question is guaranteed.
Security. Token transmission is checked: they must not appear in URLs (GET parameters), logged in browser console, transmitted to localStorage in unencrypted form for sensitive operations. HTTPS is mandatory everywhere, including all application CDN resources.
Error resilience. The reviewer tests the application on a portal with minimal user permissions. If the app shows a blank screen with a 403 error in console when there's no CRM access — rejection. Must be a clear UI response: "Application requires CRM access to work".
Rate limit handling. Applications that call API in a loop without delays on open get a notice. Caching and pagination presence is checked.
Content criteria:
Description matches functionality. The reviewer installs the application and compares with the description. Declared functions must work. Screenshots must match the current interface.
Localization quality. For publication in the Russian marketplace the interface must be in Russian. Machine translation with obvious errors — notice.
Icon and promotional materials. Icon 128×128px, without using Bitrix24 logo or 1C brand. Screenshots — real interface, not mockups.
Typical Rejection Reasons and How to Avoid Them
Over the years working with the marketplace, stable rejection patterns emerge:
| Rejection Reason | How to Fix |
|---|---|
| Extra scopes requested | Code audit: remove all scope not used in REST calls |
| Application crashes without required modules | Check available methods via app.info, graceful degradation |
| Token in GET URL parameters | Switch to POST or Authorization header |
| Screenshots with test data | Retake with realistic demo data |
| No uninstall handling | Implement /uninstall handler with data cleanup |
| Application doesn't work in mobile Bitrix24 | Responsive layout or separate mobile version |
| No privacy policy page | Add to website and specify URL in app card |
Review Process
Preparation for submission. Before sending to review you need to independently go through the official developer checklist (documentation on dev.1c-bitrix.ru). Test the application on different Bitrix24 tariffs: "Basic", "Standard", "Professional" — REST method availability differs.
Sandbox testing. Create several test portals with different tariffs. Bitrix24 provides free demo portals for developers.
Submission for moderation. Via your partner personal account at partner.1c-bitrix.ru. In the application specify: application version, what changed compared to previous version (for updates), contact person for quick communication.
Initial automatic analysis — passes within 1–2 days. Basic technical requirements are checked.
Manual review — 5–14 days. The reviewer installs the application on a test portal, checks against scenarios.
Iterations. If there are notes — they come as a list. A deadline is given for correction (usually 14 days). After correction — repeat check, which is faster (3–7 days) if changes are point fixes.
Accelerating Review
Several practices that reduce iteration counts:
- Attach to the application a test account on your service with filled demo data — the reviewer shouldn't have to register and set up themselves
- Write a brief testing guide (1–2 pages): main scenarios, what should work on which tariff
- Test the application in incognito mode (without cache and cookies) — that's how the reviewer will open it
- Make sure all dependent services (your backend, database, external APIs) work stably during the review time
Certification on Updates
Each new application version goes through repeat review. It's shorter than the first, if:
- Requested scopes don't change
- Monetization model doesn't change
- Changes are documented in version description
Major changes (new integrations, new placements, change in user data handling) go through full verification cycle.
Timeline
| Stage | Time |
|---|---|
| Preparation for review (audit, fixes, design) | 1–3 weeks |
| Initial review | 1–2 weeks |
| Iterations on notes (1–2 rounds) | 1–3 weeks |
| Total from ready app to publication | 3–8 weeks |