Configuring Push Notifications for the Bitrix24 Mobile App
Push notifications in the Bitrix24 mobile app operate over two channels: Firebase Cloud Messaging (Android) and Apple Push Notification Service (iOS). Without properly configured keys and certificates, the app will silently swallow notifications — users will receive neither chat messages nor task reminders.
How push notification delivery works
Bitrix24 uses the mobile module and the push.bitrix24.com service as an intermediary broker. The Bitrix24 server sends an event to push.bitrix24.com, which formulates a request to FCM or APNs, and only then does the notification reach the device. This matters: if your Bitrix24 is installed on-premise and behind a firewall, the broker must have API access to your server.
For an on-premise Bitrix24 installation, the chain looks like this:
- Portal event (new message, task, lead) → trigger in the
mobilemodule - Request to
https://push.bitrix24.com/pub/with the device token and payload - Broker → FCM/APNs → user's device
Device tokens are stored in the b_mobile_device table. When the app is reinstalled, the token changes; the old token is marked invalid after the first failed response from FCM/APNs.
On-premise configuration: Firebase keys and Apple certificates
Android/FCM. In the Firebase project console, obtain a Server Key (Legacy API) or configure a service account for FCM v1. Bitrix24 up to version 22.x works with the Legacy API — a key of the form AAAAxxxxxxx:APA91b.... Newer versions of the mobile module support FCM HTTP v1 API via an OAuth2 service account token.
The key is entered in: Settings → Mobile App → Push Notifications → Android. After saving, the system immediately validates the key with a test request to FCM.
iOS/APNs. Apple provides two authentication mechanisms: .p12 certificates and .p8 keys (token-based authentication). Certificates expire after one year — this is the most common cause of sudden push notification failures on iOS. .p8 keys have no expiry date, so they are the recommended option.
To generate a .p8 key: Apple Developer Console → Certificates, Identifiers & Profiles → Keys → create a key with the Apple Push Notifications service (APNs) flag. It can only be downloaded once.
Common failures and diagnostics
Push notifications not arriving on iOS only. First, check the certificate expiry. Open Keychain Access, locate the certificate Apple Push Services: com.your.bundleid, and inspect the expiry date. If expired — regenerate it via Apple Developer Portal and re-upload it to Bitrix24.
Push notifications not arriving on Android or iOS after a server migration. The portal has changed its domain or IP, but push.bitrix24.com does not yet know the new address. In the on-premise registration settings, verify that the portal's external address is correct and reachable from the internet.
Duplicate notifications. The user is logged in on multiple devices — b_mobile_device contains several active tokens. This is expected behaviour, but if duplicates multiply without end, the app is registering a new token on every launch instead of updating the existing one.
Checking the send queue. The b_push_queue table accumulates unprocessed events. If the row count is not decreasing, the \Bitrix\Push\QueueAgent agent is not running. Check cron.
Configuration stages and estimated timelines
| Task | Effort |
|---|---|
| FCM Legacy/v1 configuration for Android | 1–2 hours |
| APNs (.p8) configuration for iOS | 1–2 hours |
| Diagnostics of an existing configuration | 2–4 hours |
| Push notification setup for a custom Bitrix24-based mobile app | 1–3 days |
Pricing is calculated individually after auditing the current portal configuration and the version of the mobile module in use.