Every API timestamp is in UTC, expressed as ISO 8601 with a Z suffix:
"created_at": "2026-08-21T14:32:09Z"This covers all temporal fields — created_at, updated_at, expires_at, last_delivery_at, dispatch_at — with no per-operation exception. Converting to the user's zone is the client's job.
The guarantee travels on every response, inside the meta block described in the response shape:
"meta": { "datetime": { "timezone": "UTC", "format": "ISO 8601" } }It is there so the fact can be asserted at runtime, rather than re-read from the specification on every release.
Date filters
Range parameters accept two forms:
| form | interpretation |
|---|---|
2026-08-21 | Bare date, interpreted in UTC. As a range start it means 00:00:00Z; as an end, 23:59:59Z |
2026-08-21T14:32:09Z | Full instant, taken as given |
A bare date is never interpreted in the caller's local zone or the server's. A created_from=2026-08-01 filter covers the month from UTC midnight, not from Mexico City midnight.
That difference matters at the edges of the range: in zones west of UTC, a report filtered by local day loses its first hours if the date is sent unadjusted. The adjustment belongs to the client, which knows the user's zone.
The transfer date
A validation's fecha field is different: it identifies the day of the SPEI operation as recorded by the sending bank, not a resource creation instant. It is sent as a bare date and carries neither time nor zone, because the CEP is queried by day.