Try the Polte Location API

Polte Location API

Welcome to the Polte Location API. Polte delivers the best cellular location possible for 4G/5G Massive IoT devices, with the revolutionary ability to both enhance existing solutions and break into a new category of use cases by unlocking real-time, universal asset visibility. We provide IoT solution developers and systems integrators highly accurate location indoors and outdoors for cellular-connected devices, from supply chain asset tracking to smartphones, with best-in-class security. Learn more here. If you are an existing customer, log in anytime here.


What is SuperRes?

SuperRes (SR) delivers the highest level of cellular location accuracy on the market, and is derived when Polte firmware is embedded directly into a cellular device. To leverage SR today, you can use any of our ecosystem partners’ Powered by Polte SR IoT asset tracking devices, given they have been validated as containing Polte-enabled LTE-M chipsets. If you do not have a Powered by Polte SR device, check out Polte CoreRes below. If you are unsure or would like to chat first, connect with us here and we’re happy to help.

Quick Start Guide

Have your Powered by Polte SR device ready? Visit the Polte SR Quick Start Guide to get up and running.


Give it a Try

*Before you begin, don’t forget to view our CoreRes Best Practices. Existing customers: click here for CR module specific docs hosted on Zendesk. 


Like what you see? Let’s get you a Polte account. Sign up today here or contact us here to book a meeting.

What is CoreRes?

If you need to locate in areas that have not yet been optimized, have existing devices that do not yet have Polte firmware enabled in the chipset, or are operating on Cat-1 or higher networks, you may be a good candidate for Polte CoreRes (CR). CR currently supports both LTE-M and Cat-1+ devices, with support for NB-IoT also in the roadmap. With Polte CR,  Polte can be used by any Mobile IoT module simply  through the use of standard AT commands and API integration.  This is a faster way for customers to begin benefitting from Polte location insights immediately while transitioning to meet SR requirements for highest cellular accuracy capabilities. Check out the above example of a CoreRes (CR) locate versus a SuperRes (SR) locate in Bath, England.

Polte CR accuracy offers significantly better accuracy than Cell ID, and can be used to help Enhanced Cell ID roam. See for yourself by giving our Beta a try above.

SuperRes (SR) vs. CoreRes (CR)

Which should you employ for your use case? See our simplified guide below.

For…Use…The Details
Synchronized Cat-M networksSRLTE networks are continually being upgraded to become highly synchronized. Here’s where they are currently available: North America, Germany, Switzerland, Netherlands, Japan, Korea, Taiwan, Singapore, Australia.
Unsynchronized Cat-M networksCRThis includes all other Cat-M networks not listed above.
NB-IoT networksCRCR can be used leveraging NB-IoT networks globally.
Powered by Polte SR ChipsetsSR or CRIf unsure, please contact us here to see if your chipset is supported.
All other chipsetsCRAT Commands for a selection of other chipsets are available.
Roaming across bordersSR or CRThere is capability with both SR and CR for roaming, however its functionality depends on which countries the device is roaming to (see above).
Cat-1+ networksCRCR can be leveraged by any Mobile IoT module simply  through the use of standard AT commands and API integration.
API Endpoint

The CoreRes API Endpoint is of the form:{customer}/{customerID}/locate-core

Method: POST
Content-Type: application/json
accept: application/json"  

Existing Polte customers, the Path Parameter customerID should be obtained from your PIC account. Developers that do not have a PIC account should  input “anonymous” for customerID in the Path Parameter. Anonymous requests will be rate-limited.

Authorization Header

Polte CoreRes API uses an API key in the request header:

Polte-API <customer-api-token>

The Customer-api-token is the API Token that is created in your PIC account. Developers that do not have a PIC account should ignore the Authorization Header.

Request Body
gcidtrueunsigned integer0-268435455The global cell identity or ECI.
taoptional but recommended for best results (can be omitted if no valid ta)integerta should be in steps of 8 Ts. 16 Ts = 0.5208 µs.The timing advance value is the round-trip travel time.
mcctrueinteger0…999The mobile country code.
mnctrueinteger0…999The mobile network code.
tacfalseunsigned integer0…65535Two-byte tracking area code.
earfcntruearray of integers0…65535An array of serving cell and subsequent neighbor cells.
pcidtruearray of integers0..503Physical cell identity that shows the array for serving cell and subsequent neighboring cells.
rsrptruearray of numbers-44 to -140A measurement of the received power level measured in dBm. Note: Decimal values are acceptable.
rsrqoptionalarray of numbers-3 to -20A measurement of the quality of the received reference signal measured in dBm. Note: Decimal values are acceptable.

Below is a sample CURL request:

curl -X POST '{customerID}/locate-core' \
-H 'accept: application/json' \
-H 'Authorization: Polte-API <customer-api-token>' \
-H 'Content-Type: application/json' \
-d '{"payload":{"gcid":24411398,"ta":2, "mcc":208, "mnc":1,"tac":0,"earfcn":[6400,6400,6400],"pcid":[209,141,27],"rsrp":[-84,-90,-94],"rsrq":[-9,-12,-14 ]}}'

The response shows the location attributes:

Status Code

The status fields may contain the following values:

200-OKThis indicates that the API returned a successful response.
Successful Response

A successful CoreRes location request will return a JSON-formatted response as follows:

uidstringA unique transaction ID.
TimeUnix epoch timeThe time when the request was processed.
LocationobjectThe estimated location of the device.
Latitude64-bit float or long floatThe latitude of the estimated location.
Longitude64-bit float or long floatThe longitude of the estimated location.
ConfidencefloatThe confidence radius (in meters) displays an area with a 68% confidence that the device location is within.

When the CoreRes API returns a status code other than 200, there may be an error to produce the location or the server could not produce a location.

404Location engine could not produce a result.
429Rate limited.
5Serving cell not found.
Error in fetching the dataPlease see our Best Practices section to ensure these are being followed.
Best Practices

There’s no need to incorporate additional hardware, radios, or infrastructure deployments to use Polte – we’re simply tapping into existing, ubiquitous cell towers. Polte CoreRes works with both NB-IoT and LTE-M worldwide.

Developers who do not yet have a PIC (Polte IoT Cloud) account may perform 10 Polte CR location requests a day – if you would like to continue using further location requests, please contact us here so we can create an account for you.

The Timing Advance value (TA) is optional but ideally recommended for good accuracy. But if this is not obtained from the module, TA can be omitted.

RSRQ is optional in the CoreRes version. RSRQ will be used in the future planned code to improve the location – it is not utilized in the code today.

CR utilizes the reported neighbor list which is managed by the network. There is no limit on the number of cells that can be passed, but the Polte engine utilizes up to 10 with the strongest RSRP for computing location.

The arrays of PCIDs, EARFCNs, and RSRPs must be the same length.

Location accuracy may be affected if we utilize TAC when the serving cell is not in the Polte database. For best accuracy, please complete as many fields as possible.

EARFCN is required and recommended. If EARFCN is not available, then the system cannot lookup the PCIDs and cannot make use of the RSRP values. In that case, Polte CR will make a CellID location using the MCC, MNC, and GCID values.

EARFCN of neighbor cells must be in the same center frequency/band. Our current system does not support multiple center frequencies. If they are different, input EARFCN of the serving cell.

If RSRP is not known or not detectable, input the module level allowed value.

Version History
1.012022-4-27RSRP/RSRQ accepts decimal values.