Assistance data request

To request real-time A-GNSS data, send an HTTP GET request to
the /v2/assistance endpoint on the HERE GNSS Data API.

Base URL

https://gnss.hereapi.com/v2/assistance

Authentication

The HERE GNSS Data API supports two authentication methods.
You can use either method for all requests.

API key

Pass your API key as the apiKey query parameter:

GET /v2/assistance?gnss=gps&apiKey={YOUR_API_KEY} HTTP/1.1
Host: gnss.hereapi.com

Bearer token

Pass a bearer token in the Authorization header:

GET /v2/assistance?gnss=gps HTTP/1.1
Host: gnss.hereapi.com
Authorization: Bearer {YOUR_BEARER_TOKEN}

For information on how to obtain API keys or bearer tokens, see the Identity and Access Management Guide.

Query parameters

Parameter	Type	Required	Default	Description
`gnss`	string	No	All systems	Specifies the GNSS system(s) for which assistance data is requested. Supported values: `gps`, `glo`, `gal`, `bds`, `qzs`. Separate multiple values with commas. If omitted, data for all supported systems is returned.
`encoding`	string	No	`uper`	Specifies the encoding format for the LPP messages. Supported values: `uper` (Unaligned Packed Encoding Rules) for binary encoding, `jer` (JSON Encoding Rules) for JSON encoding. See JER encoding for details.
`lpp`	string	No	`data`	Specifies the LPP ASN.1 root element. Use `data` for `A-GNSS-ProvideAssistanceData` or `full` for `LPP-Message`. Using `data` can reduce the size of the code needed to parse ASN.1 messages.
`billingTag`	string	No	—	A list of up to six billing tags, separated by `+`. Length: 4–101 characters. For details, see the Cost Management Developer Guide.

Request headers

Header	Required	Description
`X-Request-ID`	No	User-provided token to trace a request or a group of requests. Can be any string; UUID is recommended. The value is echoed in the response.
`Accept`	No	Preferred media type for the response. For JER encoding, supported values are `application/json-seq` (default for JER), `application/json`, and `application/x-ndjson`. For UPER encoding, the only accepted value is `multipart/mixed`. If `encoding=uper` and a JSON content type is requested, the server responds with `406 Not Acceptable`.
`Accept-Encoding`	No	Preferred content encodings for response compression. Supported values: `gzip`, `deflate`, `br` (and `identity` for no compression). The server uses content negotiation to select the best option and indicates the choice in the `Content-Encoding` response header.

Examples

Request GPS assistance data with an API key

GET /v2/assistance?gnss=gps&apiKey={YOUR_API_KEY} HTTP/1.1
Host: gnss.hereapi.com

Request GPS and Galileo data with a bearer token

GET /v2/assistance?gnss=gps,gal HTTP/1.1
Host: gnss.hereapi.com
Authorization: Bearer {YOUR_BEARER_TOKEN}

Request all GNSS systems with LPP-Message root element

GET /v2/assistance?lpp=full&apiKey={YOUR_API_KEY} HTTP/1.1
Host: gnss.hereapi.com

Request GPS data in JER encoding

GET /v2/assistance?gnss=gps&encoding=jer&apiKey={YOUR_API_KEY} HTTP/1.1
Host: gnss.hereapi.com

Request with tracking headers

GET /v2/assistance?gnss=gps&apiKey={YOUR_API_KEY} HTTP/1.1
Host: gnss.hereapi.com
X-Request-ID: my-request-123

JER encoding

When encoding=jer is specified, the response contains LPP messages in ASN.1
JSON Encoding Rules (JER) format instead of binary UPER. The Accept request header
controls the specific JSON content type.

JER encoding is useful for:

Integrating with systems that natively handle JSON.
Debugging and inspecting the assistance data content.
Environments where binary ASN.1 parsing libraries are not available.

For details on JER response formats and content types, see
Response encoding and formats.