Consulta periódicamente el estado y los contadores de un trabajo en lote, lee los resultados por destino y descarga el archivo de resultados.Después de enviar una operación en lote, síguelo con dos queries:
getBulkOperationJob para el estado del trabajo y contadores agregados, y getBulkOperationItems para el detalle por destino. La finalización es solo por sondeo — no hay webhooks de lote.
Disponible solo en
staging por ahora.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 not-found.
Query — estado del trabajo
Sondéalo hasta questatus sea terminal (COMPLETED, COMPLETED_WITH_ERRORS, FAILED o CANCELLED).
Query — resultados por destino
Paginado por cursor (100 por página) y filtrable por estado del item — filtra aFAILED para conciliar solo los fallidos, 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 — sondear el estado sin ella se mantiene económico. Ábrela (o curl -L) para descargar un archivo NDJSON, una fila por destino.
- 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 destino.
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 respuesta
getBulkOperationItems y el archivo de resultados son dos vistas de los mismos datos por item. Usa la query de items 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 queries fallan en su totalidad solo por la solicitud en sí — un destino inválido nunca es un error de solicitud, es un resultado por itemFAILED/SKIPPED (ver abajo).
Códigos de falla por item
Un itemFAILED o SKIPPED lleva un errorCode legible por máquina y un errorMessage humano. Los códigos SKIPPED se asignan al enviar (el destino nunca entró a la cola); los códigos FAILED provienen ya sea de validación al enviar o, para items aceptados, del servicio downstream en tiempo de 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 item lleva el propio código de error del servicio ejecutor de forma literal, por lo que esos códigos están abiertos. Programa contra los códigos que manejes y trata los desconocidos como una falla genérica — lee
errorMessage para la razón legible por humanos.