Elegir un patrón
Patrón: Firma secuencial, destinatarios conocidos
Usa este patrón cuando el correo de cada destinatario se conoce en el momento del envío y los firmantes posteriores solo deben ser notificados una vez que los anteriores terminen. Este es el comportamiento predeterminado:settings.use_signing_order es 1 a menos que lo desactives, y los destinatarios firman en orden ascendente de order.
Crea los destinatarios con un orden explícito
order a cada destinatario. Los números más bajos firman primero.Envía la solicitud
create-and-send para una sola llamada, o create seguido de /send si primero necesitas un paso de revisión.Solo se notifica por correo al primer firmante
order: 1 de inmediato. Una vez que terminan, Firma envía automáticamente el correo al siguiente nivel de order — tú no controlas esto directamente. Suscríbete a los webhooks en lugar de hacer sondeo si quieres seguir cada paso.signing_request.recipient.signed si quieres seguir cada paso, y a signing_request.completed para cuando termine toda la cadena.
order solo necesitan ordenarse correctamente — no hace falta que sean contiguos. Sin embargo, los valores de order empatados (p. ej. 1, 2, 2, 5) no crean un nivel de firma paralelo — solo se notifica a un destinatario por valor de order a la vez. Si necesitas que dos firmantes firmen simultáneamente, usa el patrón paralelo con use_signing_order: false en su lugar.Patrón: Segundo firmante dinámico
Este es el caso detrás de la mayoría de los tickets de “cómo agrego un firmante a mitad del flujo”: el firmante 1 completa algo — una referencia, un cofirmante, un beneficiario — y solo entonces conoces el correo del firmante 2. El instinto es enviar la solicitud solo con el firmante 1 y luego actualizarla para agregar al firmante 2 una vez que sepas quién es. La solución alternativa es encadenar dos solicitudes de firma en lugar de modificar una:Envía la solicitud n.º 1 solo con el firmante 1
type: "text", con algún variable_name como next_signer_email) para que el firmante 1 indique quién es el siguiente firmante. Envíala con create-and-send, con exactamente un destinatario.Espera a que el firmante 1 complete
signing_request.completed se dispara en cuanto termina — no necesitas signing_request.recipient.signed en este caso.Lee el campo que completó el firmante 1
GET /signing-requests/{id}/fields y lee final_value del campo con el variable_name correspondiente.Crea y envía la solicitud n.º 2 para el firmante 2
id.original_signing_request_id) en tu propia base de datos cuando crees la solicitud n.º 2.Enfoque 1: Segunda solicitud activada por webhook
Usa este enfoque cuando los firmantes reciben invitaciones por correo electrónico y tu backend gestiona la cadena.Enfoque 2: Firma incrustada con campos de identidad editables
Usa este enfoque cuando incrustas la firma directamente en tu aplicación y quieres que el firmante 2 confirme o corrija su propia identidad al abrir la vista de firma — sin necesidad de un flujo basado en correo electrónico.Crea y envía la solicitud n.º 1 para el firmante 1
variable_name: "next_signer_email") para que el firmante 1 proporcione el correo del firmante 2. Establece send_signing_email: false, ya que tú mismo incrustarás la vista de firma.Incrusta la vista de firma del firmante 1
firma:signing:completed.Al completarse, lee el correo del firmante 2 desde el campo
GET /signing-requests/{id}/fields y lee final_value del campo con variable_name: "next_signer_email".Crea la solicitud n.º 2 con identity_editable_fields
settings.identity_editable_fields establecido en ["first_name", "last_name", "email"]. Esto permite que el firmante 2 revise y corrija su propia identidad al abrir la vista de firma — útil cuando el firmante 1 pudo haber proporcionado datos aproximados.Incrusta la vista de firma del firmante 2
identity_editable_fields: ["first_name", "last_name", "email"] permite que el firmante 2 actualice su propio nombre y correo en la vista de firma antes de firmar. Si el firmante 1 proporcionó un nombre aproximado, el firmante 2 lo corrige por sí mismo. Establece notify_identity_change_email: 1 para recibir una notificación cuando un firmante cambie su identidad.Patrón: Firma en paralelo
Usa este patrón cuando los firmantes son independientes entre sí — nadie necesita esperar a que otro termine. Establecesettings.use_signing_order: false en la solicitud. Con esta opción desactivada, Firma envía un correo a todos los destinatarios en el momento del envío, en lugar de condicionar los niveles posteriores a que terminen los anteriores. Los valores de order se siguen almacenando en cada destinatario, pero no se aplican — nadie recibe un bloqueo por firmar fuera de turno.
signing_request.completed) una vez que todos han terminado, sin importar el orden en que realmente firmen.
Patrón: Firmante y aprobador
El modelo de designación de Firma es deliberadamente excluyente: una fila de destinatario esSigner, Approver o CC — nunca más de uno. Si la misma persona necesita firmar y luego aprobar, aparece como dos filas con distintos valores de order, no como una fila con dos roles.
approval_signature, approval_checkmark y approval_date solo se pueden asignar a un destinatario cuya designation sea Approver — asignar uno a una fila Signer devuelve un 400. Su valor se genera del lado del servidor cuando el aprobador completa su revisión; tú no lo envías.Signer un order menor que a la fila Approver, y el propio paso de aprobación de Alice no se desbloqueará hasta que ella termine de firmar.
Manejo de errores: 409 ALREADY_SENT
ALREADY_SENT significa que la solicitud de firma tiene una marca de tiempo sent_on y que la operación que intentaste solo funciona en un borrador. Se devuelve, con código 409, desde:
POST /signing-requests/{id}/resend— reenvía el correo de notificación a los destinatarios que se encuentran actualmente en el nivel de firma activo y aún no han terminado. No te permite cambiar su correo ni ningún otro dato del destinatario.POST /signing-requests/{id}/cancel— detiene toda la solicitud para todos.
ALREADY_SENT al intentar corregir un correo de destinatario mal escrito o agregar un destinatario que olvidaste, no hay una corrección in situ — cancela y vuelve a crear, o (para el caso de “aún no conocía al segundo destinatario”) usa el patrón de segundo firmante dinámico descrito antes.
Próximos pasos
- Envío de una solicitud de firma — el flujo básico de creación y envío sobre el que se construyen estos patrones
- Webhooks — tipos de eventos, verificación de firma y comportamiento de reintentos
- Precarga de campos — completa campos con datos conocidos en lugar de pedirle al firmante que los complete