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.

Lanzamiento de Adobe Acrobat Sign v17.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 desde los filtros En curso y Esperando por usted en la Página de administración, 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 puntos del ciclo de vida de envío, reduciendo la necesidad de reiniciar desde cero.
Nota: Con esta versión, los controles administrativos para desactivar 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: Sandbox, Commercial, Government | Niveles de servicio disponibles: acrobat sign Solutions | Ámbito de configuración: Cuenta y Grupo; Habilitado por defecto.

Revisar la documentación actualizada de acciones del Usuario >

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 del remitente y destinatario en experiencias integradas, y entrega correcta de correo electrónico.
\n Para flujos de trabajo integrados OEM 2.0, Acrobat Sign ahora muestra el correo electrónico personalizado de un Usuario en lugar del correo electrónico registrado del partner en superficies clave de la interfaz de uso y notificaciones. Los acuerdos, colas como "Esperando por usted" y correos electrónicos de "Revisar y firmar" reflejan consistentemente la identidad personalizada mientras preservan internamente el correo electrónico registrado 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 no entregables.
\n
\nEntornos disponibles: Sandbox, Commercial | Niveles de servicio disponibles: Acrobat Sign Solutions | Ámbito de configuración: API
\n
\n

Notificación webhook para fallos de entrega SMS – Visibilidad en tiempo real de envíos SMS fallidos, remediación automatizada y paridad con rebotes de correo electrónico.
\n Acrobat Sign ahora emite un nuevo evento webhook, AGREEMENT_PHONE_BOUNCED, cuando un acuerdo enviado vía SMS no puede entregarse 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 de entrega de SMS en 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 ciegos y reduciendo retrasos en flujos de trabajo de firma móviles.

Entornos disponibles: Sandbox, Commercial, Government | Niveles de servicio disponibles: Acrobat Sign Solutions | Ámbito de configuración: API

Cargas útiles de webhook – Se añadió el campo condicional extendedStatus del participante para actualizaciones dinámicas de participación, 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: Sandbox, Commercial, Government | 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 exitosamente 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	Corrección: La lógica de atribución de eventos se corrigió para que los eventos de rebote de correo electrónico se asocien solo con el participante cuyo correo electrónico realmente rebota. Ya no se genera un evento de rebote 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 uso web pueden expirar después de 10 años, aunque la Página de creación indique que la clave proporciona "acceso permanente." Cuando una clave alcanza su acumulado de 10 años, las llamadas de API comienzan a devolver un error de token expirado, lo que puede interrumpir las integraciones existentes inesperadamente.
4544548	Corrección: La mensajería de la interfaz de uso se actualizó para eliminar la redacción de "acceso permanente" y mostrar claramente la fecha de expiración para las claves de integración. El texto actualizado ahora indica que la clave mantiene el acceso hasta la fecha de expiración o hasta que se revoque manualmente, proporcionando transparencia sobre el acumulado predeterminado de 10 años.
4546301	Resumen: La entrega de eventos de webhook puede retrasarse hasta múltiples horas para acuerdos con documentos muy grandes, incluso cuando la creación del acuerdo se completa y los pasos de procesamiento temprano parecen finalizar en 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: El manejo de disponibilidad de documentos se corrigió para que los acuerdos grandes transicionen 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 múltiples horas causados por reintentos de recuperación de documentos contra documentos no disponibles.
4547823	Resumen: Un mensaje privado del destinatario puede no mostrarse para algunos firmantes cuando un acuerdo se crea en el estado de creación a través de la API y luego se edita desde la experiencia de administrar. En este escenario, la interfaz de uso puede mostrar el Valor del mensaje privado como "Ninguno" o en blanco aunque los datos del acuerdo incluyan el Valor correcto del mensaje privado. Este comportamiento aparece en escenarios de Cuenta compartida donde un Usuario cambia a la Cuenta de otro Usuario para editar el borrador, y puede afectar solo a destinatarios específicos mientras otros se muestran correctamente.
4547823	Corrección: Se añadió una verificación para recuperar el contexto de Compartir principal y devolver el mensaje privado para usuarios compartidos autorizados. Como resultado, el Valor del mensaje privado ahora se muestra correctamente al ver o enviar un borrador creado por API desde el flujo de creación.
4548274	Resumen: La fecha modificada para 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 añadidos o actualizados en la plantilla, pero la fecha de modificación permanece sin cambios en la interfaz de uso Administrar y en las vistas administrativas, lo que hace que parezca que la plantilla no se modificó recientemente. Esto ocurre porque la nueva experiencia actualiza los campos del formulario a través de una ruta que no actualiza también la marca de tiempo de modificación de la plantilla.
4548274	Solución: El comportamiento de actualización de la fecha de modificación se alineó entre la nueva experiencia de plantilla y las operaciones de API relacionadas. La ruta de código que guarda los cambios de campo de plantilla ahora también actualiza la fecha de modificación de la plantilla para que refleje el tiempo real del cambio más reciente.
4548564	Resumen: Las firmas y los campos de formulario pueden aparecer invisibles en el pdf firmado cuando se colocan sobre anotaciones de sello preexistentes en el documento fuente. En las plantillas afectadas, las anotaciones de sello se superponen u ocultan los campos interactivos durante el procesar, causando que las firmas completadas y otros campos estén oculta en el documento firmado final.
4548564	Solución: El manejo de anotaciones de sello se actualizó para procesar y aplanar de forma segura las anotaciones de sello preexistentes para que ya no oculten los campos de formulario o las firmas. Los campos colocados sobre áreas selladas ahora permanecen visibles durante la firma y en el pdf completamente ejecutado.
4549103	Resumen: Un evento de rebote de correo electrónico puede registrarse nuevamente para un destinatario previamente incorrecto después de que el remitente reemplace a ese destinatario con un correo electrónico válido. En algunos casos, el registro 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 exitosamente el acuerdo. Este comportamiento puede hacer que parezca que el acuerdo aún está dirigido tanto al correo electrónico anterior como al nuevo.
4549103	Solución: El flujo de trabajo de reemplazar firmante se actualizó para evitar enviar 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 rebotes previos antes de enviar notificaciones relacionadas con el reemplazo, asegurando que no se generen nuevos eventos de rebote para el correo electrónico anterior después del reemplazo.
4549306	Resumen: Los usuarios cuyos correos electrónicos 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 el correo electrónico y hacer clic en el campo de contraseña, la Página puede recargar y limpiar el campo de correo electrónico en lugar de redirigir al Usuario al fragmento correcto 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: La lógica de resolución de fragmentos de inicio de sesión se corrigió para manejar y decodificar adecuadamente los correos electrónicos que contienen caracteres especiales antes de construir la URL de redirigir entre fragmentos. Los usuarios con formatos de correo electrónico afectados ahora son redirigidos correctamente a su fragmento designado y página de inicio de sesión SSO sin que se limpie el campo de correo electrónico.
4549331	Resumen: Las firmas y otros campos de formulario pueden aparecer faltantes o invisibles en el pdf firmado cuando ciertas características de procesamiento de documento están habilitadas y el pdf fuente contiene coordenadas de caja de Página no válido (por ejemplo, valores incorrectos de CropBox o MediaBox). En este escenario, los campos que dependen de coordenadas de Página pueden procesamiento fuera del área de Página visible, haciendo que las firmas completadas parezcan faltantes aunque la firma se complete exitosamente.
4549331	Solución: El manejo de cajas de Página pdf se corrigió para normalizar de forma segura los valores no válido 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: Crear un formulario web puede fallar con un "error de Servidor" genérico después de seleccionar vista previa y Añadir campos cuando la autenticación de 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 evita errores falsos de agotamiento de cuota y permite que los formularios web se creen normalmente.
4551011	Resumen: Cuando un remitente carga ciertos PDF escaneados, añade campos de firma y envía el acuerdo, el PDF firmado puede no mostrar firmas visibles después de completarse la firma. Este comportamiento puede ocurrir cuando el PDF cargado contiene metadatos de límites de página no válidos (las coordenadas de MediaBox y CropBox aparecen invertidas), lo que puede hacer que las capas de apariencia de firma y otros campos se procesen fuera del área visible de la página.
4551011	Solución: El manejo de límites de página PDF se actualizó para procesar correctamente los PDF con valores de coordenadas MediaBox y CropBox no válidos o invertidos, de modo que el contenido de apariencia de firma y campos de formulario se procese dentro del área visible de la página y permanezca visible en el PDF firmado final.
4551427	Resumen: Algunos destinatarios que ya tienen cuentas principales correctamente aprovisionadas reciben acuerdos como destinatarios "pseudo usuario" en su lugar, por lo que el acuerdo no aparece en su vista normal de Administrar. Esto sucede cuando las direcciones de correo electrónico del destinatario incluyen espacios al principio o al final, lo que impide que el sistema haga coincidir el correo electrónico con el Usuario existente y causa que se cree un registro de pseudo-usuario.
4551427	Solución: El análisis de correo electrónico y la búsqueda de usuarios se actualizaron para normalizar las direcciones de correo electrónico del destinatario (eliminar espacios en blanco al principio y al final) antes de hacerlas coincidir con usuarios existentes. Como resultado, los acuerdos dirigidos a usuarios existentes se resuelven a la Cuenta registrada en lugar de crear un destinatario pseudo-usuario, incluso si el correo electrónico se ingresó 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 entrega SMS y al menos un destinatario configurado para entrega solo por correo electrónico, cancelar el acuerdo a través de la API no envía una notificación de cancelación SMS al destinatario SMS. El acuerdo se cancela exitosamente y se entregan las notificaciones por correo electrónico, pero los destinatarios SMS no reciben un mensaje de cancelación.
4553198	Solución: El flujo de trabajo de cancelación se corrigió para asegurar que las notificaciones de cancelación SMS se envíen a todos los destinatarios configurados para entrega SMS cuando se cancela un acuerdo, independientemente de los métodos de entrega 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, se implementan como botones de opción. Después de firmar, el Valor seleccionado no se propaga consistentemente a todas las instancias clonadas, causando asignación incorrecta o incompleta de la selección esperada.
4554463	Solución: La lógica de manejo de campos de formulario se corrigió 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 asegura 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 partner que usan 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 indicando que la aplicación no está permitida para usar los puntos finales OAuth heredados y debe usar los puntos finales OAuth v2 en su lugar. Esto bloqueó a los clientes de autenticar Acrobat Sign a través de aplicaciones partner, incluso para integraciones que funcionaban previamente.
4554593	Solución: El servicio de autenticación se corrigió para que las aplicaciones partner que están configuradas para usar el flujo OAuth heredado puedan actualizar tokens exitosamente de nuevo, en lugar de ser forzadas incorrectamente a los puntos finales OAuth v2.
4554614	Resumen: Cuando un firmante usa la experiencia de firma electrónica moderna en un acuerdo que requiere autenticación del firmante y está configurado para requerir aceptación de Condiciones de uso antes de firmar, hacer clic en Hacer clic para firmar activa una redirección de 5 segundos a la experiencia de firma clásica. El mensaje de redirección advierte que las firmas y rúbricas ingresadas en la firma moderna se borrarán, forzando al firmante a reingresarlas y efectivamente firmar dos veces.
4554614	Solución: El flujo de actualización de token de firma se corrigió para que cuando el firmante acepta las Condiciones de uso antes de firmar, el token de firma reemitido retenga los detalles de autenticación del firmante. Esto evita que el paso final de firma falle en la autenticación y elimina el retroceso forzado de la firma moderna a la experiencia clásica.
4555656	Resumen: Bajo condiciones específicas de tiempo, una transición de estado de acuerdo puede parecer exitosa pero en realidad no cambia el estado del acuerdo. Cuando se recibe una notificación de webhook antes de que se complete el procesamiento del backend, las llamadas posteriores a la API pueden usar datos de estado de acuerdo obsoletos. En esta ventana, ciertos métodos de transición de estado devuelven HTTP 200 OK igualado cuando el acuerdo no está en un estado no válido para la transición solicitada. Como resultado, los flujos de trabajo de automatización pueden asumir que la transición se realizó correctamente mientras el acuerdo permanece en el estado original.
4555656	Solución: Se actualizó la lógica de transición de estado del acuerdo para aplicar una validación estricta antes de aplicar una transición. Si el acuerdo no está en un estado no válido, la API ahora devuelve una respuesta de error clara en lugar de devolver silenciosamente el éxito. Esto garantiza que las transiciones no válidas se rechacen explícitamente, permite que los sistemas de llamada reintenten de manera apropiada y evita que los acuerdos permanezcan en un estado no deseado sin Visibilidad.