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:

Entrega (signature_mode)	Comportamiento al enviar 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 se devuelven en el cuerpo de la respuesta del submit, para que su sistema los entregue por su propio canal (SMS, in-app, email transaccional propio, WhatsApp).	Si el proveedor de firma falla, se devuelve 502 y el status revierte. En el portal de onboarding, al no haber un sistema externo que las reciba, el link se envía por email.
none	El legajo salta el paso de firma y pasa directo al circuito de validación.	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. El consumidor completa liveness + firma en el portal, y la firma se entrega según la entrega del flujo. 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. La entrega del flujo determina el paso de firma:

Entrega	Estado post-submit	Detalle de la respuesta
email	pending_signature	El sistema envía el link por email. La respuesta incluye signature.status: "dispatched".
api_link	pending_signature	Los links se generan sincrónicamente y se devuelven en signature.urls[]. No se envía mail.
none	pending_due_diligence	Se salta la firma. La respuesta incluye signature: { "mode": "none" }.

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.