Use the tariff-rates endpoint, along with a location_id, to retrieve detailed, time-series energy price data for your customer’s address. This allows your systems to access accurate energy cost information within any desired time window.

​
Key Implementation Details

​
1. Response Data Format

The API returns tariff data as a time-series dataset, similar to a stock feed. While it may seem verbose for flat-rate tariffs, this format provides a universal integration approach, primed for any tariff variations such as time-of-use, dynamic or tiered tariffs.

​
2. Units, Precision & Rounding

  • All monetary values are returned in major currency units.
  • Tariff rates may have up to 5 decimal places, such as 0.12345.
  • To prevent UI issues, implement rounding - code example. 

​
3. Data Refresh Strategy

  • Each API response includes a next_update timestamp, indicating when new data will likely be available.
  • Use this field to drive rate caching in your systems.
  • If you are unable to use next_update, a safe fallback is to pull updates at 23:00 local time.

​
4. Handling Daylight Saving Time (DST)

  • Always use RFC3339 timestamps for both start_time and end_time. This can be in Zulu time (UTC) (e.g. 2023-06-15T13:00:00Z) or with a time offset, (e.g. 2023-06-15T12:00:00+01:00).
  • If you are using offsets and your request crossing DST transitions, ensure that both start_time and end_time reflect the correct time offset for the location.
  • If different time offsets are specified, end_time takes precedence. The valid_from and valid_to times in the response will use the end_time offset.
{
  request: {
    start_time: "2025-03-30T00:00:00+01:00",
    end_time: "2025-03-30T04:00:00+02:00",
  },
}
This example shows how FlatPeak aligns the returned intervals to the end_time offset.

​
Summary

FeatureRecommendation / Notes
Data FormatAlways a time-series — flexible for flat or complex tariff structures
PrecisionUp to 5 decimals — round when presenting
Refresh HandlingUse next_update to schedule re-fetch
DST HandlingUse RFC3339 timestamps; end_time offset governs result timestamps