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

Este mes se han introducido 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 propio artículo, 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 mediante programación 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, se mantiene en la ruta de cancelación, lo que conserva intacto el historial 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, obtendrá un 409 en lugar de un fallo silencioso, por lo que su código puede bifurcarse limpiamente entre eliminar y cancelar. Un ID que falte o sea desconocido devuelve 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 duplica 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 introdujo 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 activada la verificación por OTP, las sesiones de los firmantes expiran ahora de forma programada y estricta. Una sesión finaliza tras una ventana de inactividad 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 verificarse 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 por 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 compartidos y públicos. Si un firmante abre un documento confidencial en un ordenador que no es el suyo y se marcha, una sesión que nunca expira es un riesgo. Una ventana de inactividad estricta más un límite máximo limitan 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 importan 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, con el ajuste OTP subyacente documentado 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 era su dominio principal o único. Esa restricción ha desaparecido. DELETE en los endpoints de dominio de la empresa o del espacio de trabajo ahora funciona independientemente de si el dominio es el principal.

Después de eliminarlo, el correo electrónico saliente vuelve al remitente predeterminado de la empresa, y luego al predeterminado de la plataforma si no se ha configurado ningún remitente de la empresa. Para cambiar 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 pequeño, 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 introdujo 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,049 € por sobre (~5 ¢ USD), sin mínimos mensuales, sin contratos.