En este documento se destacan las nuevas funciones, los cambios de la experiencia y los problemas resueltos en la aplicación dirigida al cliente para la versión más reciente.

Las actualizaciones centradas en los desarrolladores de la API y los webhooks se documentan en la Guía para desarrolladores de Acrobat Sign.

No se garantiza que todas las funciones y cambios estén activados en la fecha de lanzamiento. Consulte siempre la versión en inglés estadounidense de la página como la versión más actual y precisa.

Adobe Acrobat Sign versión 17.0.1

Implementación de producción: 17 de marzo de 2026

Implementación de GovCloud: 19 de marzo de 2026

Funcionalidad mejorada

Crear una copia: puntos de acceso ampliados, reutilización más rápida de acuerdos.
Crear una copia ya está disponible directamente a través de los filtros En curso y Pendientes de la página Administrar, así como desde la página de confirmación posterior al envío. Estos puntos de entrada adicionales facilitan la reutilización de acuerdos en más momentos del ciclo de vida del envío, reduciendo la necesidad de empezar desde cero.
Nota: Con esta versión, los controles administrativos para deshabilitar esta función se eliminarán del menú de administración, estableciendo Crear una copia como una capacidad estándar disponible para todos los usuarios elegibles.

Entornos disponibles: zona protegida, comercial, administración pública | Niveles de servicio disponibles: Acrobat Sign Solutions | Ámbito de configuración: cuenta y grupo; habilitado de manera predeterminada.

Consulte la documentación de acción del usuario actualizada >

Cambios de la experiencia

Visibilidad de la caducidad de las claves de integración: las fechas de caducidad ahora se muestran en la pestaña Tókenes de acceso
La pestaña Tókenes de acceso, en el menú Preferencias personales, muestra la fecha de caducidad para cada clave de integración. Esto proporciona a los usuarios y administradores una visibilidad más clara sobre la antigüedad de las claves y el momento de reemplazo, facilitando la monitorización de las claves existentes y el poder evitar interrupciones inesperadas cuando una clave alcanza el final de su período de validez de 10 años.

Entornos disponibles: zona protegida, comercial, administración pública Niveles de servicio disponibles:Acrobat Sign Solutions Ámbito de configuración: API

Actualizaciones de Webhook o de la API de REST

Las actualizaciones de la API y webhook para esta versión se encuentran en la Documentación de API de Acrobat Sign.

Visualización de correo electrónico personalizado OEM 2.0: identidad más clara de remitente y destinatario en las distintas experiencias integradas, y envío correcto de correo electrónico.
Para los socios de OEM 2.0 que utilizan flujos de trabajo integrados, Acrobat Sign ahora puede mostrar el correo electrónico personalizado de un usuario en lugar del correo electrónico registrado del socio en las distintas superficies de interfaz de uso clave y notificaciones. Los acuerdos, colas como “Pendiente” y correos electrónicos de “Revisar y firmar” reflejan consistentemente la identidad personalizada mientras conservan el correo electrónico registrado internamente para autenticación y derechos. Esto mejora la claridad para remitentes y firmantes y evita que los correos electrónicos se envíen a direcciones registradas que no se pueden entregar.

Entornos disponibles: Sandbox, Comercial | Niveles de servicio disponibles: Acrobat Sign Solutions | Ámbito de configuración: API - Socios OEM 2.0; solo bajo solicitud

Notificación del webhook para fallos en la entrega de SMS: visibilidad en tiempo real de los envíos de SMS fallidos, remediación automatizada y paridad con los rebotes de correo electrónico.
Acrobat Sign ahora emite un nuevo evento webhook, AGREEMENT_PHONE_BOUNCED, cuando un acuerdo enviado por SMS no puede ser entregado debido a problemas como números de teléfono no válidos, rechazo del operador o líneas bloqueadas. Esto permite a los clientes detectar fallos en la entrega de SMS en casi tiempo real y activar automáticamente acciones de seguimiento, como corregir números de teléfono, reintentar la entrega o abrir casos de soporte, eliminando puntos débiles y reduciendo retrasos en los flujos de trabajo de firma primero en dispositivos móviles.

Entornos disponibles: zona protegida, comercial, administración pública Niveles de servicio disponibles: Acrobat Sign Solutions Ámbito de configuración: API

Cargas útiles de webhook: se ha añadido un campo condicional extendedStatus del participante para actualizaciones de participación dinámicas, mejorando la visibilidad del estado del participante.
Las notificaciones de webhook ahora incluyen un campo extendedStatus en cada objeto participante (memberInfos[]) cuando el remitente modifica un acuerdo en curso usando participación dinámica. Este campo proporciona detalles adicionales del ciclo de vida del participante mientras deja el campo de estado existente sin cambios para compatibilidad con versiones anteriores.

        {
          &quot;participantSets&quot;: [
            {
              &quot;id&quot;: &quot;&quot;,
              &quot;memberInfos&quot;: [
                {
                  &quot;company&quot;: &quot;TestCo&quot;,
                  &quot;email&quot;: &quot;signer2@someDomain.dom&quot;,
                  &quot;id&quot;: &quot;CBJCHBCAABAAJiZV9cH&quot;,
                  &quot;name&quot;: &quot;Signer Two&quot;,
                  &quot;status&quot;: &quot;ACTIVE&quot;,
                  &quot;extendedStatus&quot;: &quot;REMOVED&quot;
                }
              ],
              &quot;order&quot;: ,
              &quot;role&quot;: &quot;&quot;,
              &quot;status&quot;: &quot;&quot;
            }
          ]
        }

Valores de status (sin cambios): ACTIVE, REPLACED.
Valores de extendedStatus: ACTIVE, REPLACED, REMOVED, COMPLETED.

Entornos disponibles: zona protegida, comercial, administración pública | Niveles de servicio disponibles: Acrobat Sign Solutions | Ámbito de configuración: API

Problemas resueltos

Problema	Descripción
4543515	Resumen: un evento de rebote de correo electrónico de webhook puede generarse incorrectamente para un firmante válido después de que el firmante firme correctamente y el acuerdo avance al siguiente paso. Esto puede ocurrir cuando un delegado en el mismo grupo de firma tiene un correo electrónico no válido y el remitente reemplaza al delegador original. En estos casos, el sistema puede atribuir incorrectamente el evento de rebote “firmado en nombre de...” al firmante válido en lugar del participante cuyo correo electrónico realmente rebota.
4543515	Solución: la lógica de atribución de eventos se ha corregido para que los eventos de rebote de correo electrónico se asocien únicamente con el participante cuyo correo electrónico rebota en realidad. Ya no se genera un evento de rechazo para un firmante válido que ya completó la firma, y las notificaciones de webhook ahora reflejan el participante y correo electrónico correctos.
4544548	Resumen: las claves de integración creadas a través de la interfaz de usuario web pueden caducar después de 10 años, aunque la página de creación establece que la clave proporciona “acceso permanente”. Cuando una clave alcanza los 10 años de su vida útil, las llamadas de API comienzan a devolver un error de token caducado, lo que puede romper las integraciones existentes de manera inesperada.
4544548	Solución: se ha actualizado la mensajería de la interfaz de usuario para eliminar el texto “acceso permanente” y mostrar claramente la fecha de caducidad de las claves de integración. El texto actualizado ahora indica que la clave conserva el acceso hasta la fecha de caducidad o hasta que se revoque manualmente, lo que clarifica la confusión acerca de los 10 años de vida útil predeterminada.
4546301	Resumen: el envío de eventos del webhook puede retrasarse hasta varias horas para acuerdos con documentos muy grandes, incluso cuando la creación del acuerdo finaliza y los pasos de procesamiento iniciales parecen concluir en cuestión de minutos. Durante la ventana de retraso, el servicio de entrega de webhook puede recibir repetidamente respuestas DOCUMENT_NOT_AVAILABLE al intentar recuperar documentos del acuerdo, y el evento de webhook puede no entregarse hasta que el servicio deje de reintentar o los documentos estén disponibles.
4546301	Corrección: Se corrigió el manejo de disponibilidad de documentos para que los acuerdos grandes hagan la transición de manera confiable a un estado donde los documentos sean recuperables sin respuestas DOCUMENT_NOT_AVAILABLE extendidas. Como resultado, los eventos de webhook se entregan sin retrasos de varias horas causados por reintentos de recuperación de documentos contra documentos no disponibles.
4547823	Resumen: el mensaje privado de un destinatario puede no mostrarse para algunos firmantes cuando se crea un acuerdo en el estado Creación a través de la API y luego se edita desde la experiencia Administrar. En este escenario, la interfaz de usuario puede mostrar el valor del mensaje privado como “Ninguno” o en blanco aunque los datos del acuerdo incluyan el valor del mensaje privado correcto. Este comportamiento aparece en escenarios de cuentas compartidas donde un usuario cambia a la cuenta de otro usuario para editar el borrador, y puede afectar solo a destinatarios específicos mientras que otros se muestran correctamente.
4547823	Solución: se ha añadido una marca de verificación para recuperar el contexto de uso compartido activo y devolver el mensaje privado para los usuarios compartidos autorizados. Como resultado, el valor del mensaje privado ahora se muestra correctamente cuando se ve o se envía un borrador creado por la API desde el flujo Creación.
4548274	Resumen: la fecha modificada para las plantillas de biblioteca puede no actualizarse después de que una plantilla se edite y guarde en la nueva experiencia de plantilla. Los usuarios pueden ver campos recién agregados o actualizados en la plantilla, pero la fecha modificada permanece sin cambios en la interfaz de uso Administrar y en vistas administrativas, lo que hace que parezca que la plantilla no fue modificada recientemente. Esto ocurre porque la nueva experiencia actualiza los campos de formulario a través de una ruta que no actualiza también la marca de tiempo modificada de la plantilla.
4548274	Solución: el comportamiento de la actualización de fecha modificada se ha alineado en la nueva experiencia de plantilla y las operaciones de API relacionadas. La ruta de código que guarda cambios de campos de plantilla ahora también actualiza la fecha modificada de la plantilla para que refleje el tiempo real del cambio más reciente.
4548564	Resumen: las firmas y los campos de formularios pueden aparecer invisibles en el PDF firmado cuando se colocan sobre anotaciones de sello preexistentes en el documento de origen. En las plantillas afectadas, las anotaciones de sello se superponen u ocultan los campos interactivos durante el procesamiento, haciendo que las firmas completadas y otros campos queden ocultos en el documento firmado final.
4548564	Solución: se ha actualizado la gestión de las anotaciones de sello para procesar y acoplar de manera segura las anotaciones de sello preexistentes para que ya no oculten los campos de formularios ni las firmas. Los campos colocados sobre áreas selladas ahora permanecen visibles durante toda la firma y en el PDF ejecutado por completo.
4549103	Resumen: Un evento de rechazo de correo electrónico puede registrarse nuevamente para un destinatario previamente incorrecto después de que el remitente reemplace a ese destinatario con una dirección de correo electrónico válida. En algunos casos, la pista de auditoría puede mostrar un segundo evento de rebote para el correo electrónico anterior, y el estado del acuerdo puede reflejar “correo electrónico rebotado” aunque el nuevo destinatario reciba, vea o firme el acuerdo correctamente. Este comportamiento puede hacer que parezca que el acuerdo aún está dirigido tanto a las direcciones de correo electrónico antiguas como a las nuevas.
4549103	Solución: se ha actualizado el flujo de trabajo de reemplazar firmante para prevenir el envío de correos electrónicos de notificación adicionales a un destinatario reemplazado cuyo correo electrónico ya ha rebotado. El sistema ahora verifica el historial de rechazo previo antes de enviar notificaciones relacionadas con el reemplazo, asegurando que no se generen nuevos eventos de rechazo para la dirección de correo electrónico anterior después del reemplazo.
4549306	Resumen: los usuarios cuyas direcciones de correo electrónico contienen ciertos caracteres especiales (por ejemplo, un apóstrofe) pueden no poder iniciar sesión desde las páginas de inicio de sesión públicas genéricas adobesign.com o echosign.com. Después de introducir la dirección de correo electrónico y hacer clic en el campo de contraseña, la página puede recargarse y borrar el campo de correo electrónico en lugar de redirigir al usuario a la partición correcta o a la página de inicio de sesión SSO. Esto impide que los usuarios afectados completen la autenticación y bloquea las integraciones que dependen del punto final de inicio de sesión público.
4549306	Solución: se ha corregido la lógica de resolución de recursos compartidos de inicio de sesión para gestionar y decodificar correctamente las direcciones de correo electrónico que contienen caracteres especiales antes de construir la URL de redireccionamiento entre recursos compartidos. Los usuarios con formatos de correo electrónico afectados ahora son redirigidos correctamente a su partición designada y página de inicio de sesión SSO sin que se borre el campo de correo electrónico.
4549331	Resumen: las firmas y otros campos de formulario pueden aparecer como ausentes o invisibles en el PDF firmado cuando ciertas funciones de procesamiento del documento están habilitadas y el PDF de origen contiene coordenadas de recuadro de página no válidas (por ejemplo, valores incorrectos de CropBox o MediaBox). En este escenario, los campos que dependen de las coordenadas de página pueden procesarse fuera del área de página visible, haciendo que las firmas completadas parezcan ausentes aunque la firma se complete correctamente.
4549331	Solución: se ha corregido la gestión de los recuadros de página del PDF para normalizar de forma segura los valores no válidos de CropBox y MediaBox durante el procesamiento del documento. Como resultado, la ubicación de firmas y campos de formulario ahora se alinea con el área de página visible, y los PDFs firmados muestran las firmas como se esperaba.
4550367	Resumen: la creación de un formulario web puede fallar con un “error del servidor” genérico después de seleccionar Previsualización y Añadir campos cuando la autenticación del firmante predeterminada del grupo del remitente está configurada en Teléfono y la cuenta no tiene cuota de autenticación telefónica disponible, incluso si la autenticación del firmante del formulario web está configurada en un método que no sea teléfono (por ejemplo, Adobe Sign). Como resultado, todos los usuarios en la cuenta afectada pueden estar bloqueados para crear formularios web en todos los documentos.
4550367	Solución: la creación de formularios web ahora evalúa la cuota solo para el método de autenticación realmente configurado para el firmante del formulario web, y ya no aplica verificaciones de cuota de autenticación telefónica basadas únicamente en la configuración de autenticación predeterminada del grupo. Esto previene errores falsos de agotamiento de cuota y permite que los formularios web se creen con normalidad.
4551011	Resumen: cuando un remitente carga ciertos PDF escaneados, añade campos de firma y envía el acuerdo, el PDF firmado puede que no muestre firmas visibles después de completarse la firma. Este comportamiento puede ocurrir cuando el PDF cargado contiene metadatos de límite de página no válidos (las coordenadas de MediaBox y CropBox aparecen invertidas), lo que puede causar que las capas de apariencia de firma y otros campos se procesen fuera del área de página visible.
4551011	Solución: se ha actualizado la gestión de límites de página del PDF para procesar correctamente los PDF con valores de coordenadas no válidas o invertidas de MediaBox y CropBox, de modo que el contenido de las capas de apariencia de firma y campos de formulario se procese dentro del área de página visible y permanezca visible en el PDF firmado final.
4551427	Resumen: algunos destinatarios que ya tienen cuentas activas y correctamente aprovisionadas reciben acuerdos como destinatarios “pseudousuario” en su lugar, por lo que el acuerdo no aparece en su vista normal Administrar. Esto sucede cuando las direcciones de correo electrónico de los destinatarios incluyen espacios al principio o al final, lo que impide que el sistema pueda establecer la coincidencia del correo electrónico con el usuario existente, haciendo que se cree un registro de pseudousuario.
4551427	Solución: se han actualizado el análisis de correo electrónico y la búsqueda de usuarios para normalizar las direcciones de correo electrónico de los destinatarios (eliminar espacios en blanco al principio y al final) antes de buscar su coincidencia con usuarios existentes. Como resultado, los acuerdos dirigidos a usuarios existentes se resuelven a la cuenta registrada en lugar de crear un destinatario pseudousuario, incluso si el correo electrónico se introdujo con espacios (en cargas útiles de API y listas de destinatarios de flujo de trabajo).
4553198	Resumen: cuando un acuerdo incluye al menos un destinatario configurado para envío de SMS y al menos un destinatario configurado para solo entrega de correo electrónico, al cancelar el acuerdo a través de la API no se envía una notificación de cancelación de SMS al destinatario del SMS. El acuerdo se cancela correctamente y se entregan las notificaciones por correo electrónico, pero los destinatarios de SMS no reciben un mensaje de cancelación.
4553198	Solución: se ha corregido el flujo de trabajo de cancelación para asegurar que las notificaciones de cancelación de SMS se envíen a todos los destinatarios configurados para envío de SMS cuando se cancela un acuerdo, independientemente de los métodos de envío de otros destinatarios.
4554463	Resumen: cuando los acuerdos incluyen botones de opción clonados que comparten el mismo nombre de campo en documentos combinados, solo una instancia de la opción seleccionada permanece seleccionada en el PDF firmado final. Aunque los campos aparecen visualmente como casillas de verificación, están implementados como botones de opción. Después de firmar, el valor seleccionado no se propaga de forma consistente en todas las instancias clonadas, lo que provoca una asignación incorrecta o incompleta de la selección esperada.
4554463	Solución: se ha corregido la lógica de gestión de los campos de formulario para que los botones de opción clonados almacenen y propaguen el valor de exportación seleccionado en lugar de un valor de índice interno. Esto garantiza que todas las instancias clonadas del mismo campo de botón de opción reflejen la selección correcta en el PDF firmado.
4554593	Resumen: algunas integraciones de socios que utilizan los puntos finales OAuth heredados para actualizar tokens de acceso comenzaron a fallar con errores HTTP 401. El servicio rechazó las solicitudes de actualización de token con un error que indica que la aplicación no tiene permitido usar los puntos finales OAuth heredados y debe usar los puntos finales OAuth v2 en su lugar. Esto impidió que los clientes autenticaran Acrobat Sign a través de aplicaciones de partner, incluso para integraciones que funcionaban anteriormente.
4554593	Solución: se ha corregido el servicio de autenticación para que las aplicaciones de socios configuradas para usar el flujo OAuth heredado puedan volver a actualizar correctamente los tokens, en lugar de ser forzadas incorrectamente a los puntos finales OAuth v2.
4554614	Resumen: cuando un firmante utiliza la experiencia de firma electrónica moderna en un acuerdo que requiere autenticación del firmante y está configurado para requerir la aceptación de las Condiciones de uso antes de firmar, al hacer clic en Clic para firmar activa un redireccionamiento de 5 segundos a la experiencia de firma clásica. El mensaje de redireccionamiento advierte de que las firmas y las iniciales introducidas en la firma moderna se borrarán, obligando al firmante a tener que volver a introducirlas y firmar dos veces.
4554614	Solución: se ha corregido el flujo de actualización de los tokens de firma para que cuando el firmante acepte las Condiciones de uso antes de firmar, el token de firma reemitido conserve los detalles de autenticación del firmante. Esto evita que el paso final de firma falle en la autenticación y elimina la reversión forzada de la firma moderna a la experiencia clásica.
4555656	Resumen: en determinadas condiciones de tiempo, la transición del estado de un acuerdo puede parecer como realizada correctamente aunque en realidad no ha cambiado el estado del acuerdo. Cuando se recibe una notificación webhook antes de que se complete el procesamiento del backend, las llamadas API posteriores pueden usar datos de estado de acuerdo obsoletos. En esta ventana, ciertos métodos de transición de estado devuelven HTTP 200 OK aunque el acuerdo no esté en un estado válido para la transición solicitada. Como resultado, los flujos de trabajo de automatización pueden asumir que la transición se ha realizado correctamente mientras el acuerdo permanece en su estado original.
4555656	Solución: se ha actualizado la lógica de transición del estado de un acuerdo para aplicar una validación estricta antes de aplicar una transición. Si el acuerdo no se encuentra en un estado válido, la API ahora devuelve una respuesta de error clara en lugar de indicar el éxito de manera silenciosa. Esto garantiza que las transiciones no válidas se rechacen explícitamente, permite que los sistemas de llamada reintenten apropiadamente y evita que los acuerdos permanezcan en un estado no deseado sin visibilidad.