Skip to main content
Una capacidad te indica si un cliente puede utilizar un resultado, método de pago y dirección específicos. Las tareas abiertas te indican lo que debe ocurrir antes de que esa capacidad o un recurso relacionado pueda avanzar.

​
Descubre las capacidades soportadas

Lee las opciones actuales del cliente con GET /v3/customers/{customerId}/capabilities/supported:
Elige una entrada de la respuesta que coincida con los directions, method y accountType previstos. Continúa solo cuando availability sea available o beta y eligibility.eligible sea true. Si se devuelven institutions, selecciona únicamente un ID de esa respuesta. Guarda el data[].id seleccionado como CAPABILITY_ID. Nunca copies un ID de capacidad de otro cliente o entorno.

​
Tipos de cuenta pooled vs named

Las capacidades bancarias vienen en dos variantes, codificadas como el campo accountType y el sufijo del ID de la capacidad (por ejemplo, ach_pooled, wire_named):
  • pooled: cuenta bancaria compartida de Swipelux. Cada cobro utiliza una referencia única para enrutar los fondos. Elige esta opción para transferencias de una sola vez.
  • named: datos bancarios dedicados para el cliente (IBAN virtual, cuenta ACH dedicada). Reutilizables y compartibles con cualquier pagador. Requerido para cuentas bancarias emitidas.
Por defecto usa pooled. Usa named solo cuando el cliente necesite datos bancarios reutilizables. Consulta la respuesta de supported para ver qué variantes están disponibles.

​
Solicita la capacidad

Solicita la opción seleccionada con POST /v3/customers/{customerId}/capabilities/{capabilityId}:
Utiliza un array institutions explícito solo cuando necesites seleccionar de entre los IDs devueltos por la respuesta de capacidades soportadas. Guarda data.status como CAPABILITY_STATUS, data.openTaskIds como OPEN_TASK_IDS y cada data.applications[].id en APPLICATION_IDS.

​
Completa las tareas actuales

Lista las tareas con GET /v3/customers/{customerId}/tasks, selecciona los IDs de OPEN_TASK_IDS y luego lee cada tarea actual con GET /v3/customers/{customerId}/tasks/{taskId}:
Usa la última data.revision y data.requirements. Vuelve a obtener la tarea justo antes de enviar si alguno de estos puede haber cambiado. Cada tarea abierta incluye una marca de tiempo dueAt. Cuando Swipelux crea una tarea sin una fecha de vencimiento explícita, dueAt toma por defecto exactamente 31 días después del createdAt de la tarea. Trata dueAt como informativo: no puedes definirlo a través de la API y no desencadena ninguna transición automática del ciclo de vida. Solo el campo separado deadline, cuando está presente, provoca una transición automática.

​
Acciones alojadas

En la respuesta de detalle de la tarea, cada entrada de verificationSessions y tosSessions incluye un objeto action. Las respuestas de la lista de tareas no incluyen estos enlaces de acción. Guarda el id de cada sesión y lee action.kind antes de enviar al cliente; no deduzcas la disponibilidad del enlace a partir del status de la sesión.
  • action.kind: "available" incluye action.url y action.expiresAt (actualmente siempre null). Guarda action.url, envía allí al cliente y vuelve a leer la tarea. Los campos url y expiresAt de la sesión contienen los mismos valores.
  • action.kind: "unavailable" significa que no se debe presentar ningún enlace. Los campos url y expiresAt de la sesión no aparecen. El status de una sesión por sí solo no determina qué tipo de acción recibirás.
Estas son acciones con ámbito de tarea, no un ciclo de vida independiente de verificación del cliente.

​
Sube documentos

Cuando un requisito solicite un documento, súbelo con POST /v3/customers/{customerId}/documents:
Guarda el data.id devuelto como DOCUMENT_ID antes de enviar la respuesta que lo referencia.

​
Respuestas por API

Envía un conjunto completo de respuestas para la revisión actual con POST /v3/customers/{customerId}/tasks/{taskId}/submissions:
Toma cada ID de requisito y tipo de respuesta de la última tarea. Si la API informa de que la tarea cambió, vuelve a obtenerla y reconstruye el envío a partir de la nueva revisión.

​
Prerrequisito de beneficiario final para empresas

Solicitar una capacidad de empresa que necesita evidencia de beneficiario final tiene éxito incluso cuando el cliente todavía no tiene ningún propietario que califique. La capacidad se crea como restricted con statusReason.code: tasks_due, y la tarea de intake de la empresa solicita los hechos de propiedad faltantes, incluida la estructura de propiedad. La misma tarea contiene un requisito resource_reference cuya solicitud incluye qualification: "beneficial_owner":
Una parte relacionada califica cuando es una parte person activa del mismo cliente con ownership.declared: true o un porcentaje de propiedad proporcionado de al menos 25. El requisito se deriva del listado actual de partes relacionadas, por lo que normalmente no lo respondes directamente:
  • Crear o actualizar una parte relacionada que califique cumple el requisito en la misma reevaluación y abre el trabajo de perfil y documentos propio de ese propietario. Consulta Añade partes relacionadas de la empresa.
  • También puedes referenciar explícitamente una parte que califique con una respuesta resource_reference que incluya su relatedPartyId.
  • El requisito permanece listado en la tarea actual después de cumplirse. Cuando no queda ninguna otra obligación abierta, la tarea pasa a satisfied.
  • Archivar la última parte que califica, o eliminar los hechos que la calificaban, reabre el requisito, incluso después de que la tarea haya quedado satisfied.

​
Continúa cuando la capacidad esté lista

Vuelve a leer la capacidad con GET /v3/customers/{customerId}/capabilities/{capabilityId}:
Reemplaza el estado y los IDs de tarea almacenados con la última respuesta. Continúa solo cuando el estado actual de la capacidad permita la cuenta, cotización o transferencia que planeas crear. A continuación, elige la ruta correspondiente en Flujos comunes.