Skip to main content
Devuelve transacciones de tus usuarios conectados como una sola lista plana, paginada por keyset, de más reciente a más antigua. Cada fila incluye el externalReferenceId y accountId del usuario al que pertenece. No hay límite por usuario: pagina con nextCursor para recorrer cada transacción en la ventana a través de cada usuario objetivo. De forma predeterminada toma los últimos 90 días cuando no se proporciona un filtro de fecha.
Cambio incompatible. Esta consulta previamente devolvía results, una entrada por usuario objetivo, cada una con hasta 20 transacciones. Ahora devuelve una lista plana transactions con paginación por cursor. Consulta Migración desde la respuesta por objetivo.

Requisitos

  • Authorization: Basic <API_KEY> (la clave de API de tu aplicación)
  • La capacidad de API masiva en tu aplicación
  • Los alcances LIST_PAYMENT y LIST_PURCHASES en la concesión de cada usuario objetivo
Los errores se informan por objetivo y nunca fallan toda la solicitud. Consulta Descripción general de la API masiva para el modelo de segmentación y códigos de error.

Consulta

Variables

Respuesta

Argumentos

Los límites de fechas acotan los datos; limit acota una sola página. La ventana puede abarcar como máximo 365 días. Las transacciones se almacenan en particiones mensuales y cada partición en la ventana se escanea por objetivo, por lo que una ventana más amplia cuesta más por página: no es gratis. Para historiales más largos, usa la exportación.

Segmentación

targetSpec.mode es SELECTED (nombra a los usuarios en targets, usando el externalReferenceId con el que los conectaste) o ALL_CONNECTED (cada usuario con una concesión activa en tu aplicación). Los targets duplicados se eliminan. Esta consulta acepta hasta 1,000 usuarios objetivo. Para más que eso, usa la exportación asíncrona.

Campos de la respuesta

BulkTransaction

Cuatro comportamientos a tener en cuenta:
  • transactionType es una etiqueta legible por humanos, no un enum estable: los valores se ven como "Account Transfer - In", no TRANSFER. No lo uses para lógica en el código; usa recordId y el monto/signo para la lógica, y trata este campo como texto para mostrar.
  • Solo se devuelven transacciones PENDING y SETTLED: se excluyen las rechazadas y otros registros no básicos, en consonancia con la superficie de transacciones de un solo usuario.
  • El orden es de más reciente a más antigua en todo el flujo plano (createdAt descendente, empates resueltos por recordId, luego por usuario).
  • Una transacción en una cuenta compartida aparece una vez por concesión que puede verla: dos filas atribuidas con el mismo recordId y diferente externalReferenceId.
BulkTransaction es un tipo específico y acotado. No es el tipo Transaction completo devuelto por la consulta de transacciones de un solo usuario: los campos anteriores son el conjunto completo. Para datos más ricos por transacción, usa la exportación asíncrona.

BulkTargetFailure

Un objetivo fallido nunca hace fallar la solicitud. Selecciona ambos identificadores. externalReferenceId es null para cualquier concesión que conectaste sin uno, por lo que por sí solo puede no indicarte qué usuario falló. accountId se completa siempre que el objetivo se haya resuelto, lo cual ocurre en INSUFFICIENT_SCOPE y ACCOUNT_NOT_PERMITTED, y es null solo en TARGET_NOT_CONNECTED e INVALID_TARGET_IDENTIFIER, donde nada se resolvió. Consultar errors { externalReferenceId accountId code message } significa que cada entrada es identificable por al menos uno de los dos.

Errores a nivel de solicitud

Todo lo anterior es por objetivo. Estos rechazan toda la solicitud, devolviendo data.getBulkTransactions: null más un error de GraphQL. Ramifica por extensions.code, nunca por el texto del mensaje: la redacción puede cambiar, los códigos no. Las dos fallas de fecha comparten un código: ambas significan “el rango solicitado no es utilizable”, y el message las distingue:
Un cursor alterado de cualquier manera — truncado, recodificado, editado a mano — falla como APPLICATIONS-0010 antes de llegar a la base de datos. Trátalo como “comenzar de nuevo desde la página uno”, no como reintento.

Paginación

Lee la primera página y luego sigue nextCursor hasta que hasMore sea false. Mantén idéntico cada otro argumento entre páginas: el cursor codifica una posición en el orden específico de esa consulta.
Dado que la paginación se basa en keyset y no en offset, las transacciones escritas mientras paginas no desplazarán filas entre límites de página ni producirán duplicados.

Migración desde la respuesta por objetivo

Cuándo usar la exportación en su lugar

getBulkTransactions puede recorrer el historial completo paginando, por lo que la exportación es para extracciones que prefieres no paginar: más de 1,000 usuarios, ventanas mayores a un año, trabajos por lotes programados, o cuando necesitas campos más ricos por transacción de los que contiene BulkTransaction. Envía GET_TRANSACTIONS_EXPORT mediante submitBulkOperation, consulta getBulkOperationJob y descarga el NDJSON desde el resultUrl de corta duración. Consulta Operaciones masivas.