Actualizaciones de productos, junio de 2026: Limpieza de borradores, seguridad de la sesión y gestión de dominios

Este mes se han lanzado tres cambios que comparten un hilo común: un mayor control operativo sobre las solicitudes, sesiones y dominios que gestiona su integración. Ninguno de ellos es lo suficientemente grande como para tener su propia publicación, pero juntos cubren el tipo de tareas de mantenimiento que resultan importantes una vez que se tiene un volumen real de ejecución a través de la API. Esto es lo que ha llegado.

Eliminar solicitudes de firma no enviadas a través de la API

Ahora puede eliminar programáticamente los borradores de solicitudes de firma con DELETE /signing-requests/{id}. Esto se aplica únicamente a las solicitudes que aún no se han enviado. Una vez que se envía una solicitud, esta se mantiene en la ruta de cancelación, lo que conserva intacto el registro de auditoría de cualquier cosa que el firmante ya haya podido ver.

Una llamada correcta devuelve un 200 con el signing_request_id y una marca de tiempo deleted_on. Si intenta eliminar una solicitud que ya se ha enviado, recibirá un 409 en lugar de un fallo silencioso, de modo que su código pueda bifurcarse limpiamente entre eliminar y cancelar. Si el ID no existe o es desconocido, se devuelve un 404.

También hay un nuevo evento de webhook signing_request.deleted que se activa cada vez que se elimina una solicitud a través de la API. Si refleja el estado de la firma en su propia base de datos, puede suscribirse a él y mantener sus registros sincronizados sin necesidad de realizar consultas periódicas.

El caso de uso obvio es la limpieza. Si su integración crea borradores como parte de un flujo de creación y posterior revisión, o genera solicitudes de forma especulativa y descarta las que no se utilizan, ya no tendrá que dejar borradores abandonados. Puede eliminarlos como parte del mismo flujo que los creó.

Esto se lanzó en la versión v1.22.0 de la API.

Expiración de sesión de firmante más estricta en solicitudes protegidas por OTP

Para las solicitudes que tienen habilitada la verificación OTP, las sesiones de los firmantes ahora expiran siguiendo un cronograma estricto. Una sesión finaliza tras una ventana de inactividad dinámica de 4 horas, o 12 horas después de la última verificación como límite máximo, lo que ocurra primero. Cuando una sesión expira, el firmante vuelve a realizar la verificación con un nuevo código de 6 dígitos. Ese código es válido durante 10 minutos, permite 5 intentos y tiene un tiempo de espera de reenvío de 60 segundos.

Esto solo afecta a las solicitudes en las que require_otp_verification está activado. Si no utiliza la verificación OTP, nada cambia para usted. Para las solicitudes que sí la utilizan, no se requiere ninguna acción por parte del remitente y los enlaces de firma existentes siguen funcionando. El nuevo comportamiento de expiración simplemente se aplica de forma adicional.

La razón por la que esto es importante son los dispositivos públicos y compartidos. Si un firmante abre un documento confidencial en un equipo que no es el suyo y se marcha, una sesión que nunca expira constituye un riesgo. Una ventana de inactividad estricta junto con un límite máximo limita el tiempo que esa ventana permanece abierta. Si gestiona acuerdos que conllevan expectativas reales de confidencialidad, esto refuerza su postura y le ayuda a cumplir con las expectativas de control de acceso que interesan a marcos de trabajo como HIPAA y SOC 2.

Los detalles se encuentran en la entrada de actualizaciones de la plataforma del 29 de mayo, y la configuración de OTP subyacente está documentada a partir de la versión v1.09.00 de la API.

Eliminar un dominio de envío de correo electrónico principal o único

Antes, la eliminación de un dominio de envío de correo electrónico personalizado estaba bloqueada cuando se trataba de su dominio principal o único. Esa restricción ha desaparecido. El método DELETE en los endpoints de dominio de la empresa o del espacio de trabajo ahora funciona independientemente de si el dominio es el de carácter principal.

Después de eliminarlo, el correo electrónico saliente recurre al remitente predeterminado de la empresa y, a continuación, al predeterminado de la plataforma si no se ha configurado ningún remitente de la empresa. Para migrar a un nuevo dominio personalizado de forma limpia, añada el nuevo, verifíquelo y establézcalo como principal. Ya no tendrá que mantener un dominio obsoleto solo porque la API no le permitía eliminar el último.

Se trata de un cambio menor, pero elimina un verdadero punto de fricción para cualquiera que migre dominios. La migración de dominios no debería requerir un ticket de soporte, y ahora ya no es necesario.

Esto se lanzó en la versión v1.22.1 de la API.

Primeros pasos

Los tres cambios ya están disponibles en la API. Los detalles completos de las solicitudes y respuestas se encuentran en el registro de cambios de la API.

Comience a utilizar Firma.dev gratis, sin necesidad de tarjeta de crédito. Pago por uso a 0,029 $ por sobre (2,9 ¢ USD), sin mínimos mensuales ni contratos.