How to HERE route matching v8 service transactions are counted

Symptoms
--------

Customers using HERE Route Matching v8 may notice one or more of the following:

The number of billed transactions is higher than the number of Route Matching API requests sent.
Transaction usage increases when the attributes parameter is added to a request.
Usage calculations do not match the assumption of one transaction per API call.
Requests containing map layer attributes such as SPEED_LIMITS_FCn, ROAD_GEOM_FCn, or LINK_ATTRIBUTE_FCngenerate additional usage.
Different routes produce different transaction counts even when the same request parameters are used.

Answer
------

This behavior is expected. For HERE Route Matching v8, the route matching operation itself is counted as one transaction per request. Additional transactions are generated when map layer attributes are requested because the service must retrieve attribute data from one or more map tiles along the matched route.

Product
-------

HERE Route Matching v8
HERE Platform Routing and Map Data Services

Explanation
-----------

A Route Matching v8 request contains two potential transaction components:

### 1. Route Matching Request

Each Route Matching API request is counted as:

1 Route Matching transaction per request

Example:

| | | |
| --- | --- | --- |
| Item | Info | Remarks |
| Route matching v8 request | POST url https://routematching.hereapi.com/v8/match/routelinks?routeMatch=1&mode=fastest;car;traffic:disabled&attributes=SPEED_LIMITS_FCn(FROM_REF_SPEED_LIMIT,TO_REF_SPEED_LIMIT),LINK_ATTRIBUTE_FCn(ISO_COUNTRY_CODE)&apiKey={{HERE_APIKey}} POST body latitude,longitude,speed_kmh 47.188005,39.620847,8 47.18803,39.620755,9 47.188037,39.620688,9 POST Man reference | |
| Transactions count | Route Matching transaction = 1 transaction / request + Speed_Limit_FCn = (1 no of tiles retrieved) transaction(s) / request + Link_Attribute_FCn = (1 no of tiles retrieved) transaction(s) / reques | For every map layer attribute requested the transactions count by the number of tiles required to retrieve all the information on the matched route. If the matched route falls in 5 tiles and user requested 3 map layers attributes for example: + SPEED_LIMITS_FCn + ROAD_GEOM_FCn + ROAD_ROUGHNESS_FCn Then it results in (3*5) transactions PLUS the main route match request transaction. |

### 2. Map Attribute Retrieval

When the request includes map layer attributes through the attributes parameter, additional transactions are counted.

Examples:

* SPEED_LIMITS_FCn
* LINK_ATTRIBUTE_FCn
* ROAD_GEOM_FCn
* ROAD_ROUGHNESS_FCn

For each requested map layer, transaction consumption depends on the number of map tiles required to return the requested data for the matched route.

Formula:

Attribute Transactions =

(Number of Requested Map Layers) ×

(Number of Tiles Accessed)

``

Example Calculation
-------------------

Request:

Route Matching = 1 request

Requested map layers:

- SPEED_LIMITS_FCn

- ROAD_GEOM_FCn

- ROAD_ROUGHNESS_FCn

Assume the matched route spans 5 map tiles.

Calculation:

Route Matching Request:

1 transaction

Map Layer Transactions:

3 layers × 5 tiles = 15 transactions

Total:

1 + 15 = 16 transactions

Root Cause
----------

Map attribute data is stored and retrieved by map tile. When a matched route crosses multiple tiles, the service must access each applicable tile for every requested map layer. As a result, transaction usage scales with:

1. The number of requested attribute layers.
2. The geographic length and coverage of the matched route.
3. The number of map tiles intersected by the route.

Impact
------

Customers may observe higher-than-expected transaction consumption when:

* Multiple map attribute layers are requested.
* Routes cover large geographic areas.
* Routes span many map tiles.

This is expected service behavior and does not indicate a platform issue.

Recommended Actions
-------------------

* Request only the map layers required by the application.
* Review whether all requested attributes are necessary for each workflow.
* Expect transaction consumption to increase as route length and tile coverage increase.
* Monitor usage when adding additional FCn attribute layers to Route Matching requests.

Expected vs. Unexpected Behavior
--------------------------------

### Expected

* One Route Matching transaction per request.
* Additional transactions for each requested map layer and tile accessed.
* Different transaction totals for routes with different tile coverage.

### Unexpected

* Missing transaction records for processed requests.
* Transaction counts that do not reflect the requested layers or tile coverage.
* API errors preventing attribute retrieval.

Transaction Example from Sample Request
---------------------------------------

Request includes:

SPEED_LIMITS_FCn(FROM_REF_SPEED_LIMIT,TO_REF_SPEED_LIMIT)

LINK_ATTRIBUTE_FCn(ISO_COUNTRY_CODE)

Total transaction count:

1 Route Matching transaction

+

(1 × number of tiles for SPEED_LIMITS_FCn)

+

(1 × number of tiles for LINK_ATTRIBUTE_FCn)

Classification
--------------

* Behavior Type: Expected Behavior
* Status: UPDATE
* Current Platform Relevance: Applicable to HERE Route Matching v8 transaction accounting model

Keywords
--------

HERE Route Matching v8, transaction count, billing calculation, routelinks, map attributes, SPEED_LIMITS_FCn, LINK_ATTRIBUTE_FCn, ROAD_GEOM_FCn, ROAD_ROUGHNESS_FCn, map tiles, usage calculation, API transactions, route matching billing, FCn layers, HERE platform usage metrics