Skip to main content
Devuelve transacciones de tus usuarios conectados como una sola lista plana, paginada por claves, con las más recientes primero. Cada fila incluye el externalReferenceId y el 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 todos los usuarios objetivo. Por defecto usa los últimos 90 días cuando no se provee un filtro de fecha.
Cambio incompatible. Esta consulta anteriormente 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 API de tu aplicación)
  • La capacidad de API en lote en tu aplicación
  • Los alcances LIST_PAYMENT y LIST_PURCHASES en la concesión de cada usuario objetivo
Los errores se reportan por objetivo y nunca fallan toda la solicitud. Consulta Descripción general de la API en lote para el modelo de direccionamiento 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, así que una ventana más amplia cuesta más por página: no es gratis. Para historiales más largos, usa la exportación.

Direccionamiento

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

Tres comportamientos a tener en cuenta:
  • Solo se devuelven transacciones PENDING y SETTLED: se excluyen declinadas y otros registros no base, coincidiendo con la superficie de transacciones de un solo usuario.
  • El orden es de las más recientes primero 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 cada concesión que puede verla: dos filas atribuidas con el mismo recordId y diferente externalReferenceId.
BulkTransaction es un tipo estrecho y creado para un fin específico. No es el tipo Transaction completo que devuelve 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.

Errores a nivel de solicitud

La solicitud completa solo se rechaza por: …además de los fallos habituales de autenticación y capacidad.

Paginación

Lee la primera página y luego sigue nextCursor hasta que hasMore sea false. Mantén idénticos todos los demás argumentos entre páginas: el cursor codifica una posición en el orden específico de esa consulta.
Como la paginación es basada 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, así 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 por transacción más ricos que los que ofrece BulkTransaction. Envía GET_TRANSACTIONS_EXPORT vía submitBulkOperation, consulta getBulkOperationJob y descarga el NDJSON desde el resultUrl de corta duración. Consulta Operaciones en lote.