Skip to main content

Descripción general

La mutación requestOwnerDocumentVerificationLink genera una URL compartible que un propietario de negocio puede usar para completar la verificación de identidad por documento. El enlace funciona por sí solo: el propietario no necesita credenciales de Fluz. Úsalo para propietarios cuyos getBusiness reportan verificationType: DOCUMENTS y status: PENDING_CIP. Esos son beneficiarios finales o personas de control enviadas con isUsPerson: false, lo cual los coloca en la ruta de documentos en lugar de la ruta de SSN.
Los propietarios en la ruta de SSN (verificationType: SSN) no necesitan usar esta mutación, y tampoco los propietarios invitados que aún no han aceptado — Fluz les envía un correo directo y ellos se verifican por su cuenta.

Alcances requeridos

Usa un token emitido para la cuenta de negocio que devolvió registerBusiness.

Requisitos previos

Todos estos deben cumplirse, o la llamada fallará:
1

Un token de cuenta de negocio con REGISTER_BUSINESS

Con alcance al negocio que es dueño del roster.
2

El caso está en estado enviado para revisión (submitted-for-screening)

El enlace solo puede generarse durante un estado específico después del envío. Los casos que aún se están creando, que ya están esperando resultados de screening, o que están en revisión manual serán rechazados — aunque getBusiness reporta todos esos como kybStatus: PENDING. Ver Tiempo.
3

businessOwnerId es el ID de usuario de negocio del propietario

Tomado de owners[].id en getBusiness, y perteneciente a este negocio. No se acepta un ID de usuario de Fluz, y los propietarios invitados que aún no han aceptado tienen id: null.
4

El propietario está en la ruta de documentos

verificationType: DOCUMENTS con status: PENDING_CIP.

Estructura básica de la mutación

Parámetros

Detalles de la respuesta

Los fallos se devuelven como errores de GraphQL de nivel superior, no como success: false. Verifica el arreglo errors, no solo el payload de datos. Esto es lo opuesto a registerBusiness, que reporta fallos de validación dentro de su payload.

Tiempo

El requisito de estado en el prerrequisito 2 es la razón más común por la que esta llamada falla, y no es visible a través de kybStatus.
Llámalo temprano. Poco después de que registerBusiness devuelva respuesta, tan pronto como getBusiness muestre al propietario con verificationType: DOCUMENTS y status: PENDING_CIP.Si recibes ARG-0001 con business is not submitted for approval, el caso ya pasó — o aún no ha llegado — a esa ventana. No reintentes en un bucle. Sigue leyendo getBusiness, y contacta a tu account manager con el accountId si un propietario permanece en PENDING_CIP sin forma de enviarle un enlace.

Ejemplo cURL

Respuesta de ejemplo

Éxito

Error

Códigos de error

Notas

  • El enlace generado es de un solo propósito. Si el enlace del propietario expira o se pierde, llama a la mutación nuevamente para obtener uno nuevo en lugar de reutilizar el anterior.
  • Generar un enlace no cambia el status del propietario. Pasa a READY solo cuando el propietario realmente complete la verificación — sigue leyendo getBusiness.
  • No existe una variante masiva. Llama una vez por cada propietario que necesite un enlace.

Páginas relacionadas

Estado de KYB del negocio

Identifica qué propietarios necesitan un enlace y confirma cuando terminen.

Descripción general de KYB

Dónde se ubica este paso en el flujo de extremo a extremo.

Registrar un negocio

Cómo isUsPerson coloca a un propietario en la ruta de documentos.