Skip to main content
GET
Sincronizar movimientos con cursor
Mantén una copia fiel de los movimientos sin releer rangos. Sin cursor, la primera llamada recorre la historia visible de tu API key, página a página; cuando se agota, el next_cursor pasa a apuntar al registro de cambios y cada llamada siguiente entrega solo lo que cambió desde la anterior.

Qué trae cada lista

  • added: movimientos nuevos, con la misma forma del listado.
  • modified: movimientos que cambiaron algo visible después de creados: una pendiente que se posteó, una contraparte que se resolvió, una categoría nueva. Vienen completos; reemplaza tu copia.
  • removed: movimientos que el banco retiró o que fueron reemplazados por una posteada (posted_movement_id en el detalle). Solo id, account_id y removed_at.
Un movimiento aparece una vez por página: si en el mismo tramo se creó y se modificó, viene en added; si se retiró, solo en removed.

El cursor

Es opaco: guárdalo tal cual y mándalo en la próxima llamada. Mientras has_more sea true, sigue llamando con el next_cursor que recibes; cuando sea false, guarda el cursor y vuelve cuando quieras (o cuando llegue movement.created por webhook). limit va de 1 a 500 (default 100). La sincronización respeta el ambiente de tu key: una key sandbox recorre solo el dataset sandbox.
Lee la guía Sincronizar con cursor para la receta completa: persistencia del cursor, qué hacer ante cursor_expired y cómo tratar pending y posted.

Authorizations

Authorization
string
header
required

API Key para autenticación. Debe proporcionarse en el header Authorization con el formato: 'Api-Key YOUR-API-KEY' (incluye el prefijo 'Api-Key ' seguido de tu API key)

Query Parameters

cursor
string

El next_cursor de la respuesta anterior.

limit
integer
default:100
Required range: 1 <= x <= 500

Response

Cambios desde el cursor

added
object[]
modified
object[]
removed
object[]
next_cursor
string
has_more
boolean
limit
integer