Get network date and time

GET /api/configuration/system/time/current-time

Success: 200 OK

Products: Operator (FOH), Consumer (CONSUMER) (any one of these products, not all)
Features: Online Bookings (ONLINEBOOK), Online Joining (ONLINEJOIN), Front of House Generic Access (FOHGENERIC) (any one of these features, not all)

Overview

Returns the current time, read from public NTP time servers and converted into whichever time zone you name.

Be clear about what clock this is. It is not a Gladstone business clock, not a site's trading date, and not a value stored anywhere in the platform. On each request the platform queries a public NTP server over UDP — time.google.com, then time.windows.com, then pool.ntp.org, stopping at the first that answers — reads the transmit timestamp from the reply, and converts it to the requested zone. Nothing is cached and nothing comes from your tenant's data. Two calls a second apart produce two separate NTP round trips.

The reason to use it rather than your own clock is narrow but real: it gives you a reference time that is independent of both your machine and the Gladstone server, in the same time zone the operator works in. If your integration decides whether a booking cut-off has passed, or which trading day a transaction falls on, a device with a drifting or misconfigured clock will make that decision wrong, and reconciling afterwards is painful. Reading this endpoint at the start of a session and holding the offset against your own monotonic clock is the sensible pattern.

Do not call it per operation. It is a network round trip to a third-party server on every request, it is the endpoint in this service most prone to timing out, and if UDP port 123 is blocked between the Gladstone cluster and the internet every call fails with 500 until that is fixed.

Endpoint

GET {base_url}/api/configuration/system/time/current-time

{base_url} is the environment URL issued to your integration. See Authenticating with Gladstone APIs.

Query parameters

Name	Type	Required	Description
`timeZoneId`	string	No	The zone the returned time is expressed in. Omit it and you get `Europe/London` — the default is applied server-side, so a UK integration can leave it off entirely, and an integration outside the UK that forgets it will silently receive British time rather than an error. The value is resolved by the .NET runtime's time zone lookup and the built-in default is an IANA identifier such as `Europe/London` or `America/New_York`. Anything the host cannot resolve returns `404`, not a fallback to the default.

Sample request

cURL

curl -X GET '{base_url}/api/configuration/system/time/current-time?timeZoneId=Europe/London' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'

Response fields

Field	Type	Description
`dateTime`	string (date-time)	The current time already converted into `timeZone` — a local wall-clock reading, not UTC. It is serialised with no `Z` and no `+01:00` offset, so a parser that defaults unqualified timestamps to UTC will be an hour out during British Summer Time and silently correct in winter, which is the worst kind of bug. Combine it with `timeZone` yourself, or convert back to UTC before storing. Precision comes from the NTP reply and includes milliseconds; treat it as accurate to well under a second, but not as a monotonic source — call it once and track elapsed time locally.
`timeZone`	string	The zone `dateTime` is expressed in, echoed back exactly as it was resolved. When you omitted `timeZoneId` this is how you discover the default that was applied, so read it rather than assuming. It is the identifier only — no offset and no abbreviation — so it does not on its own tell you whether daylight saving was in effect.

Sample response

200 OK

{
  "dateTime": "2026-08-14T19:00:00.123",
  "timeZone": "Europe/London"
}

Errors

Status	Meaning	When
`404`	Not found	`timeZoneId` is not a zone the server can resolve. The body is a plain-text string: `The specified time zone '{timeZoneId}' is invalid.` Note the status: an unrecognised zone is reported as `404`, not `400`, so do not treat `404` on this endpoint as "endpoint missing".
`500`	Internal server error	Every configured NTP server failed to answer — commonly a firewall blocking outbound UDP on port 123, or the NTP server list being absent from the platform's configuration. The body is empty. This is a transient infrastructure failure rather than a fault in your request, so retrying is reasonable, but if it persists there is nothing a caller can change to fix it.

This page as markdown · All pages · llms.txt