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 objetivo común: ofrecer un mayor control operativo sobre las solicitudes, sesiones y dominios que gestiona tu 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 gestionándose a través de la API. Esto es lo que se ha implementado:

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

Ahora puedes eliminar solicitudes de firma en estado de borrador mediante programación 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 el rastro de auditoría intacto para todo aquello que un firmante ya haya podido ver.

Una llamada exitosa devuelve un código 200 con el signing_request_id y una marca de tiempo en deleted_on. Si intentas eliminar una solicitud que ya se ha enviado, recibirás un código 409 en lugar de un fallo silencioso, de modo que tu código pueda bifurcarse limpiamente entre eliminar y cancelar. Un ID faltante o desconocido devuelve un código 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 replicas el estado de las firmas en tu propia base de datos, puedes suscribirte al evento y mantener tus registros sincronizados sin necesidad de realizar consultas periódicas.

El caso de uso más evidente es la limpieza de datos. Si tu integración crea borradores como parte de un flujo de creación y posterior revisión, o genera solicitudes de manera provisional y descarta las que no se utilizan, ya no tendrás que dejar borradores abandonados por ahí. Puedes eliminarlos como parte del mismo flujo encargado de crearlos.

Esto se implementó en la API v1.22.0.

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

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

Esto solo afecta a las solicitudes en las que require_otp_verification está habilitado. Si no utilizas la verificación OTP, nada cambia para ti. Para las solicitudes que sí la utilizan, no es necesaria 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.

El motivo por el que esto es importante son los dispositivos compartidos y públicos. Si un firmante abre un documento confidencial en un equipo informático que no es suyo y se marcha, una sesión que nunca expira representa un riesgo. Un periodo de inactividad estricto sumado a un límite máximo limita el tiempo que dicha sesión permanece abierta. Si gestionas acuerdos que conllevan verdaderas exigencias de confidencialidad, esto refuerza tu seguridad y te ayuda a cumplir con los requisitos de control de acceso que exigen marcos regulatorios 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 API v1.09.00.

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

Anteriormente, la eliminación de un dominio de envío de correo electrónico personalizado estaba bloqueada cuando se trataba de tu dominio principal o de tu único dominio. Dicha restricción ha desaparecido. El método DELETE en los endpoints de dominios de empresa o espacio de trabajo ahora funciona independientemente de si el dominio es el principal.

Después de eliminarlo, el envío de correos electrónicos salientes recurre al remitente predeterminado de la empresa, y luego al de la plataforma si no hay ninguno configurado para la empresa. Para migrar limpiamente a un nuevo dominio personalizado, añades el nuevo, lo verificas y lo configuras como principal. Ya no te verás en la obligación de mantener un dominio obsoleto solo porque la API no te permitía eliminar el último.

Se trata de un cambio menor, pero elimina un verdadero obstáculo para cualquiera que esté migrando dominios. La migración de dominios no debería requerir un ticket de soporte, y ahora ya no lo requiere.

Esto se implementó en la API v1.22.1.

Primeros pasos

Estos tres cambios ya están disponibles en la API. Todos los detalles sobre solicitudes y respuestas se encuentran en el registro de cambios de la API.

Empieza a utilizar Firma.dev de forma gratuita, sin necesidad de tarjeta de crédito. Pago por uso a un precio de 0,049 $ por sobre (5 ¢ USD), sin mínimos mensuales y sin contratos.