Showing a price timeline to a driver
A driver-facing price timeline is a bar chart of what a charging session costs at each hour or slot across today or the coming week, with the price that applies right now marked as active. Building one takes both APIs: the Pricing API resolves which rate applies to the driver and which entry is active, and the Dynamic Pricing API returns the full schedule behind that rate. The introduction to either API sets out the split between them.
Fetch the applied price
Call api/pricing for one evse, or
api/pricing/batch for several, with the driver’s token and
the target evse ids. Set next_price=true to get the following entry in
the same call.
From the response, read costId and costRateUuid to identify the
resolved cost rate, pricingType to tell which kind of schedule it has,
and scheduleUuid to identify the entry that produced the current price.
When scheduleUuid is null, the active price is a default-price gap: keep
validity.start/end too, since a week’s timeline can hold several gap
bars and matching by uuid alone will not tell them apart.
Fetch the schedule behind the rate
The endpoint depends on pricingType, and each rejects a cost rate in the
other mode with a 400 (see Dynamic pricing modes):
1— Get Recurring Pricing Schedule Entries returns the weekday and time-range slots, enough for a full week view. It accepts an optional weekday and time-of-day window, which wraps at the end of the week.2— Get Unique Pricing Schedule Entries returns the date-specific entries, with an optional window on the station’s clock:from/toare naive local datetimes, and a timestamp carrying aZor an offset is rejected with400.
A static rate (0) has no schedule to read; its one price is already in
the price response.
Both endpoints are paginated and return each entry with its own
validity, intervals and marketing_texts. The list holds
configured entries only — it does not enumerate the cost rate’s default
price, so it leaves gaps wherever no entry covers: before the first entry,
between two entries that do not meet, and after the last one on a unique
schedule. To step forward from an entry you already have, call
Get Next Pricing Schedule Entries.
Render the timeline
How an entry maps to bars depends on the mode. On a unique-date rate each
entry is one window: draw one bar, sized to its validity start and
end and priced from its intervals. On a recurring rate each entry is
a whole parent schedule, and its validity.weekdays carries one row per
weekday and time range the schedule covers: draw one bar per row, all priced
from that entry’s intervals.
Marking the active bar differs with it too. On a unique-date rate the entry
whose uuid matches the price response’s scheduleUuid is the active bar.
On a recurring rate that uuid is the parent schedule’s on both sides, so it
identifies the schedule and not the slot — take the active row from the price
response’s own validity.weekdays, which holds exactly the one slot in
force, and match it against validity.weekdays[].uuid in the schedule
listing. Where scheduleUuid is null the active bar is the gap bar whose
window matches the price response’s validity.
Fill every gap the entry list leaves with a bar of the cost rate’s own
default price: call
cost_rate_energy_cost,
cost_rate_time_costs and
cost_rate_session_fee
without a schedule identifier, and bound the bar the same way the API bounds
a default window — day by day, from
where the previous entry (or the start of the day) leaves off to where the
next entry (or 23:59:59) picks up. This is a real price, not a missing
value to skip: when the price response’s validity.type is default,
the active bar is one of these, with scheduleUuid null. For the full
rule behind it, see Dynamic pricing metadata.
Note
The Dynamic Pricing API takes a cost rate uuid and returns that rate’s schedule. It resolves nothing per driver and knows nothing about tokens or contracts. Show a schedule to a driver only after the Pricing API has resolved that rate for their token; any other rate reports prices they will not be charged.