.. _pricing-timeline: 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 :ref:`dynamic-pricing-modes`): - ``1`` — :doc:`/dynamicPricingApi/recurring_schedule_get` 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`` — :doc:`/dynamicPricingApi/unique_schedule_get` returns the date-specific entries, with an optional window on the station's clock: ``from``/``to`` are naive local datetimes, and a timestamp carrying a ``Z`` or an offset is rejected with ``400``. 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 :doc:`/dynamicPricingApi/next_schedule_get`. 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 :doc:`cost_rate_energy_cost `, :doc:`cost_rate_time_costs ` and :doc:`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 :ref:`pricing-dynamic-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.