Dates

Every timestamp the API returns is UTC, in ISO 8601 with a trailing Z. A date you send as a filter can mean one of two things, and the API decides which by the shape of the value.

Calendar dates and instants

You send	It means
2026-09-10	The calendar day of 10 September in the tenant’s time zone.
2026-09-10T14:30:00	14:30 on the tenant’s clock — a wall-clock time, read in the tenant’s zone.
2026-09-10T14:30:00Z	An exact instant. Used as sent.
2026-09-10T14:30:00+02:00	An exact instant, converted to UTC. Used as sent.

A value with a zone designator (Z, or an offset) is an instant. A value without one is a time on the tenant’s clock — which is what a person picking a date in the app means, and what an integrator copying a date off a statement means. The tenant’s time zone is set by the tenant’s own administrators (it is read and written on GET/PUT /api/tenants/{tenantId}/tax-statement-org-profile as timeZoneId, an IANA identifier, beside fiscalYearStartMonth); the platform default is America/New_York.

Range bounds

List filters come in pairs — dateFrom/dateTo, fromDate/toDate, since/until, openedFrom/openedTo, from/to. On every one of them:

• the lower bound is inclusive;
• a calendar-date upper bound includes the whole of that day, so dateFrom=2026-09-10&dateTo=2026-09-10 returns everything that happened on the 10th in the tenant’s zone;
• an instant upper bound is inclusive of that instant.

So “last week” for a New York tenant is dateFrom=2026-09-01&dateTo=2026-09-07, and the window it resolves to is 2026-09-01T04:00:00Z up to but not including 2026-09-08T04:00:00Z. Sending the same range with Z suffixes would ask for UTC days instead — four hours off at each end, and the 7th cut off at midnight.

Either bound may be omitted. 0001-01-01 and 9999-12-31 are accepted as “no bound” and are not shifted by the zone.

Parameters named …Utc

Two endpoints name their parameters fromUtc / toUtc for historical reasons (impersonation activity). They follow the same rule as every other pair: a bare calendar date is read in the tenant’s zone, an instant is used exactly. To filter by UTC day, send the instants explicitly.

Empty values

?dateFrom= with nothing after the = is not the same as omitting the parameter. It is a 400 of type errors/bad-request naming the parameter — see Errors. Omit what you do not mean to send.

Worked example

Orders placed on one tenant-local day:

curl -sS \
  -H "X-Api-Key: $AURA_API_KEY" \
  "https://api.auradonors.com/api/tenants/$TENANT_ID/orders?dateFrom=2026-09-10&dateTo=2026-09-10"

The same day expressed as instants, for a tenant in New York during daylight time:

curl -sS \
  -H "X-Api-Key: $AURA_API_KEY" \
  "https://api.auradonors.com/api/tenants/$TENANT_ID/orders?dateFrom=2026-09-10T04:00:00Z&dateTo=2026-09-11T03:59:59Z"

Prefer the first form. It stays correct across daylight-saving changes and if the tenant’s time zone is ever updated.