Concept

Signed JSON responses and verification

Signing is optional, explicit, and documented as a verification workflow rather than a generic response flag.

What signing changes

When `sign=true` is enabled on supported JSON routes, the gateway signs the exact UTF-8 JSON response and returns verification headers alongside the payload. That creates a cleaner audit trail for systems that cache or re-distribute results.

The site treats signing as a product capability with its own concept page, related endpoint links, and header notes so teams can evaluate it before wiring verification code.

Verification posture

Verification starts by fetching the public key set from the unauthenticated well-known endpoint. Downstream systems should verify the signature against the exact response body and the signature headers returned by the gateway.

Clock HTML is not part of this model because the clock route returns embeddable markup rather than JSON.

  • Store the raw response body before reformatting or prettifying it.
  • Use the key identifier header to select the right public key.
  • Treat the signed envelope as transport-level integrity, not as a replacement for application authorization.
Related endpoints

Public signing key set

Use this route when a downstream service needs to verify signed JSON responses from the public API.

Open endpoint

Get the current time for a target

Use this route to validate selector resolution and inspect the canonical single-target time payload.

Open endpoint

Convert a timestamp into a target timezone or offset

Use conversion when you already know the source instant and need the target rendered in another timezone or offset.

Open endpoint

Time elapsed since or remaining until a reference instant

Use elapsed when you need time since or time until a reference instant, optionally relative to another explicit comparison instant.

Open endpoint