Skip to main content
Firma envía eventos de webhook para notificar a tu aplicación sobre cambios en el ciclo de vida de firma, finalizaciones de documentos y actividades del espacio de trabajo. Los webhooks permiten integraciones en tiempo real sin necesidad de polling.

Casos de uso comunes

  • Enviar notificaciones internas cuando se firman documentos
  • Actualizar tu base de datos cuando se completan solicitudes de firma
  • Activar flujos de trabajo posteriores (facturación, aprovisionamiento, etc.)
  • Rastrear cambios de estado de las solicitudes de firma en tiempo real

Tipos de eventos

Firma envía los siguientes tipos de eventos:

Eventos de solicitud de firma

  • signing_request.created - Nueva solicitud de firma creada
  • signing_request.sent - Solicitud de firma enviada a los destinatarios
  • signing_request.viewed - El destinatario visualizó el documento
  • signing_request.completed - Todos los destinatarios terminaron de firmar
  • signing_request.expired - La solicitud de firma expiró
  • signing_request.cancelled - La solicitud de firma fue cancelada
  • signing_request.updated - Metadatos de la solicitud de firma actualizados
  • signing_request.deleted - Solicitud de firma eliminada (antes de enviarla)
  • signing_request.certificate.generated - Certificado de firma generado
  • signing_request.reminder.sent - Recordatorio enviado a los destinatarios

Eventos de destinatario

  • signing_request.recipient.signed - El destinatario completó la firma
  • signing_request.recipient.declined - El destinatario rechazó firmar
  • signing_request.recipient.identity_changed - El destinatario cambió su identidad (nombre, empresa, etc.) durante la firma

Eventos de plantilla

  • template.updated - Plantilla modificada
  • template.used - Plantilla usada para crear una solicitud de firma

Eventos de espacio de trabajo

  • workspace.created - Nuevo espacio de trabajo creado
  • workspace.updated - Espacio de trabajo modificado

Eventos de dominio

  • domain.verified - Dominio verificado correctamente
  • domain.verification.failed - Falló la verificación del dominio

Dos niveles de habilitación

La entrega de webhooks requiere que ambos interruptores estén activados: un interruptor por webhook y un interruptor maestro a nivel de cuenta. Los dos son independientes, por lo que un webhook puede crearse y habilitarse correctamente sin llegar a disparar un solo evento. Al menos un alcance (empresa o espacio de trabajo) debe tener su interruptor maestro activado para que se entregue cualquier webhook de ese alcance. Activar el interruptor maestro del espacio de trabajo también genera un secret de firma para ese espacio de trabajo si aún no existe uno.
POST /webhooks/{id}/test omite el interruptor maestro. Una entrega de prueba puede tener éxito incluso cuando el interruptor maestro está desactivado y los eventos reales no se están entregando - una prueba exitosa no confirma que los eventos reales se disparen.
Cuando el interruptor maestro está desactivado, Firma omite el evento antes de registrar un intento de entrega. consecutive_failures permanece en 0 y el webhook no muestra historial de fallos, aunque no se esté entregando nada - no hay ningún error que te alerte.

Permisos

Activar o desactivar el interruptor maestro a nivel de empresa requiere acceso de propietario o administrador de la empresa; los miembros de solo lectura no pueden habilitarlo ni deshabilitarlo. Intentar cambiarlo sin permisos suficientes devuelve un error de permisos.

Crear un webhook

Crea webhooks a través de la API o del panel:
Tu URL de webhook debe usar HTTPS y responder en un plazo de 5 segundos. Usa POST /webhooks/{id}/test después de la creación para verificar que tu endpoint está recibiendo eventos correctamente.

Estructura del payload del webhook

Todos los eventos de webhook siguen esta estructura estándar:

Seguridad: Verificación de firma (Obligatorio)

Siempre verifica las firmas de los webhooks para prevenir ataques de suplantación. No proceses webhooks sin verificación de firma.
Firma firma todas las solicitudes de webhook usando HMAC SHA-256. Tu endpoint de webhook recibe estos headers:
  • X-Firma-Signature - Firma HMAC usando el secret de firma actual
  • X-Firma-Signature-Old - Firma HMAC usando el secret anterior (durante el período de gracia de rotación de 7 días)
  • X-Firma-Event - Tipo de evento (por ejemplo, signing_request.completed)
  • X-Firma-Delivery - ID único del intento de entrega

Formato de la firma

Firma usa un header de firma con marca de tiempo:
  • Header: X-Firma-Signature: t=1707500000,v1=abc123def456...
  • t = Marca de tiempo Unix (segundos) cuando se generó la firma
  • v1 = Digest hexadecimal HMAC-SHA256
  • Formato del payload firmado: {timestamp}.{json_body}
Ejemplo:

Obtén tu secret de firma

  1. Ve a tu panel de Firma
  2. Consulta los detalles del webhook para obtener el secret de firma
  3. Almacena el secret de forma segura (variable de entorno o gestor de secretos)

Ejemplo de verificación - Node.js (Express)

Ejemplo de verificación - Python (Flask)

Manejo de rotación de secrets

Cuando rotas tu secret de firma de webhooks:
  1. Firma genera un nuevo secret
  2. Durante 7 días, Firma envía ambas firmas:
  • X-Firma-Signature (secret nuevo)
  • X-Firma-Signature-Old (secret anterior)
  1. Después de 7 días, solo se envía X-Firma-Signature
Implementación: Verifica primero X-Firma-Signature. Si la verificación falla y X-Firma-Signature-Old existe, verifica contra el secret anterior.

Comportamiento de reintentos

Firma reintenta automáticamente las entregas de webhooks fallidas:
  • Programa de reintentos: Inmediato, luego +5 minutos, luego +1 hora
  • Total de intentos: Hasta 3 intentos por evento
  • Tiempo de espera: Tu endpoint debe responder en un plazo de 5 segundos
  • Éxito: Cualquier código de estado 2xx indica éxito
  • Desactivación automática: Después de 50 fallos consecutivos, el webhook se desactiva automáticamente
Mejor práctica: Responde con 200 inmediatamente y luego procesa los eventos de forma asíncrona (cola, tarea en segundo plano, etc.) para evitar tiempos de espera agotados.

Idempotencia

Siempre maneja eventos duplicados usando el id del evento:

Monitorear la salud del webhook

Monitorea la salud de tu webhook consultando los detalles del webhook:
La respuesta incluye:
  • consecutive_failures - Número de entregas fallidas consecutivas
  • last_failure_at - Marca de tiempo del fallo más reciente
  • enabled - Si el webhook está activo (se desactiva automáticamente después de 50 fallos)
  • last_success_at - Marca de tiempo de la entrega exitosa más reciente
Límite de tasa: Todas las operaciones de /webhooks (tanto GET como de escritura) comparten un límite de 60 solicitudes por minuto por clave API. POST /webhooks/{id}/test tiene su propio límite independiente de 10 solicitudes por minuto.

Solución de problemas

Problemas comunes

Los webhooks están configurados pero los eventos no se disparan Esta es la causa más común de los reportes de “mi webhook no funciona”. La configuración por webhook puede ser completamente correcta mientras el interruptor maestro a nivel de cuenta está desactivado, lo que omite silenciosamente todos los eventos.
  • Confirma que el interruptor maestro está activado para el alcance correcto: los webhooks a nivel de empresa necesitan el interruptor de la empresa activado, los webhooks a nivel de espacio de trabajo necesitan el interruptor de ese espacio de trabajo activado.
  • No confíes en una prueba exitosa como prueba definitiva - POST /webhooks/{id}/test omite el interruptor maestro, por lo que puede tener éxito aunque los eventos reales no se disparen.
  • Revisa consecutive_failures en el webhook - si muestra 0 y no aparecen eventos, eso también apunta al interruptor maestro, ya que los eventos omitidos nunca se registran como intentos de entrega fallidos.
  • Si no encuentras o no puedes cambiar el interruptor maestro, es posible que no tengas permisos de propietario o administrador en la empresa; pide a un propietario o administrador que lo active desde Configuración > Webhooks.
401 Unauthorized / Firma inválida
  • Verifica que estás usando el secret de firma correcto
  • Comprueba que estás hasheando el cuerpo de la solicitud sin procesar (no el JSON parseado)
  • Asegúrate de estar usando HMAC SHA-256 y no otro algoritmo de hash
Tiempos de espera agotados / errores 504
  • Responde con 200 inmediatamente y procesa de forma asíncrona
  • Comprueba que tu endpoint responde en un plazo de 5 segundos
  • Usa tareas en segundo plano/colas para el procesamiento pesado
Eventos duplicados
  • Implementa idempotencia usando el id del evento
  • Almacena los IDs de eventos procesados en tu base de datos
Webhook desactivado automáticamente
  • Revisa consecutive_failures y los registros de eventos recientes
  • Corrige los problemas del endpoint y luego vuelve a activar el webhook mediante la API o el panel

Probar webhooks localmente

Usa un servicio de túnel como ngrok para el desarrollo local:

Lista de verificación para producción

  • Verificar las firmas HMAC en todas las solicitudes de webhook
  • Manejar la rotación de firmas (comprobar tanto X-Firma-Signature como X-Firma-Signature-Old)
  • Responder con 200 en un plazo de 5 segundos
  • Procesar eventos de forma asíncrona (colas/tareas en segundo plano)
  • Implementar idempotencia usando el id del evento
  • Almacenar el secret de firma de forma segura (variable de entorno o gestor de secretos)
  • Monitorear la métrica consecutive_failures mediante el endpoint GET de webhook
  • Configurar alertas para fallos de webhooks
  • Registrar todos los eventos de webhook para depuración
  • Probar con todos los tipos de eventos suscritos
  • Mantente dentro de los límites de tasa (Consulta la Guía de Límites de Tasa)

Próximos pasos