Entrega de la firma

La entrega de la firma define qué hace el sistema con la firma electrónica del contrato cuando el legajo se envía. No es un campo que se manda en cada request: es una propiedad del flujo de apertura bajo el cual se crea el legajo. Su organización configura los flujos en el backoffice, y al crear un legajo por API se elige el flujo con el campo onboarding_flow (ver Flujo de integración).

Distinto de la entrega es el método de firma —cómo se valida la identidad de quien firma (por ejemplo, validación con clave fiscal)—, que también se configura por flujo en el backoffice, mediante reglas. El integrador no lo elige por API: el sistema aplica la regla del flujo automáticamente, y cada firma se emite con el método que corresponde.

Para saber qué flujos hay disponibles y qué entrega tiene cada uno, consultá GET /v1/onboarding-flows: devuelve, por flujo, su slug, name, is_default, requires_liveness y signature_mode (la entrega).

El campo type referenciado en las tablas y ejemplos toma dos valores: 1 para persona humana y 2 para persona jurídica (ver Flujo de integración para el detalle).

Las tres entregas

El signature_mode del flujo toma uno de tres valores. Significan lo mismo para un legajo abierto por API y para uno abierto por el portal de onboarding. Ninguna de las tres cambia lo que pasa al enviar el legajo — eso siempre va a due diligence (ver Cómo avanza el legajo) — sino qué pasa después de que el legajo es aprobado:

Entrega (signature_mode)	Comportamiento al aprobar el legajo	Restricciones
email (por defecto)	El sistema envía a cada firmante un email con el link para firmar.	Los firmantes requeridos deben tener email cargado.
api_link	Los links de firma quedan disponibles vía GET /v1/accounts/{id}/signature-links, para que su sistema los entregue por su propio canal (SMS, in-app, email transaccional propio, WhatsApp).	En el portal de onboarding, al no haber un sistema externo que las reciba, el link se envía por email.
none	El legajo se activa directamente al aprobarse, sin paso de firma.	Aplica igual a personas humanas y jurídicas.

Cómo avanza el legajo

Hay dos formas de avanzar un legajo creado por API, y la entrega del flujo opera igual en ambas:

1. Handoff al portal — POST /v1/accounts/{id}/hosted-flow/link. Devuelve un magic-link para que el consumidor termine el onboarding en el navegador. Es la vía cuando el flujo requiere biometría (requires_liveness=true) o todavía faltan datos que solo el cliente puede completar. Ver Hosted flow.
2. Submit por API — POST /v1/accounts/{id}/submit. Avanza el legajo directamente, asumiendo que ya cargaste todos los datos por API y que el flujo no requiere biometría.

El envío del legajo siempre pasa al estado pending_due_diligence, sin importar la entrega configurada — la firma no ocurre en este paso, y la respuesta del submit no incluye ningún bloque signature.

La entrega recién se aplica cuando el legajo es aprobado (automáticamente al terminar la due diligence, o manualmente por el oficial de cumplimiento): si el modo requiere firma (email o api_link), el legajo pasa a pending_signature y el sistema dispara la firma según la entrega; si la entrega es none, el legajo pasa directo a active. Consultá el estado de la firma con GET /v1/accounts/{id}/signature-links — ver Envío del legajo en Flujo de integración para el ejemplo completo del request.

Biometría (requires_liveness)

Si el legajo debe completar la captura de selfie con detección de vida (liveness) y el cotejo con el documento es una propiedad del flujo (requires_liveness), no un campo del request. Lo ve en GET /v1/onboarding-flows. Un flujo con requires_liveness=true necesita la presencia del consumidor en el portal: usá el handoff (/hosted-flow/link). Un flujo con requires_liveness=false puede avanzarse por /submit sin portal.

La responsabilidad de definir cuándo se omite el liveness corresponde al área de cumplimiento de su organización, que lo configura por flujo.

Consideraciones regulatorias para la entrega none

Un flujo configurado con none (sea para personas humanas o jurídicas) declara implícitamente que su organización cuenta con el respaldo normativo para operar sin firma electrónica del contrato gestionada por el sistema (por ejemplo, firma en papel, firma digital propia, o una exención aplicable).

Quantian Compliance no valida si la omisión de firma es regulatoriamente admisible para cada caso concreto. Esa evaluación corresponde exclusivamente al área de cumplimiento de su organización. Si tiene dudas sobre cuándo aplica, consultá con su área legal o de cumplimiento antes de configurarla.