Response encoding and formats

The HERE GNSS Data API supports two encoding formats for LPP messages in responses.
The encoding query parameter controls which format is used.

UPER encoding

When encoding=uper (default), the response uses the HTTP multipart/mixed format.
Each part carries a single binary LPP message with its own headers.

Multipart structure

--boundary
Content-Type: application/octet-stream
X-Constellation: gps

<binary LPP message for GPS>
--boundary
Content-Type: application/octet-stream
X-Constellation: gal

<binary LPP message for Galileo>
--boundary--

Part headers

Each part in the multipart response includes the following headers:

Prediction responses include additional part headers for validity period information.
See Understanding the prediction response
for details.

To decode the binary LPP messages, use an ASN.1 decoder generated from
the LPP schema. See LPP ASN.1 schema for the schema files.

JER encoding

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

JER response formats

Note

If encoding=uper and the Accept header requests a JSON content type,
the server responds with status code 406 Not Acceptable.

JSON text sequences (application/json-seq)

This is the default JER format. Each LPP message is written as a separate
JSON text per RFC 7464:

<RS>{"type":"assistance","gnss":"gps","lpp":{...}}
<RS>{"type":"assistance","gnss":"gal","lpp":{...}}

Where <RS> is the ASCII Record Separator character (0x1E).

JSON object (application/json)

When Accept: application/json is specified, the response is a single JSON object
with a messages array:

{
  "assistance": {
    "messages": [
      {
        "gnss": "gps",
        "lpp": {
          "gnss-CommonAssistData": {
            "gnss-ReferenceTime": {...},
            "gnss-IonosphericModel": {...}
          },
          "gnss-GenericAssistData": [
            {
              "gnss-ID": { "gnss-id": "gps" },
              "gnss-NavigationModel": {...}
            }
          ]
        }
      }
    ]
  }
}

Newline-delimited JSON (application/x-ndjson)

Each LPP message is a JSON object on its own line:

{"type":"assistance","gnss":"gps","lpp":{...}}
{"type":"assistance","gnss":"gal","lpp":{...}}

JER message fields

The fields present in each JER message object depend on the response content type.

For application/json responses, each item in the messages array contains:

For application/json-seq and application/x-ndjson responses, each message object contains:

Prediction responses include an additional validity field for validity period information.
See Understanding the prediction response
for details.

Response compression

The server applies content encoding to responses following HTTP content negotiation (RFC 9110).
Clients may request compression (or no compression) using Accept-Encoding header.

Supported compression methods: gzip, deflate, br (and identity for no compression).

Clients should always check the Content-Encoding response header to determine how the response
is encoded and should not assume any specific encoding based on the request.

LPP root element

The lpp query parameter controls the root ASN.1 element used for the LPP messages:

Using data can simplify response parsing by allowing the parser to use
the smaller lpp-18-3-0-data.asn1 schema variant instead of the full LPP schema.
This smaller schema also reduces the code size of auto-generated parsers.

Related information

• Understanding the assistance response
• Understanding the prediction response
• LPP ASN.1 schema