Skip to main content
Esta guía cubre los patrones recurrentes que adoptan los flujos de firma: varios firmantes que firman en orden, firmantes que no necesitan un orden, un segundo firmante cuya identidad no se conoce hasta que el primero actúa, y un firmante que también debe aprobar. Cada patrón a continuación es una variación de crear y enviar una solicitud de firma, así que lee primero esa guía si aún no lo has hecho.

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.
1

Crea los destinatarios con un orden explícito

Asigna un order a cada destinatario. Los números más bajos firman primero.
2

Envía la solicitud

Usa create-and-send para una sola llamada, o create seguido de /send si primero necesitas un paso de revisión.
3

Solo se notifica por correo al primer firmante

Firma envía un correo a los destinatarios con 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.
Bob no recibe ningún correo hasta que Alice completa sus campos. Suscríbete a signing_request.recipient.signed si quieres seguir cada paso, y a signing_request.completed para cuando termine toda la cadena.
Los valores de 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.
Esa actualización no es posible en la misma solicitud de firma. Una vez que se establece sent_on, PATCH/PUT /signing-requests/{id} y DELETE /signing-requests/{id} devuelven todos 409 ALREADY_SENT — una solicitud de firma enviada es completamente inmutable, y eso incluye agregar un nuevo destinatario. No existe ningún endpoint que agregue un destinatario a una solicitud ya enviada, ni que cambie el correo de un destinatario en ella. Consulta Manejo de errores: 409 ALREADY_SENT más abajo para ver la lista completa de operaciones que esto bloquea.
La solución alternativa es encadenar dos solicitudes de firma en lugar de modificar una:
1

Envía la solicitud n.º 1 solo con el firmante 1

Incluye un campo (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.
2

Espera a que el firmante 1 complete

Como la solicitud n.º 1 tiene un solo firmante, signing_request.completed se dispara en cuanto termina — no necesitas signing_request.recipient.signed en este caso.
3

Lee el campo que completó el firmante 1

El payload del webhook no incluye los valores de los campos, así que llama a GET /signing-requests/{id}/fields y lee final_value del campo con el variable_name correspondiente.
4

Crea y envía la solicitud n.º 2 para el firmante 2

Usa el correo que acabas de extraer. Esta es una solicitud de firma nueva, con su propio id.
Como son dos solicitudes de firma independientes, se generan dos certificados de finalización y dos registros de auditoría independientes — no existe un único certificado que cubra a ambos firmantes. Si un certificado unificado es un requisito indispensable, la única alternativa es recopilar el correo del firmante 2 antes de enviar — por ejemplo, mediante un formulario en tu propia aplicación — en lugar de hacerlo a mitad del flujo.
Firma no tiene un campo de metadatos ni de referencia externa en la propia solicitud de firma para vincular la solicitud n.º 1 con la n.º 2. Guarda esa relación (por ejemplo, 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.
Responde 200 antes de hacer la consulta del campo y la llamada de creación y envío posterior — la entrega de webhooks de Firma tiene un tiempo de espera de 5 segundos, y el patrón anterior implica dos llamadas salientes a la API por sí solo.

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.
1

Crea y envía la solicitud n.º 1 para el firmante 1

Incluye un campo de texto (p. ej. 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.
2

Incrusta la vista de firma del firmante 1

Usa el componente de firma incrustable para renderizar la vista de firma del firmante 1 en tu aplicación. Escucha el evento postMessage firma:signing:completed.
3

Al completarse, lee el correo del firmante 2 desde el campo

Llama a GET /signing-requests/{id}/fields y lee final_value del campo con variable_name: "next_signer_email".
4

Crea la solicitud n.º 2 con identity_editable_fields

Crea una nueva solicitud de firma para el firmante 2 con 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.
5

Incrusta la vista de firma del firmante 2

Renderiza la vista de firma del firmante 2 en tu aplicación. El firmante 2 ve su identidad precargada, puede corregirla si es necesario, y firma.
Establecer 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. Establece settings.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.
Los tres reciben su correo de firma de inmediato. La solicitud se completa (y se dispara 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 es Signer, 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.
Los campos también importan aquí: los campos 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.
Esto también se combina con la firma secuencial: dale a la fila 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: Lo que puedes seguir haciendo con una solicitud enviada pero no finalizada: Si te encuentras con 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