> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cariqa.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-08-31 — v1.2.0

> Context and impact for Cariqa Connect API v1.2.0.

## Overview

This release improves station naming clarity by separating operator-provided station names from location names. Partners can now display operator-defined station names where available, while handling location names as optional data.

## Why this was delivered

Some operators invest significant effort into station naming and expect third parties to use those names consistently. These names may also be visible on the physical stations themselves.

To support this, station naming data is now separated into dedicated fields. `operator_name` identifies the operator-provided station/operator context, while `location_name` represents the specific location name when such a name exists. For stations without a dedicated location name, `location_name` may be `null`.

## Impact

Integrations that display name of the location using `name` field from:

* `GET /stations/details/`
* `GET /stations/around/`

and `station_name` field from:

* `GET /users/<str:user_id>/charging-sessions/`
* `GET /users/<str:user_id>/charging-sessions/<str:session_id>/`
* `PATCH /users/<str:user_id>/charging-sessions/<str:session_id>/`
* `POST /users/<str:user_id>/charging/start/`

## Required action

\[MIGRATE DEPRECATED FIELD]

Updated schema marks older fields as deprecated:

* `name` on the station response objects
* `station_name` on session response objects

Integrations using these fields should migrate to `operator_name` and `location_name`. Since `location_name` may be `null`, clients should handle missing location names gracefully and use the field only when it is provided.