OptionalurlServer URL where you want the SDK to post recorded locations.
Both the iOS and Android native code host their own robust HTTP service
which can automatically upload recorded locations to your server. This is
particularly important on Android when running headless with
AppConfig.stopOnTerminate set to false, since only the plugin's
background service continues running in that state.
// Listen to HTTP events.
BackgroundGeolocation.onHttp((event) => {
console.log("[onHttp]", event);
});
BackgroundGeolocation.ready({
http: {
url: "https://my-server.com/locations",
params: {
user_id: 1234
},
headers: {
Authorization: "Basic my-secret-key"
},
autoSync: true,
method: "POST"
},
app: {
stopOnTerminate: false
}
});
Warning: It is highly recommended to let the SDK manage uploads to your
server, especially on Android when AppConfig.stopOnTerminate is
false. In that mode your application component will terminate—only the
native Android background service continues operating, recording locations
and posting them to your server. The SDK’s HTTP service automatically
retries on failures and is more reliable for background delivery than
ad-hoc HTTP requests from your own code.
See the HTTP guide under HttpConfig for full examples, error handling, and payload structure.
OptionalheadersOptional HTTP headers applied to every outbound upload request.
These headers are merged with the SDK’s automatically applied headers
(such as "content-type": "application/json"). When using authorization,
the SDK also injects an Authorization header as needed.
BackgroundGeolocation.ready({
http: {
url: "https://my.server.com",
headers: {
Authorization: "Bearer <a secret key>",
"X-FOO": "BAR"
}
}
});
Observing incoming requests at your server:
POST /locations
{
"host": "tracker.transistorsoft.com",
"content-type": "application/json",
"content-length": "456",
...
"authorization": "Bearer <a secret key>",
"X-FOO": "BAR"
}
Note:
The SDK automatically applies several required headers, including:
"content-type": "application/json"See also: the HTTP Guide under HttpConfig.
OptionalparamsOptional HTTP params appended to the JSON body of each outbound upload request.
These key/value pairs are merged into the payload sent to your server
(either at the root level or under rootProperty, if configured).
BackgroundGeolocation.ready({
http: {
url: "https://my-server.com/locations",
params: {
user_id: 1234,
device_id: "abc123"
}
}
});
Example request body received by your server:
{
"location": {
"coords": {
"latitude": 45.51927,
"longitude": -73.61650
// ...
}
},
"user_id": 1234, // <-- params merged into the payload
"device_id": "abc123"
}
See also: the HTTP Guide under HttpConfig.
OptionalmethodThe HTTP method used when uploading locations to your configured url.
Defaults to POST.
Valid values: POST, PUT, OPTIONS.
OptionalautoImmediately upload each recorded location to your configured url.
Defaults to true.
When autoSync is enabled and a url is provided, the SDK
will attempt to upload each location as soon as it is recorded.
If you set autoSync: false, you must manually call
BackgroundGeolocation.sync to initiate uploads.
Regardless of autoSync, all recorded locations are persisted in the
SDK’s internal SQLite database until successfully delivered.
Note: The queue continues to grow until you call BackgroundGeolocation.sync or until uploads succeed.
See also
OptionalautoThe minimum number of persisted records the plugin must accumulate before triggering an automatic upload via autoSync.
Defaults to 0 (no threshold).
When set to a value greater than 0, the SDK will wait until at least that
many locations are recorded before uploading to your configured
url.
Using autoSyncThreshold together with batchSync can
significantly reduce battery consumption, since batching minimizes the
number of HTTP requests (which cost far more power than GPS work).
⚠️ Warning: Ignored during onMotionChange
If you've configured autoSyncThreshold, it will be ignored during
BackgroundGeolocation.onMotionChange transitions:
Entering the moving state:
The device may have been dormant for a long time; the SDK eagerly uploads
queued locations immediately.
Entering the stationary state:
The device may soon become dormant; the SDK eagerly uploads all queued
locations before going idle.
See also
OptionaldisableDisable autoSync when the device is connected over cellular data.
Defaults to false.
When set to true, automatic HTTP uploads will occur only when on Wi-Fi.
This is useful for conserving mobile data usage, particularly when large batches of locations may accumulate while offline.
⚠️ Warning: This option is ignored when manually invoking BackgroundGeolocation.sync. Manual syncs always proceed regardless of connection type.
See also
OptionalbatchUpload multiple locations to your url in a single HTTP request.
Defaults to false.
When set to true, the SDK will bundle all currently queued locations in
the native SQLite database and upload them together in one HTTP request.
When batchSync is false, the HTTP service performs one request per
location, which can increase battery and network usage.
Batching is often used together with autoSyncThreshold to reduce upload frequency and conserve power.
See also
OptionalmaxControls the number of records attached to each batched HTTP request.
Defaults to -1 (no maximum).
When using batchSync with url configured, this option limits how many queued location records may be included in a single HTTP request.
If the number of queued records exceeds maxBatchSize, the SDK will generate
multiple HTTP requests until the queue is fully drained.
This prevents extremely large request bodies when the device has been offline for long periods (where megabytes of location data may accumulate).
See also
OptionalrootThe root property of the JSON object where location data will be placed.
When set, outgoing HTTP payloads will wrap the serialized location record(s) under the specified key.
BackgroundGeolocation.ready({
http: {
rootProperty: "myData",
url: "https://my.server.com",
}
});
Produces payloads shaped like:
{
"myData": {
"coords": {
"latitude": 23.232323,
"longitude": 37.373737
}
}
}
If you specify "." (dot), the SDK places the data directly in the root
of the JSON body:
{
"coords": {
"latitude": 23.232323,
"longitude": 37.373737
}
}
Note: See the HTTP Guide at HttpConfig for detailed payload examples and composition rules.
See also
OptionaltimeoutHTTP request timeout in milliseconds.
When an HTTP request exceeds this timeout, the SDK fires BackgroundGeolocation.onHttp with a failure event.
Defaults to 60000 ms.
HTTP / Networking Configuration
The HttpConfig group controls how recorded locations are uploaded to your server. It defines the endpoint, HTTP verb, headers, params, batching behavior, and request timeouts.
These options apply to all automatic syncs as well as manual syncs triggered by the app.
Example
Overview
The SDK persistently stores each recorded location in its internal SQLite database before attempting to upload it. The HTTP Service continuously consumes this queue of stored records in the background. For each record:
The uploader operates automatically across:
When connectivity returns, it resumes processing any remaining records.
methoddefaults toPOST.How uploads work
The SQLite buffer
The storage acts as a rolling buffer and is normally empty. Records disappear when:
Inspect queue size using BackgroundGeolocation.getCount or fetch with BackgroundGeolocation.getLocations.
Payload composition
Body: JSON. If
batchSyncistrue, an array of records is sent.If
rootPropertyis set, payload becomes:Headers: Combined from headers plus authorization if configured.
Params: Added to every payload at the root or under
rootProperty.Uploads use
application/json; authorization refresh requests useapplication/x-www-form-urlencoded.Sync strategy
autoSync: upload after each recordautoSyncThreshold: wait for N recordsbatchSync: upload several records in one requestmaxBatchSize: max records per batchtimeout: maximum HTTP durationdisableAutoSyncOnCellular: defer uploads until Wi-FiError handling & retries
On non-2xx or network failure, records remain in queue and are retried when:
Or manually:
HTTP Logging
Logs provide insight into HTTP behavior:
📍 LocationINSERTLockedHTTP POST/PUTResponseDESTROY/UNLOCKRemote control via HTTP response (RPC)
Your server may instruct the SDK to execute commands by returning JSON containing a
background_geolocationpayload.Multiple commands
Single command
Supported remote commands
"start""stop""startGeofences""changePace""setConfig"{Config}"addGeofence"{Geofence}"addGeofences"[{Geofence}, ...]"removeGeofence"identifier:string"removeGeofences""uploadLog"url:string"destroyLog"Examples
Simple upload:
Batched uploads:
Conserve cellular data:
Manual sync:
Migration from legacy flat Config
Old:
New (compound):
Legacy keys remain available but are @deprecated and will be removed in a future major release.