Skip to main content
GET
Última transacción
GET https://clientapi.retailgrid.io/v1/transactions/latest devuelve una transacción con el mayor transaction_timestamp almacenado no nulo en todo el espacio de nombres de datos de tu organización. No requiere paginación ni exportación. El orden de las listas existentes y los cursores no cambian. Autentícate con la misma clave de API Bearer que en los demás endpoints públicos:
Opcionalmente, indica store_id, el UUID canónico de una tienda de la organización:
No se aceptan nombres ni códigos externos de tienda. Los UUID no válidos o en blanco devuelven 422. Los UUID desconocidos, las tiendas que pertenecen a otra organización, las tiendas sin emparejar, los espacios de nombres vacíos y los datos que solo contienen fechas de transacción nulas devuelven HTTP 200:
Una respuesta HTTP 200 con datos usa los campos de transacción existentes. Los valores decimales se serializan como cadenas; los campos opcionales siguen presentes como null:
Las claves ausentes, no válidas o revocadas devuelven 401; un contexto de organización no disponible o un acceso prohibido devuelve 403. La denegación por presupuesto de uso devuelve 429; si el control de uso no está disponible, se devuelve 503. Los fallos del proveedor son errores, nunca respuestas exitosas vacías. La consulta no crea tiendas, no resuelve alias ni asigna una tienda por defecto.

Orden y zonas horarias

La selección ordena por transaction_timestamp DESC, id DESC, ignorando las fechas nulas. Para fechas iguales, gana la cadena UUID canónica mayor. updated_at, el orden de llegada y el actor que hace la solicitud no afectan la selección dentro del espacio de nombres. BigQuery almacena este campo como DATETIME sin desplazamiento horario. Las entradas de la API con zona horaria se normalizan a UTC antes de almacenarse: 2026-01-02T00:30:00+02:00 y 2026-01-01T22:30:00Z se convierten ambas en 2026-01-01T22:30:00. Las entradas sin zona horaria conservan el valor de reloj indicado. Los valores históricos sin zona horaria no tienen una zona horaria original recuperable; la respuesta no inventa un sufijo Z ni una fecha local del cliente.

Sincronización y costo

Este máximo no es un punto de control de sincronización sin pérdidas. Reanudar estrictamente después de él puede omitir llegadas tardías, registros con fecha retroactiva, correcciones y marcas de tiempo iguales. El desempate determinista por ID no resuelve esos casos. Concilia con las listas o exportaciones de transacciones compatibles; si usas updated_since, solapa las ventanas de tiempo y aplica los registros de forma idempotente por ID de transacción. Sigue los cursores devueltos con la misma selección y el mismo límite. El endpoint de última transacción no tiene en sí un filtro por ventana de fechas. La base de datos filtra, ordena y limita el resultado a una fila; la aplicación decodifica solo esa fila. Cada llamada puede seguir recorriendo particiones históricas, y las llamadas repetidas pueden incurrir cada una en costo de lectura de la fuente. LIMIT 1 no garantiza poda de particiones ni bajo costo. Se aplican la contabilidad de uso y los topes de consulta existentes; no se crea ningún mecanismo alternativo sin límite ni ninguna exportación completa retenida. Usa las exportaciones asíncronas para extracciones grandes.