Skip to main content
GET
Latest transaction
GET https://clientapi.retailgrid.io/v1/transactions/latest returns one transaction with the greatest non-null stored transaction_timestamp across your organization’s data namespace. It requires no pagination or export. Existing list ordering and cursors are unchanged. Authenticate with the same Bearer API key as other public endpoints:
Optionally supply store_id, a canonical organization store UUID:
Names and external store codes are not accepted. Invalid or blank UUIDs return 422. Unknown UUIDs, stores belonging to another organization, unmatched stores, empty namespaces, and data containing only null transaction dates all return HTTP 200:
A populated HTTP 200 response uses the existing transaction fields. Decimal values serialize as strings; optional fields remain present as null:
Missing, invalid or revoked keys return 401; unavailable organization context or forbidden access returns 403. Usage-budget denial returns 429; unavailable usage enforcement returns 503. Provider failures are errors, never empty successes. The lookup does not create stores, resolve aliases or assign a default store.

Ordering and timezones

Selection orders by transaction_timestamp DESC, id DESC, ignoring null dates. For equal dates, the greatest canonical UUID string wins. updated_at, arrival order and the requesting actor do not affect selection within the namespace. BigQuery stores this field as DATETIME without an offset. Aware API inputs are normalized to UTC before storage: 2026-01-02T00:30:00+02:00 and 2026-01-01T22:30:00Z both become 2026-01-01T22:30:00. Naive inputs retain their supplied wall-clock value. Historical naive values have no recoverable original timezone; the response does not invent a Z suffix or a client-local date.

Synchronization and cost

This maximum is not a lossless synchronization checkpoint. Resuming strictly after it can miss late arrivals, backdated records, corrections and equal timestamps. The deterministic ID tie-break does not solve those cases. Reconcile with supported transaction lists or exports; where using updated_since, overlap time windows and apply records idempotently by transaction ID. Follow returned cursors with the same selection and limit. The latest endpoint itself has no date-window filter. The database filters, sorts and limits the result to one row; the application decodes only that row. Each call can still scan historical partitions, and repeated calls can each incur source-scan cost. LIMIT 1 is not a partition-pruning or low-cost guarantee. Existing usage accounting and query ceilings apply; no uncapped fallback or retained full export is created. Use asynchronous exports for large extractions.