Skip to main content
Flatpeak is timezone-aware by design. All API time handling is based on UTC internally. System-generated timestamps are always returned in UTC. However, the API accepts datetime inputs in any timezone and will respond in the same timezone.

​
Use RFC3339 format

All requests must use RFC 3339 timestamps for start_time and end_time. You can send:
  • Zulu (UTC) format: 2025-06-15T00:00:00Z
  • Offset format: 2025-06-15T00:00:00+10:00
These represent different moments in time. Examples:
  • 2025-06-15T00:00:00Z → UTC
  • 2025-06-15T00:00:00+10:00 → UTC+10

​
Integration Strategy: Choose One Approach

Before integrating, choose a consistent approach to time handling:
  • UTC-first: Send and process all timestamps in UTC. Convert to local time in your system if needed.
  • Local-first: Always include the correct local timezone offset in API requests.

​
Example

Calling retrieve-price endpoint using UTC vs Local Time for a location in Sydney, Australia:
  • UTC example
  • Local time example
curl --request POST \
  --url https://api.flatpeak.com/prices/loc_641b90b758fb8e6293716e40 \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "start_time": "2023-06-15T09:00:00Z",
  "end_time": "2023-06-15T23:00:00Z",
  "tariff_direction": "IMPORT"
}'
```json5 Response example
{
    "id": "prs_68ba8186d1926f4da39601b5",
    "object": "price",
    "location_id": "loc_65e42ce4d3b813479b252160",
    "location_timezone": "Australia/Sydney",
    "currency_code": "AUD",
    "data":
    [
        {
            "valid_from": "2025-09-15T10:00:00Z",
            "valid_to": "2025-09-16T10:00:00Z",
            "tariff":
            {
                "rate": 0.014
                "confidence": 1,
            }
        }
    ]
}

​
Handling Daylight Saving Time (DST)

If you are using offsets and your request crosses 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",
  },
}
The example above shows how Flatpeak aligns the returned intervals to the end_time offset.