> ## Documentation Index > Fetch the complete documentation index at: https://developers.bloobank.com/llms.txt > Use this file to discover all available pages before exploring further. # Check Server Time > Returns the server's current time so clients can measure clock skew before signing requests. Compare `epochMs` against your local clock and apply the resulting offset when generating `X-Access-Timestamp`, which must stay within the tolerance defined by the Integration Guide. This endpoint requires **no authentication** — it can be called before any credentials are provisioned. Use this endpoint to measure the offset between your host's clock and the Bloobank server clock. The signed `X-Access-Timestamp` header must stay within **±10 seconds** of server time, so checking the offset before your first authenticated call — and periodically thereafter — prevents intermittent `TIMESTAMP_SKEW_EXCEEDED` rejections. This endpoint requires **no authentication**: no signing headers, no credentials. That also makes it a convenient connectivity check before onboarding is complete. ## Recommended usage 1. Call `GET /time` and read your local clock immediately around the call. 2. Compute `offset = epochMs − localTimeMs` (optionally correct for half the round-trip). 3. Apply the offset when signing: `X-Access-Timestamp = Date.now() + offset`. 4. Re-check periodically — and on any `TIMESTAMP_SKEW_EXCEEDED` error — since clocks drift. The `epochMs` field uses the exact same representation as `X-Access-Timestamp` (Unix epoch milliseconds, UTC), so it compares directly against `Date.now()` and equivalents. For the platform's time model, see [Date & time](/get-started/concepts/date-and-time). If your requests are rejected with clock-related errors, see [Troubleshooting](/get-started/authentication/troubleshooting). ## OpenAPI ````yaml GET /time openapi: 3.0.3 info: title: Bloobank Transactions Engine API version: 1.0.0 description: > The **Bloobank Transactions Engine API** provides wallet management and payment order orchestration for the Bloobank platform. It is the canonical entry point for inbound (cash-in) and outbound (cash-out) payment flows across supported payment networks. All requests are authenticated via the **Bloobank Access Protocol** — see the [Integration Guide](https://developers.bloobank.com/iam/integration) for request-signing rules. List endpoints follow the [List Query Parameters](https://developers.bloobank.com/api/list-query-parameters) standard with the [SFS-1 filter syntax](https://developers.bloobank.com/api/sfs-v1). This specification documents the API contract only. Integration mechanics (signing, replay protection, filter syntax, error remediation) are covered in the linked guides — single source of truth per concept. contact: name: Bloobank Developer email: developers@bloobank.com termsOfService: https://bloobank.com/legal/api-terms servers: - url: https://txengine.bloobank.com/txengine/v1 description: Production security: - AccessKey: [] AccessTimestamp: [] AccessRequestId: [] AccessSignature: [] tags: - name: Wallets description: | Tenant-scoped balance containers. Each wallet is the isolation boundary for payment orders, balances, and ledger transactions. x-displayName: Wallets - name: Payment Orders description: | Inbound (cash-in) and outbound (cash-out) payment requests routed through provider networks. x-displayName: Payment Orders - name: Server Time description: | Public utility endpoint exposing the server's current time so clients can measure clock skew before signing requests. x-displayName: Server Time externalDocs: description: Bloobank Developer Portal — guides, code samples, changelog url: https://developers.bloobank.com paths: /time: get: tags: - Server Time summary: Check server time description: | Returns the server's current time so clients can measure clock skew before signing requests. Compare `epochMs` against your local clock and apply the resulting offset when generating `X-Access-Timestamp`, which must stay within the tolerance defined by the Integration Guide. This endpoint requires **no authentication** — it can be called before any credentials are provisioned. operationId: checkServerTime responses: '200': description: The current server time. content: application/json: schema: $ref: '#/components/schemas/ServerTime' example: time: '2026-08-05T12:00:00.000Z' epochMs: 1754392800000 '500': $ref: '#/components/responses/InternalServerError' '503': $ref: '#/components/responses/ServiceUnavailable' security: [] components: schemas: ServerTime: type: object description: >- Snapshot of the server's current time, used to measure clock skew before signing requests. required: - time - epochMs properties: time: type: string format: date-time description: >- Current server time as an ISO 8601 UTC string with millisecond precision. example: '2026-08-05T12:00:00.000Z' epochMs: type: integer format: int64 description: >- Current server time in milliseconds since the Unix epoch — the same format expected in the `X-Access-Timestamp` header. example: 1754392800000 Error: type: object description: Standard error envelope returned by every non-2xx response. required: - error properties: error: type: object required: - code - status - message - details properties: code: type: integer description: HTTP status code echo. example: 401 status: allOf: - $ref: '#/components/schemas/ReasonCode' description: >- Canonical error identifier. Stable; safe to branch on programmatically. message: type: string description: >- Human-readable summary. May vary between releases — do not string-match on it. details: type: array items: $ref: '#/components/schemas/ErrorDetail' ReasonCode: type: string description: | Stable identifier returned in `error.status` and `error.details[].reason`. See the Integration Guide for the catalog of meanings and remediation steps. ErrorDetail: type: object required: - reason properties: reason: allOf: - $ref: '#/components/schemas/ReasonCode' description: Stable code identifying this specific diagnostic. description: type: string description: Human-readable explanation of the specific detail. metadata: type: object additionalProperties: true description: | Key-value context. For DENY decisions contains `decisionId`. For 5xx errors may contain `id` — the exception record id (format `exc_…`) to quote when contacting support. responses: InternalServerError: description: An unexpected error occurred on the server. content: application/json: schema: $ref: '#/components/schemas/Error' example: error: code: 500 status: INTERNAL message: An unexpected error occurred. details: - reason: INTERNAL description: Internal server error. metadata: id: exc_5KaHsBxYzW3pM2dV ServiceUnavailable: description: A downstream dependency is currently unavailable. content: application/json: schema: $ref: '#/components/schemas/Error' example: error: code: 503 status: PROVIDER_UNAVAILABLE message: Upstream payment provider is unavailable. details: - reason: PROVIDER_UNAVAILABLE description: The provider returned a transient error or did not respond. metadata: id: exc_5KaHsBxYzW3pM2dV securitySchemes: AccessKey: type: apiKey in: header name: X-Access-Key description: | Opaque credential identifier provisioned during onboarding. See the [Integration Guide](https://developers.bloobank.com/iam/integration) for the request-signing protocol. AccessTimestamp: type: apiKey in: header name: X-Access-Timestamp description: | Unix epoch timestamp in UTC milliseconds. See the Integration Guide for skew tolerance. AccessRequestId: type: apiKey in: header name: X-Access-Request-Id description: | Unique identifier per request (UUID v4 recommended). The `(accessKey, requestId)` tuple must be unique within the replay window defined by the Integration Guide. AccessSignature: type: apiKey in: header name: X-Access-Signature description: | Base64-encoded ECDSA signature of the canonical request, computed with the private key paired to `X-Access-Key`. See the Integration Guide for canonicalization rules and reference implementations. ````