Ejecuta una escritura o una exportación grande a través de muchos usuarios conectados en una sola llamada asíncrona. Envías un trabajo, consultas su estado y (para exportaciones y escrituras) descargas un archivo de resultados.Ejecuta una operación por lotes a través de tus usuarios conectados en una sola llamada. A diferencia de las lecturas síncronas (Obtener saldos por lotes, Obtener transacciones por lotes),
submitBulkOperation es asíncrona: valida la solicitud, crea un trabajo más un elemento por objetivo y regresa inmediatamente con un jobId. El trabajo se ejecuta en segundo plano — sigue el trabajo para monitorear el progreso y recuperar los resultados.
Una sola mutación cubre las cinco operaciones, seleccionadas por el campo operation:
Requisitos
Authorization: Basic <API_KEY>- La capacidad de API por lotes en tu aplicación.
- Los alcances que necesita la operación elegida, otorgados por cada usuario objetivo (ver la tabla arriba). Un objetivo que los carezca se convierte en una falla por elemento — nunca falla todo el trabajo.
Cada envío debe llevar una clave de idempotencia — ya sea la entrada
idempotencyKey o un encabezado Idempotency-Key (si se envían ambos, deben coincidir). Reenviar la misma clave devuelve el trabajo original en lugar de crear un duplicado, siempre que la solicitud sea idéntica byte por byte; una solicitud diferente bajo la misma clave se rechaza. No hay un valor predeterminado seguro para una escritura de fan-out, por lo que la clave es obligatoria.Mutación
QUEUED. acceptedItemCount es cuántos objetivos se procesarán; skippedItemCount es cuántos fueron rechazados de entrada (por ejemplo, por faltar el alcance requerido). Consulta el trabajo para ver cómo se completan succeededItemCount / failedItemCount — ver Seguir un trabajo por lotes.
Variables — exportar saldos / transacciones
exportOptions delimita la ventana (por defecto los últimos 90 días; GET_BALANCES_EXPORT es una instantánea en un punto en el tiempo e ignora la ventana). Usa selección de objetivos como las lecturas.
Variables — crear transferencia
Cada elemento nombra su propio endpointfrom y to, por lo que un trabajo puede mezclar direcciones: operador→usuario, usuario→operador y usuario→usuario. Un endpoint es o bien { "operator": true } (la cuenta de pagos de tu aplicación) o bien { "externalReferenceId": "…" } (un usuario conectado). from y to deben ser distintos. El grant del usuario origen debe permitir MAKE_PAYOUT_TRANSFER_SEND; el destino solo necesita estar conectado. Una transferencia permanece dentro de un mismo banco patrocinador. targetSpec no es requerido para transferencias — los participantes se toman de los elementos.
Variables — depositar saldo en efectivo
Fondea la cuenta de gasto de un usuario conectado desde un método de pago que él posee — exactamente uno debankCardId o bankAccountId por elemento. Segmentación SELECTED, un elemento por objetivo. userCashBalanceId es opcional (por defecto la cuenta de gasto permitida/predeterminada del usuario).
Variables — actualizar metadatos de transacción
Editamemo y/o transactionCategory en las transacciones de un usuario. Segmentación SELECTED, un elemento por objetivo, como máximo 100 ediciones en total por envío. Un campo establecido en null lo borra; un campo omitido queda sin cambios. Las ediciones de metadatos se ejecutan sincrónicamente — el trabajo devuelto ya es terminal, por lo que puedes leer los resultados por edición de inmediato sin consultar.
Respuesta
Argumentos
Campos de respuesta
Las fallas son por elemento — la falla de un objetivo nunca falla el trabajo (ver el contrato de fallas por objetivo). La solicitud en sí solo se rechaza por una falla de autenticación, una operación inválida, un límite excedido o cuando todos los objetivos son irresolubles. Después de un estado terminal, lee el detalle por elemento — incluyendo el recurso que produjo cada escritura — con Seguir un trabajo por lotes.