How to calculate Vector and Traffic Tile transactions

How are Vector Tile, Raster Tile, and Traffic Tile Transactions Calculated When the Map View Does Not Change
============================================================================================================

Symptoms
--------

Customers may observe one or more of the following:

Traffic tile transaction counts continue to increase even when the map is not panned or zoomed.
Traffic Vector Tile API or Traffic Raster Tile API usage appears higher than expected during long-running map sessions.
Questions about whether traffic updates automatically generate billable transactions.
Confusion about whether vector tiles generate fewer transactions than raster tiles.
Uncertainty about cache expiration times for Vector Tile API, Raster Tile API v3, and satellite imagery.
Questions about whether underlying map tiles are re-requested when traffic data refreshes.

Answer
------

Traffic tile transactions are generated only when the client makes a request for a traffic tile. Updates to real-time traffic data do not by themselves create transactions. If an application requests traffic tiles every 60 seconds after the cached content expires, each request is counted as a new transaction.

For HERE Traffic Vector Tile API and Traffic Raster Tile API, traffic tile responses include cache expiration headers with a lifetime of approximately 60 seconds. After expiration, the client may request updated traffic content. Each subsequent tile request is counted as one transaction.

### Example: Static Map View

Assume a map viewport contains 6 traffic tiles and remains unchanged for 1 hour.

If the application refreshes traffic tiles every 60 seconds:

6 traffic tiles × 60 refresh cycles = 360 Traffic Tile transactions

Each requested tile represents one billable transaction.

If the application refreshes less frequently, such as every 5 minutes, transaction counts will be lower because transactions occur only when requests are sent.

### Do Traffic Updates Automatically Generate Transactions?

No.

Traffic data updates on the service side do not automatically create transactions. Transactions are generated only when the client requests tiles.

### Are Underlying Raster Map Tiles Refreshed Every 60 Seconds?

No.

Traffic services and base map tile services are separate.

Traffic Vector Tile API and Traffic Raster Tile API responses use traffic-specific cache settings.
Base map tiles served through Raster Tile API v3 are independent of traffic tile expiration.
A traffic tile refresh does not automatically require reloading unchanged underlying map tiles.

### Do Vector Tiles Generate Fewer Transactions Than Raster Tiles?

Not necessarily.

For the same viewport and tile size (for example, 512×512), the number of tile requests is generally the same.

Transaction counts depend primarily on:

Number of visible tiles
Zoom level
User interaction (pan and zoom)
Application refresh behavior
Cache utilization

### Does Zoom Level Affect Vector Tiles?

Yes.

Vector tiles and raster tiles both exist across multiple zoom levels.

Vector rendering supports smoother visual scaling between zoom levels, but the underlying vector tile system still uses zoom-based tile requests. Therefore, zoom level remains relevant for transaction calculations.

Cache Expiration
----------------

### Traffic Vector Tile API

Cache lifetime: approximately 60 seconds

### Traffic Raster Tile API

Cache lifetime: approximately 60 seconds

### Raster Tile API v3

Cache lifetime: 1 hour (max-age=3600)

### Vector Tile API

Cache lifetime: 1 hour (max-age=3600)

### Satellite Imagery

Cache lifetime: 1 day

### Legacy Map Tile API v2

Cache lifetime: 1 day

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

Customers often assume that real-time traffic updates automatically generate transactions. In practice, HERE billing is based on tile requests made by the client application. Cache expiration enables clients to obtain fresher traffic information but does not force requests.

Impact
------

Applications that refresh traffic layers frequently can generate significantly more transactions than applications that rely on longer refresh intervals. Proper cache usage and refresh interval planning help optimize consumption.

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

Refresh traffic tiles only as frequently as required by the use case.
Use cache headers appropriately where near-real-time traffic is not required.
Calculate expected consumption based on:
+ Visible tile count
+ Refresh interval
+ Session duration
+ User interaction patterns
For static map displays, consider longer traffic refresh intervals when operationally acceptable.

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

Expected

A new transaction is counted for every traffic tile request.
Traffic tiles may be refreshed after cache expiration.
Transaction counts increase when the client requests updated traffic tiles.

Unexpected

Assuming traffic service updates automatically create transactions without client requests.
Assuming traffic tile expiration forces reloading of all underlying base map tiles.
* Assuming vector tiles inherently produce fewer transactions than raster tiles for the same number of requested tiles.

Keywords
--------

traffic tile transactions, traffic vector tile api, traffic raster tile api, vector tile api, raster tile api v3, tile billing, cache expiration, max-age, real-time traffic, transaction calculation, map tile caching, traffic refresh interval, satellite imagery caching, viewport tile count, HERE platform APIs