Consulta el estado y los contadores de un trabajo en lote, lee los resultados por objetivo y descarga el archivo de resultados.Después de enviar una operación en lote, síguela con dos consultas:
getBulkOperationJob para el estado del trabajo y contadores agregados, y getBulkOperationItems para el detalle por objetivo. La finalización es solo por sondeo — no hay webhooks de lote.
Requisitos
Authorization: Basic <API_KEY>- La capacidad de API de lote en tu aplicación.
- El trabajo debe pertenecer a tu aplicación — un id de trabajo desconocido o de otra aplicación devuelve no encontrado.
Consulta — estado del trabajo
Sondéalo hasta questatus sea terminal (COMPLETED, COMPLETED_WITH_ERRORS, FAILED o CANCELLED).
Consulta — resultados por objetivo
Paginada por cursor (100 por página) y filtrable por estado del ítem — filtra aFAILED para conciliar solo los fallos, o lee resultResourceId para mapear una escritura exitosa al recurso de Fluz que produjo.
Descargar el archivo de resultados
SeleccionarresultUrl genera una URL de descarga firmada de corta duración (~15 minutos), producida bajo demanda — consultar el estado sin ella se mantiene económico. Ábrela (o curl -L) para descargar un archivo NDJSON, una fila por objetivo.
- Exportaciones (
GET_*_EXPORT) — los saldos/transacciones exportados. - Escrituras (
CREATE_TRANSFER,DEPOSIT_CASH_BALANCE) — un libro de resultados:{ externalReferenceId, accountId, status, resultResourceId, resourceType, errorCode, errorMessage }por objetivo.
resultUrl es null hasta que el trabajo sea terminal, y para trabajos que no produjeron archivo. Solicita el campo nuevamente para una URL fresca una vez que expire (resultUrlExpiresAt).
Argumentos
Campos de la respuesta
getBulkOperationItems y el archivo de resultados son dos vistas de los mismos datos por ítem. Usa la consulta de ítems para conciliar programáticamente (filtra a FAILED, mapea resultResourceId); usa el archivo de resultados para extraer todo el libro de una vez para trabajos grandes.Errores
Estas consultas fallan en su totalidad solo por la solicitud en sí — un objetivo inválido nunca es un error de solicitud, es un resultado por ítemFAILED/SKIPPED (ver abajo).
Códigos de fallo por ítem
Un ítemFAILED o SKIPPED lleva un errorCode legible por máquina y un errorMessage humano. Los códigos SKIPPED se asignan al enviar (el objetivo nunca ingresó a la cola); los códigos FAILED provienen ya sea de la validación al enviar o, para ítems aceptados, del servicio downstream en el momento de la ejecución.
Cualquier operación:
Solo
CREATE_TRANSFER:
Solo
DEPOSIT_CASH_BALANCE:
Los códigos con prefijo de categoría son asignados por Fluz; una fila downstream significa que el ítem lleva literalmente el código de error propio del servicio ejecutor, por lo que esos códigos están abiertos. Programa contra los códigos que manejas y trata los desconocidos como un fallo genérico — lee
errorMessage para el motivo legible por humanos.