Learn · Understand · Build

Date Filters — fromBookingDateTime & toBookingDateTime

CategoryIntegrationRead3 minUpdated21 May 2026

The transaction and statement list endpoints accept an optional date range. This article is the short version: what the range accepts, the three cases the API Hub rejects, and what an LFI's Ozone Connect implementation has to do with the requests that reach it.

Data SharingOzone ConnectTransactions

Both list endpoints take an optional, open-ended date range. GET /accounts/{accountId}/transactions uses fromBookingDateTime / toBookingDateTime; GET /accounts/{accountId}/statements uses fromStatementDate / toStatementDate. The behaviour is identical — the examples below use transactions.

01 Accepted

What the range accepts

Both parameters are optional. They narrow the result to transactions booked on or after fromBookingDateTime and on or before toBookingDateTime; omit either bound for an open-ended range. A well-formed range is always accepted — even when it matches nothing. In particular, the following are valid requests, not errors:

a range reaching beyond two years into the past — the LFI returns the records it holds, and MAY return records older than two years where it has them;
a quiet period with no activity;
a fromBookingDateTime set in the future or later than any booked transaction — coherent, it simply matches nothing.

In each of these cases the response is 200 with the matching subset in data — an empty array where nothing matches. A 404MUST NOT be used to signal "no transactions in range".

200 — a valid empty resulthttp

HTTP/1.1 200 OK

{
  "data": [],
  "meta": {
    "paginated": true,
    "totalPages": 0,
    "totalRecords": 0
  }
}

02 Rejected

Three cases the API Hub rejects

The API Hub validates the date range before proxying the request to the LFI. It returns 400 with Resource.InvalidFormat in three cases:

a date-time parameter cannot be parsed;
the range is contradictory — fromBookingDateTime is after toBookingDateTime;
toBookingDateTime is in the future — an upper bound on when a transaction was booked cannot lie past the current moment.

A rejected date-range requesthttp

HTTP/1.1 400 Bad Request

{
  "code": "Resource.InvalidFormat",
  "message": "A query parameter has an invalid format."
}

Note the asymmetry: only the upper bound is checked against the clock. A future fromBookingDateTime is coherent — it just matches nothing — so it is accepted and returns 200. The identical three checks apply to fromStatementDate / toStatementDate on the statements endpoint.

03 What the LFI does

What your Ozone Connect implementation must do

Because the API Hub catches all three malformed cases, your Ozone Connect endpoints receive only parseable, non-contradictory ranges whose upper bound is not in the future. There is nothing to re-validate — the LFI's job is simply to filter and return:

Filter to transactions whose booking date-time falls within the supplied bounds, then apply pagination — so meta.totalRecords and meta.totalPages describe the filtered set.
Ignore any timezone offset on the supplied values — compare the wall-clock date-time as given.
Make at least two years of history available; you MAY hold and return more. The two-year figure is a minimum availability floor, not a query limit.
Return 200 with the matching subset — an empty data array where nothing matches. Never 404.

A bounded request from the API Hubhttp

GET /accounts/acc-001/transactions
  ?fromBookingDateTime=2025-01-01T00:00:00Z
  &toBookingDateTime=2025-12-31T23:59:59Z
  &page=1
  &page-size=100

An empty result is not a completeness signal

A 200 with an empty data array means "no records matched" — it does not assert the customer had no activity. For any period beyond the two-year guarantee, an empty or partial result may simply reflect what the LFI retains. TPPs are told not to infer absence of activity past that window.

Date Filters — fromBookingDateTime & toBookingDateTime

Read alongside

Pagination — LFI meta to TPP Links

FAPI Request Headers