Configuring Geofencing Notifications for 1С-Bitrix
Picture this: you manage a chain of 50 retail stores. Thousands of potential buyers pass by every day. Sending a personalised push notification the moment someone is near a store boosts visit conversion by 2–3 times. Standard Bitrix24 tools don't offer this — you need a solution at the intersection of mobile app and server API. We've already implemented such scenarios for 15+ clients, and in this article we'll describe an architecture that handles up to 10,000 concurrent sessions.
Geofencing is a trigger that fires when a user enters or leaves a defined zone. In the Bitrix context, that means a push notification like "You're nearby — 10% off". Unlike the browser Geolocation API, native geofencing saves 30% battery and doesn't require an active screen.
How geofencing works in 1С-Bitrix
Three components are needed:
- A mobile app with background monitoring — registers geofences and sends events to the server.
- A server API on Bitrix — receives events and decides whether to send a push.
- Push infrastructure — Firebase Cloud Messaging (FCM) for Android, APNs for iOS.
The event arrives from the app in 200–500 ms, the server processes it in 50 ms. The notification is delivered in 1–2 seconds.
Why native geofencing outperforms browser-based
Native SDKs (Android GeofencingClient, iOS CLLocationManager) provide accuracy down to 50 meters and work in the background. The browser API requires an open tab and drains the battery 3 times faster. Key comparison:
| Parameter | Native Geofencing | Browser Geolocation |
|---|---|---|
| Accuracy | 50–100 m | 500–1000 m |
| Background operation | Yes | No |
| Battery consumption | 2–5% per day | 15–20% per hour |
| Trigger latency | 1–5 s | 10–30 s |
What components are needed for implementation?
The mobile app uses:
- Android:
com.google.android.gms.location.GeofencingClient - iOS:
CLLocationManagerwithstartMonitoring(for: CLCircularRegion)
On startup, the app loads the list of zones from the Bitrix server and registers them. On entry/exit, the OS generates an event — the app sends a POST request to your API.
API on the Bitrix side
A REST endpoint /local/ajax/geofence-event.php is created to accept events:
<?php require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'; $data = json_decode(file_get_contents('php://input'), true); $userId = (int)$data['user_id']; $zoneId = (int)$data['zone_id']; $eventType = $data['event']; // 'enter' or 'exit' $deviceToken = $data['device_token']; if ($eventType === 'enter') { \Local\Geofence\NotificationService::sendEnterZoneNotification( $userId, $zoneId, $deviceToken ); } ?> Storing geozones
We use an HL-block GeoZones to store zones. Example structure:
| Field | Type | Description |
|---|---|---|
UF_NAME |
String | Zone name |
UF_LAT |
Float | Center latitude |
UF_LNG |
Float | Center longitude |
UF_RADIUS |
Integer | Radius in meters |
UF_NOTIFICATION_TEXT |
Text | Push notification text |
UF_ACTIVE |
Boolean | Is the zone active |
Sending push via FCM
namespace Local\Geofence; class NotificationService { private const FCM_URL = 'https://fcm.googleapis.com/fcm/send'; public static function sendEnterZoneNotification( int $userId, int $zoneId, string $deviceToken ): void { $zone = \Local\Geofence\GeoZoneTable::getById($zoneId)->fetch(); if (!$zone || $zone['UF_ACTIVE'] !== true) return; $payload = [ 'to' => $deviceToken, 'notification' => [ 'title' => 'You\'re nearby', 'body' => $zone['UF_NOTIFICATION_TEXT'], ], ]; $http = new \Bitrix\Main\Web\HttpClient(); $http->setHeader('Authorization', 'key=' . FCM_SERVER_KEY); $http->setHeader('Content-Type', 'application/json'); $http->post(self::FCM_URL, json_encode($payload)); } } How to set a cooldown for push notifications?
Without limits, a user walking by a store several times a day would receive just as many notifications. We add a cooldown: log sends in the b_user_counter table or an HL-block, and don't send again if less than N hours have passed since the last notification for that zone. The default is 6 hours, but it's configurable per project.
Implementation process
We implement geofencing in five steps:
- Analysis: examine your infrastructure, identify requirements for zones and push scenarios.
- Design: define HL-block structure, API endpoints, data schema.
- Development: build the server API, FCM/APNs integration, cooldown logic.
- Integration: configure event transfer from the mobile app.
- Testing: verify entry/exit scenarios, load (up to 1000 events/sec), and anti-spam.
What's included in the work
- Design of geozone structure and API.
- Development of the server API on 1С-Bitrix with HL-block support.
- Setup of FCM/APNs for sending push notifications.
- Integration with the mobile app (data transfer architecture).
- Implementation of cooldown and anti-spam logic.
- API documentation and instructions for mobile app developers.
- Technical support during the implementation phase.
We also provide access to the module source code and train your developers on how to use it.
Timeline
Estimated implementation time is 3 to 5 business days, depending on integration complexity and the readiness of the mobile app.
Our engineers have 10 years of experience with 1С-Bitrix and hold "1С-Bitrix Expert" certifications. We have completed over 50 projects involving mobile app integration and geofencing. Quality is backed by a warranty on all work performed.
Get a consultation on implementing geofencing for your project — free architecture assessment and timeline estimation. Contact us to discuss the details.







