New releases: 28.10.2026 | Knowledge Portal

This release adds a stop-cost threshold to remote start, so a payment terminal or app can start a session that stops by itself when a pre-authorised amount is reached. Session validation rules can now be set per integration, holding back sessions that break them until you approve them. Roaming CDRs now reach the partner within seconds of the session stop instead of about a minute, tariffs reach roaming partners as soon as they are linked to a socket, and several roaming CDR issues are fixed. There are also two API behaviour changes to check against your integration.

Stop a remote-started session at a set cost

Start a session through the API with a cost limit, and it stops on its own when the running cost reaches it.

POST /v2/chargers/{chargerId}/start-charging takes a new optional stopCostInclVat. The session is stopped at the first running cost that reaches the value, which lets a payment terminal or an app stay within the amount the driver pre-authorised.

It is a stop threshold, not a cap. The cost can overshoot by up to about a minute of charging, so leave a margin.
The value is in the currency of the session's tariff and must be above zero with at most two decimals.
It never raises the tariff's own maximum price. If the tariff has a lower maximum, that still applies.
It is ignored when the session has no tariff, because there is no cost to compare against.
Omitting the field, or sending null, starts the session as before.

Two related fixes: a tariff whose maximum price is set only including VAT no longer stops the session at its first meter value, and sessions with more than one tariff that has a maximum price no longer fail the running cost calculation.

Hold integration sessions that break validation rules

Sessions that break a rule you set on a roaming or UtilityCloud integration are held back until you approve them.

Session validation rules, added for your organisation in the 29.09.2026 release, can now also be set per integration. A rule on an integration does more than flag the session: a session that breaks it is held, and nothing is sent to the other party until you decide.

Roaming integrations: the CDR of a held session is not sent to the roaming partner. The session's Roaming tab shows the CDR as Held for review, and the roaming CDR list can be filtered by the new Held and Rejected statuses. Credit CDRs are not checked.
UtilityCloud integrations: a held session is left out of the consumption sent to UtilityCloud. The integration page has a new Sessions tab that lists the integration's sessions with their delivery status (Pending, Held, Rejected, Approved, pending delivery or Sent) and when they were sent.

Set the rules under Session validation rules on the integration's page in Connect. Admins only. The rules are the same as the organisation-level ones: maximum average power, minimum duration, maximum energy and zero duration. All are off until you turn them on, and a session that passes, or an integration with no rules on, is handled as before.

Held sessions are reviewed on the session page, on the new Flagged Session tab. It shows which rule the session broke, with the actual value and the limit. Approve sends the session on: the CDR goes to the roaming partner, or the consumption is posted to UtilityCloud. Reject needs a note and keeps the session from ever being sent. If a delivery fails after approval, the tab shows the error and offers Retry. Who approved or rejected the session, and when, is recorded on the tab. Users without admin rights see the tab read-only.

In the API, GET and PUT /v2/integrations/{integrationId}/session-validation-rules manage an integration's rules, GET /v2/session-validation-holds?internalTransactionId= lists a session's holds, and POST /v2/session-validation-holds/{holdId}/approve and /reject resolve them. GET /v2/integrations/{integrationId}/uc-sessions lists a UtilityCloud integration's sessions with their delivery status.

Tariffs reach roaming partners as soon as they are linked

When you link a tariff to sockets in a roaming location for the first time, the tariff is now pushed to the roaming partner right away, together with the location update. Before, the partner only received the tariff object after the tariff was edited, so partners that poll tariffs on a schedule could show a newly linked tariff a day late or not at all. Linking a tariff the partner already has sends nothing extra.

Roaming CDRs reach the partner faster

The CDR of a roaming session is now sent to the roaming partner within seconds of the session stop, instead of about a minute after it. This helps payment terminals and apps that wait for the CDR before closing the session screen. The session summary sent at stop is unchanged, so keep showing that first and handle the CDR as a separate message.

Roaming CDR fixes

A CDR whose last charging period started after the end of the tariff's validity was never sent to the partner. It is now sent, using the tariff that was valid when the period or the session started.
A CDR notification that arrives before the session's stop has been processed is retried a few seconds later instead of waiting for the scheduled reconciliation run.

API changes to check

Meter values are limited to 31 days per request. GET /v2/chargers/{chargerId}/meter-values returns 400 when the range between from and to is longer than 31 days.
Charging sessions in the API carry a new costStatus field, PRICED or ZERO_COST, for sessions that ended with no cost or a cost of zero.

Other features released

The drivers list (GET /v2/drivers) is much faster for large organisations. Looking up a driver by external ID took several seconds for organisations with tens of thousands of drivers and could slow down other requests.
Consumption time series requests with transferredToUtilizer=true failed with a database error. Fixed.
In the charging sessions Excel export, the "Sanity Flags" column is now called "Issues" and shows the same readable names as Connect, for example "Session too short" instead of "MinDurationNotMet".
A session whose charger reported an implausible stop time (before the start, far in the future, or spanning more than a year) no longer generates energy time series for that span. The session is flagged with an invalid timestamp issue instead. One such session used to flood the platform with hundreds of thousands of events.
Other small bug fixes.

If you have any questions regarding these changes, feel free to contact us at our Service Desk or at support@emabler.com