Primer informe: agosto de 2024
Última actualización el
3 jun. 2026
Las notificaciones técnicas de Adobe Sign se ordenan a continuación con la actualización más antigua en la parte superior, y avanzando en el tiempo a medida que se desplaza hacia abajo por la página.
|
|
Quitado de la lista actual: enero de 2025 |
|---|
El encabezado Accept-Charset heredado se eliminará de todas las notificaciones de Webhook y devoluciones de llamada en la versión de noviembre de 2024.
Todos los clientes que dependan de este encabezado por cualquier motivo deben refactorizar su código para tener en cuenta su ausencia.
|
Primer informe: septiembre de 2024 |
Quitado de la lista actual: enero de 2025 |
|---|
|
Primer informe: noviembre de 2024 |
Quitado de la lista actual: enero de 2025 |
|---|
En la versión de noviembre de 2024, las etiquetas editables en el Diseñador de flujo de trabajo personalizado tienen un límite de 100 caracteres. Este límite se evalúa cuando se crea o actualiza el flujo de trabajo.
Los flujos de trabajo preexistentes que tienen etiquetas de más de 100 caracteres pueden seguir enviándose correctamente, pero si se actualiza el flujo de trabajo, la etiqueta deberá reducirse a 100 caracteres o menos para que se pueda guardar. Las etiquetas infractoras se resaltan en rojo para facilitar su localización.
Los nuevos flujos de trabajo advertirán sobre el límite de las etiquetas antes de guardarlas.
Acción necesaria
Se recomienda que los administradores con control sobre los flujos de trabajo personalizados abran y revisen cada flujo de trabajo para asegurarse de que no tengan errores en su plantilla.
|
Primer informe: noviembre de 2024 |
Quitado de la lista actual: febrero de 2025 |
|---|
La nueva experiencia del destinatario contiene mejoras de firma tanto para exploradores web de escritorio como móviles. Esta nueva experiencia se está desplegando a lo largo de los primeros meses de 2025, pero estará disponible en el entorno de zona protegida en la primera semana de diciembre de 2024.
|
Primer informe: diciembre de 2024 |
Quitado de la lista actual: febrero de 2025 |
|---|
Adobe Acrobat Sign rotará el certificado SSL de Adobe Acrobat Sign el 22 de enero de 2025.
Además, se está implementando un nuevo certificado SSL para admitir los cambios de red WAF que se realizarán en enero de 2025. Este nuevo certificado afecta directamente al acceso al servicio de Acrobat Sign y debe instalarse antes de que WAF entre en funcionamiento.
Acción necesaria
- Cada cuenta de cliente que protege explícitamente la actividad de la red debe incluir el nuevo certificado SSL de WAF en su lista de certificados almacenados.
- Si tienes integraciones personalizadas de Acrobat Sign que utilizan las API de SOAP o REST y en caso de que cualquiera de estas integraciones tenga “fijada” la clave pública existente, no será necesaria ninguna otra acción.
- Si está utilizando los certificados SSL de acrobat sign para SSO, o si está fijando el certificado en sí (o utilizando otros métodos), puede encontrar los nuevos certificados SSL de acrobat sign en los Requisitos del sistema de Adobe acrobat sign.
- Si tu configuración de SSO admite varias cadenas o certificados públicos, puedes añadir los nuevos certificados ahora y quitar la antigua cadena o certificado público de tu configuración tras el cambio de enero.
- Si su SSO no admite varias certificaciones/cadenas públicas, deberá sincronizar su conmutador SSL con Acrobat Sign el 22 de enero de 2025.
Los nuevos certificados SSL estarán activos el 22 de enero de 2025.
|
Primera notificación: septiembre de 2024, actualizado en febrero de 2025 |
Eliminado de la lista actual: marzo de 2025 |
|---|
Para mejorar la seguridad y solidez del servicio de Adobe Acrobat Sign, implementaremos cambios en la red para incluir un cortafuegos de aplicaciones web (WAF) en la primera mitad de 2025 (fechas finales por determinar; Marca este aviso. Estos cambios redirigirán el tráfico a los servidores de aplicaciones de Acrobat Sign a través del servicio de WAF. Este enrutamiento será invisible para la mayoría de los clientes. El uso no interferirá con el acceso a Acrobat Sign de ningún cliente o de ninguna integración de Adobe.
Acción necesaria
Ninguna.
Este cambio no afectará a las integraciones de los clientes, puesto que la API de Acrobat Sign y los nombres de dominio de la API no sufrirán ninguna modificación. Esta solución es compatible con los rangos de IP publicados.
Los clientes que hayan actualizado sus dispositivos de seguridad no necesitan volver a introducir o realizar cualquier otro cambio.
El programa de actualización actual es el siguiente:
- La zona protegida de producción actualiza el 24 de febrero de 2025.
- Los fragmentos de producción: IN1, JP1, AU1 y SG1 se actualizarán el 3 de marzo de 2025.
- Los fragmentos de producción: NA2, NA3 y EU2 se actualizarán el 6 de marzo de 2025.
- Los fragmentos de producción: NA1, NA4 y EU1 se actualizarán el 11 de marzo de 2025.
Acceso de entrada y salida a Acrobat Sign
Acrobat Sign ya no está anulando la lista de direcciones IP entrantes del servidor como se ha anunciado anteriormente.
Tal y como se documenta en la página Requisitos del sistema para Acrobat Sign, las direcciones IP de entrada y salida del servidor seguirán siendo válidas.
¿Por qué Acrobat efectúa estos cambios?
El uso de un WAF mejora la protección de Acrobat Sign frente al tráfico dañino y nos ayuda a resolver mejor los problemas de seguridad, solidez y cumplimiento.
Tengo una integración personalizada en Acrobat Sign. ¿Se verá afectada mi aplicación?
No, no creemos que ninguna integración se verá afectada negativamente.
¿Hay nuevas listas de direcciones IP que se puedan sustituir?
No.
La información en la página Requisitos del sistema para acrobat sign sigue siendo precisa.
Mi organización ha implementado el filtrado de red mediante la lista de dominios publicada en Acrobat Sign para el tráfico desde nuestra red corporativa. ¿Estamos afectados?
No.
Los cambios de red descritos aquí no afectan la lista de dominios de acrobat sign, como se documenta en la página Requisitos del sistema para acrobat sign. El filtrado de nivel de dominio no se ve afectado.
Mi organización emplea la validación de direcciones IP para el envío de correos electrónicos desde servidores de Acrobat Sign. ¿Estamos afectados?
No.
Los rangos de IP para retransmisores de correo saliente, como se enumeran en la página Requisitos del sistema para acrobat sign, no están cambiando.
Mi organización ha configurado nuestra cuenta de Acrobat Sign para restringir el acceso a nuestras propias direcciones IP. ¿Estamos afectados?
No.
acrobat sign se puede configurar para validar el tráfico entrante contra direcciones IP elegidas por el cliente, como se describe en la página Restringir el acceso a su cuenta utilizando rangos de direcciones IP. Este cambio no afectará a este uso.
Mi organización ha implementado el filtrado de red mediante la lista publicada de direcciones IP de entrada de Acrobat Sign. ¿Estamos afectados?
No.
La nueva configuración de WAF es compatible con la architectura de red existente, por lo que no debe requerirse ningún ajuste adicional de los dispositivos de seguridad.
Nota
Ten en cuenta que esto se refiere a la filtración de nivel IP para el entorno que aloja tu aplicación. El filtrado de nivel de dominio no se ve afectado.
Estoy usando la integración de Salesforce con una lista de permitidos IP configurada explícitamente. ¿Debo hacer alguna cosa?
No.
La instalación del WAF no requiere ningún cambio en las instalaciones de Salesforce actuales por el momento.
Tal y como se describe en la documentación de ayuda, la configuración y el proceso actuales siguen siendo los mismos, y los administradores deben seguir todos los pasos de inclusión de IP en la lista de permitidos.
Los socios de ISV y Embed deben ponerse en contacto con su Success Manager para cualquier consulta adicional.
|
Primer informe: noviembre de 2024, Actualizado: enero de 2025 |
Eliminado de la lista actual: marzo de 2025 |
|---|
Los remitentes pueden proporcionar una vista adicional de acuerdos para los destinatarios de dispositivos móviles que solo muestra el campo del acuerdo disponible para el destinatario.
Los remitentes pueden organizar la lista de campos como deseen y los campos de grupo en secciones lógicas para ayudar a los firmantes a moverse por la entrada del campo con un mínimo de desplazamiento.
Los destinatarios tienen la opción de ver la lista de campos para dispositivos móviles o la vista del PDF original con los campos situados dentro del contenido del documento.
Esta función se ha programado para ser publicada:
- Se implementará en el entorno de zona protegida el 11 de diciembre de 2024
- Se implementará en el entorno de producción el miércoles, 4 de marzo de 2025
|
Primer informe: mayo de 2024 |
Eliminado de la lista actual: marzo de 2025 |
|---|
La opción de utilizar una unidad externa para cargar archivos se limitará a OneDrive solo en la nueva experiencia de Solicitar firma.
Se recomienda que los clientes que utilizan otras opciones para cargar archivos utilicen la aplicación específica del proveedor para proporcionar una unidad de red a la que se pueda acceder a través del selector de archivos nativo en el sistema local del usuario.
- Dropbox: https://www.dropbox.com/desktop
- Google Drive: https://support.google.com/drive/answer/10838124
- Box: https://support.box.com/hc/en-us/articles/360043697194-Installing-Box-Sync
- Acrobat/Document Cloud: https://www.adobe.com/acrobat/hub/share-sync-pdfs.html
|
Primer informe: mayo de 2024 |
Eliminado de la lista actual: abril de 2025 |
|---|
Acción necesaria
Todas las integraciones y aplicaciones que utilizan la API SOAP de Adobe Acrobat Sign deben migrarse a la última versión 6 de la API REST antes de la fecha de deshabilitación para garantizar el funcionamiento continuo.
A partir de marzo de 2025, se eliminará el acceso a la API SOAP para todos los socios incrustados.
Para garantizar la continuidad del servicio, todos los socios incrustados que utilicen la API SOAP de Adobe Acrobat Sign deben migrar a la API REST más reciente antes del 1 de marzo de 2025.
Revise la documentación de la versión 6 de REST y la migración:
- Métodos de la versión 6 de la API REST de Adobe Acrobat Sign
- Migración desde SOAP
Para cualquier consulta, póngase en contacto con el PSM de Adobe Acrobat Sign designado.
Nota
Esta actualización solo se aplica a la versión Comercial del servicio de Acrobat Sign. Las cuentas de Government Cloud no se ven afectadas.
Esta actualización solo se aplica a la página Enviar (Solicitar firmas electrónicas). Los flujos de trabajo de Firma automática estructurada aún no se incluyen.
|
Primer informe: marzo de 2024. Actualizado en enero de 2025 |
Eliminado de la lista actual: abril de 2025 |
|---|
A partir de la versión de abril de 2025, el entorno moderno de Solicitud de firma será la experiencia predeterminada que se utilizará para crear un nuevo acuerdo.
- Los usuarios ya no podrán cambiar entre los entornos nuevo y clásico, ya que los enlaces de cambio se desactivarán.
- Los administradores seguirán disponiendo de la opción para habilitar la experiencia clásica y restaurar los enlaces de cambio a través del menú de administrador.
- Los clientes que utilicen la integración de Validar no se verán afectados por este cambio.
|
Informado por primera vez: marzo de 2024 - Actualizado abril de 2025 |
Eliminado de la lista actual: abril de 2025 |
|---|
Nota
Esta actualización solo se aplica a la versión Comercial del servicio de Acrobat Sign. Las cuentas de Government Cloud no se ven afectadas.
A partir de la versión de abril de 2025, el entorno moderno Request Signature se convertirá en la experiencia predeterminada disponible al crear una nueva plantilla de Enviar en lote.
- Los usuarios no podrán volver al entorno clásico.
- Los administradores tendrán la opción de habilitar la experiencia clásica y restaurar los enlaces de cambio a través del menú de administración.
|
Primera notificación: febrero de 2025 |
Eliminado de la lista actual: abril de 2025 |
|---|
El nombre de la pestaña Cuenta, disponible para los administradores de nivel de cuenta de Acrobat Sign, cambiará a Administrador.
- Esta actualización se aplica exclusivamente al entorno independiente de Acrobat Sign (Acrobat Sign Solutions y Acrobat Sign para la administración pública).
- La actualización se implementará en el entorno comercial en abril de 2025 y en el entorno gubernamental en mayo de 2025.
Ten en cuenta que este cambio es puramente estético: no hay modificaciones funcionales, solo actualizaciones en las etiquetas de la pestaña.
Nota
La etiqueta Grupo para los administradores de nivel de grupo no cambiará.
|
Primer informe: marzo de 2025 |
Eliminado de la lista actual: abril de 2025 |
|---|
- Experiencia de inicio de sesión de usuario mejorada: Acrobat Sign ha simplificado el proceso de inicio de sesión y autenticación mediante el Sistema de administración de identidades de Adobe (IMS).
- El perfil organizativo del usuario se selecciona automáticamente durante el proceso de inicio de sesión para las personas con derecho al servicio de Acrobat Sign (identificando la solicitud como procedente de una fuente de Acrobat Sign).
- Los usuarios que encuentren errores durante el inicio de sesión tendrán enlaces en sus mensajes de error para ponerse en contacto con sus administradores de Acrobat Sign para obtener ayuda.
- Todos los usuarios que tengan asignado un derecho activo, pero que no hayan iniciado sesión en el servicio, recibirán hasta dos recordatorios por correo electrónico. (Esto también se aplica a los usuarios inactivos existentes antes de la fecha de lanzamiento)
Estas mejoras simplifican el inicio de sesión, reducen la fricción y mejoran la experiencia del usuario en general.
Entornos disponibles: comercial | Niveles de servicio disponibles: Acrobat Sign Solutions | Ámbito de configuración: habilitado de forma predeterminada; no configurable
|
Primer informe: marzo de 2025. Actualizado en abril de 2025 |
Eliminado de la lista actual: junio de 2025 |
|---|
A partir de mayo de 2025, Acrobat Sign aplicará límites más estrictos en cuanto al número de webhooks creados en cuentas de nivel de desarrollador.
Estos límites se han elegido a propósito para garantizar la fiabilidad de la infraestructura de webhooks y se han alineado mejor para los flujos de trabajo de prueba.
|
¿Qué es lo que cambia? |
Limite anterior |
Nuevo límite |
Descripción |
|---|---|---|---|
|
Número de webhooks activos creados por canal |
10 |
1 |
Se permite 1 webhook para el evento de suscripción por canal. |
|
Número de webhooks activos creados para una cuenta |
100 |
2 |
Se permiten 2 webhooks de nivel de cuenta por evento de suscripción. |
|
Número de webhooks activos creados por grupo |
100 |
2 |
Se permiten 2 webhooks a nivel de grupo por grupo y por evento de suscripción. |
|
Número de webhooks activos creados por recurso de acuerdo |
50 |
1 |
Se permite 1 webhook por acuerdo y por evento de suscripción. |
|
Número de webhooks activos creados por usuario |
100 |
1 |
Se permite 1 webhook por usuario por evento de suscripción. |
Niveles disponibles: comercial | Niveles de servicio disponibles: Desarrollador | Ámbito de configuración: habilitado de forma predeterminada; no configurable
|
Primer informe: marzo de 2025 |
Eliminado de la lista actual: abril de 2025 |
|---|
Los clientes de Acrobat Sign ahora pueden suscribirse al servicio de webhook de Acrobat Sign para recibir notificaciones proactivas sobre interrupciones, alteraciones y eventos de mantenimiento a través de Adobe Status.
Administra y añade suscripciones aquí: Ayuda de suscripción de Adobe Status.
Tenga en cuenta que el servicio Adobe Acrobat Sign se enumera en el encabezado Document Cloud:
|
Informado por primera vez: marzo de 2025 |
Eliminado de la lista actual: junio de 2025 |
|---|
En la versión de mayo de 2025, estamos optimizando la API GET /acuerdos para reducir significativamente los tiempos de respuesta: nuestra prueba interna muestra mejoras de hasta 10 veces.
Cambios
- Tamaños de página más pequeños: para favorecer estas mejoras, hemos reducido el número máximo de acuerdos devueltos por solicitud a 500, pero este límite puede cambiar en futuras versiones. Cada respuesta incluye lo siguiente:
- El número real de acuerdos devueltos
- Un vínculo a la siguiente página de resultados (si está disponible)
- Recuento de resultados dinámicos: aún puede solicitar un número específico de acuerdos, pero la API devuelve tantos acuerdos como sea posible. Cada respuesta incluye lo siguiente:
Previsiones
En algunos casos, puede haber un retraso leve entre la creación de un acuerdo y su recuperación mediante la API GET /agreements. Este retraso es normalmente muy corto; una solicitud de seguimiento debe devolver el nuevo acuerdo.
Entornos disponibles: comercial, administración pública | Niveles de servicio disponibles: Acrobat Sign Services, administración pública | Ámbito de configuración: habilitado, no configurable
|
Informado por primera vez: abril de 2025 |
Eliminado de la lista actual: agosto de 2025 |
|---|
Todas las cuentas que utilicen el servicio Acrobat Sign for Government obtendrán acceso para habilitar el nuevo entorno Request Signature, junto con varias funciones creadas recientemente que dependen de él:
- eWitnessing
- Acceso restringido a los acuerdos
- Aplicar tipo de firma
- Comprobación de identidad
- CC por destinatario
- La lista de destinatarios y las propiedades de los destinatarios se pueden editar después de la creación
|
Primer informe: septiembre de 2024 |
Eliminado de la lista actual: febrero de 2026 |
|---|
Acción necesaria
Todos los clientes que utilicen la API deben actualizar sus API para utilizar los puntos finales de la versión 6 lo antes posible para garantizar la disponibilidad ininterrumpida.
Las versiones 1 a 4 de la API REST de Acrobat Sign han quedado en desuso y se eliminarán del servicio el 1 de diciembre de 2025.
La actualización de las API puede requerir un esfuerzo considerable, por lo que se recomienda encarecidamente a todos los clientes que apliquen y presupuesten su actualización lo antes posible para que el servicio de asistencia pueda participar plenamente en la solución de cualquier pregunta o problema que surja antes de la fecha límite en diciembre de 2025.
Si bien las versiones de API REST v1-4 quedan en desuso, seguirán funcionando y tus aplicaciones seguirán funcionando hasta el 1 de diciembre de 2025, fecha en la que se eliminarán las API REST v1-4.
Después del 1 de diciembre de 2025, las aplicaciones creadas basadas en las versiones 1 a 4 de API REST dejarán de funcionar.
|
Primer informe: abril de 2025 |
Eliminado de la lista actual: febrero de 2026 |
|---|
Todas las cuentas que utilicen el servicio Acrobat Sign for Government obtendrán acceso para habilitar el nuevo entorno Request Signature, junto con varias funciones creadas recientemente que dependen de él:
- eWitnessing
- Acceso restringido a los acuerdos
- Aplicar tipo de firma
- Comprobación de identidad
- CC por destinatario
- La lista de destinatarios y las propiedades de los destinatarios se pueden editar después de la creación
|
Primer informe: septiembre de 2024. Actualización: abril de 2025 |
Eliminado de la lista actual: febrero de 2026 |
|---|
La infraestructura de Webhook 2.0 se ha implementado en todos los clientes y, una vez completada, las notificaciones de firmantes han quedado en desuso. Esto significa que el parámetro webhookNotificationApplicableUsers de la carga útil de Webhook ya no proporciona datos útiles, por lo que se eliminará de todas las cargas útiles de Webhook.
El entorno de zona protegida se actualizará en la versión de junio.
Los entornos de producción se actualizarán en la versión de julio de 2025.
El ID de usuario y el correo electrónico del remitente se pueden encontrar mediante los parámetros initiatingUserId e initiatingUserEmail en la carga de notificación.
|
Primera notificación: agosto de 2025 - Actualizado octubre de 2025 |
Eliminado de la lista actual: febrero de 2026 |
|---|
Para ayudar a mantener la estabilidad del sistema y mejorar el rendimiento, Acrobat Sign introducirá un umbral de sondeo en la versión del 4 de noviembre de 2025 (versión 16.2.1). Este cambio limita la frecuencia con la que las aplicaciones cliente pueden sondear puntos de conexión de API específicos.
- Los clientes tienen dos meses después del lanzamiento de la versión 16.2.1 para implementar los cambios de sondeo recomendados en su código. Durante esta ventana de tiempo, el sistema solo REGISTRARÁ los eventos de umbral de intervalo de sondeo.
- Después de diciembre de 2025, las directivas de protección de sondeo se cambiarán a APLICAR, y los errores comenzarán a activarse para los usuarios.
El sondeo de alta frecuencia crea una carga innecesaria en los sistemas backend, lo que resulta en un rendimiento degradado y tiempos de respuesta más lentos. Se recomienda a los desarrolladores de API cambiar a webhooks para actualizaciones en tiempo real.
Cambios
Esta política de encuesta se aplica a todos los puntos finales de GET API.
Ejemplos de puntos finales afectados
Recuperación de estado:
- GET/agreements/{agreementId): recupera el estado actual de un acuerdo.
- GET/agreements/{agreementId)/documents/{documentId): recupera el flujo de archivos de un documento dentro de un acuerdo.
Enumeración:
- GET/agreements: recupera acuerdos para el usuario.
- GET/agreements/{agreementId)/events: recupera información de eventos para un acuerdo.
Se aplicará un límite a la frecuencia con la que el usuario efectivo puede realizar la misma llamada API al servicio Acrobat Sign. Se devuelve un error si el mismo usuario efectivo realiza la misma llamada dentro del intervalo mínimo de encuesta.
Detalles de la política de sondeo
- Intervalo mínimo de sondeo de objetos (MOPI): El MOPI predeterminado varía según el nivel de servicio y los tipos de aplicación:
- Aplicaciones partner de Acrobat Sign: El MOPI para una aplicación partner está determinado por el nivel de la Cuenta del Usuario.
- Nivel GLOBAL/ENTERPRISE: 3 llamadas por intervalo de un minuto
- Todos los demás niveles: 1 llamada única por intervalo de diez minutos
- Aplicaciones de cliente con cuentas globales o de empresa: tres llamadas idénticas por intervalo de un minuto.
- Aplicaciones de cliente con cuentas de desarrollador: una llamada única por intervalo de 10 minutos.
- Aplicaciones partner de Acrobat Sign: El MOPI para una aplicación partner está determinado por el nivel de la Cuenta del Usuario.
- Solicitudes duplicadas dentro de MOPI: si el mismo usuario efectivo realiza más solicitudes GET idénticas (misma ruta y encabezados) de lo que permite su nivel dentro del MOPI, el sistema devolverá:
- 304 Not Modified código de estado para solicitudes HTTP condicionales usando un ETag.
- Código de estado 429 Hay demasiadas solicitudes con “reintentar después de” para otras solicitudes.
- Manejo de ETag: Esta directiva se aplica cuando se proporcionan valores ETag en la cabecera If-None-Match para puntos finales que ya admiten 304 Not Modified.
Acción necesaria
Webhooks: Si tu aplicación requiere actualizaciones casi en tiempo real, usa webhooks en lugar de encuestas. Los webhooks proporcionan una forma más eficiente y escalable de recibir actualizaciones oportunas.
Si no se pueden implementar webhooks, las aplicaciones deben implementar mecanismos de almacenamiento en caché del lado del cliente para almacenar y reutilizar respuestas de API. Cuando se recibe una respuesta 304 No modificado, se deben utilizar los datos almacenados en caché en lugar de realizar otra llamada a la API.
Los clientes tienen dos meses después del lanzamiento de la versión 16.2.1 para implementar los cambios de sondeo recomendados en su código. Durante este período, el sistema REGISTRARÁ los eventos de umbral de intervalo de sondeo.
Después de diciembre de 2025, las directivas de protección de sondeo se cambiarán a APLICAR y los errores comenzarán a activarse para los usuarios.
Póngase en contacto con su CSM si necesita ayuda o tiene alguna pregunta.
El entorno de zona protegida habilitará la directiva de sondeo para REGISTRAR errores el 17 de septiembre de 2025, y se establecerá en APLICAR el 25 de septiembre de 2025.
|
Primer informe: agosto de 2025 |
Eliminado de la lista actual: febrero de 2026 |
|---|
Para cumplir con los requisitos de FedRAMP CSP, estamos habilitando el protocolo IPv6 en nuestro entorno Acrobat Sign for Government :
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Reportado por primera vez: Septiembre de 2025 |
Eliminado de la lista actual: febrero de 2026 |
|---|
Se ha reforzado la validación de la configuración de idioma al crear un acuerdo a través de la API. Si la configuración regional de un acuerdo no está permitida por las políticas de la Cuenta, la API rechaza la solicitud con un error claro. Esto reduce los desajustes de idioma no intencionados y mantiene las experiencias de los destinatarios alineadas con la Configuración aprobada.
Quién se ve afectado
- Cuentas que establecen la configuración regional del acuerdo en las solicitudes de API.
- Cuentas que restringen las configuraciones regionales disponibles o no permiten cambios de configuración regional durante el envío.
¿Qué ha cambiado?
Cuando la configuración DISPLAY_LOCALE_INFO_DURING_SEND está habilitada (nivel GLOBAL), la API aplica:
- La configuración regional del acuerdo debe estar incluida en AVAILABLE_LOCALES del Usuario.
- Si ALLOW_LOCALE_SELECTION_DURING_SEND es falso, la configuración regional del acuerdo debe coincidir con AGREEMENT_LOCALE del Usuario.
Las violaciones hacen que POST /agreements falle con: "La configuración regional no es válida o falta."
Error común y cómo solucionarlo
Error: "La configuración regional no es válida o falta."
- Verifica la configuración regional utilizada en la solicitud de API (por ejemplo, en_US).
- Confirma que la configuración regional aparece en AVAILABLE_LOCALES para el Usuario que realiza la llamada.
- Si ALLOW_LOCALE_SELECTION_DURING_SEND es falso, asegúrate de que la configuración regional de la solicitud coincida con AGREEMENT_LOCALE.
- Si se requiere flexibilidad entre regiones, habilita la selección de configuración regional al momento del envío (consulta Acción requerida).
Compatibilidad con versiones anteriores
- Antes de este cambio, algunas solicitudes con configuraciones regionales no coincidentes podían tener éxito. Ahora, estas solicitudes fallan con un error claro cuando las validaciones no pasan.
- No hay cambios en el esquema de la API; el comportamiento de validación cambia solo cuando DISPLAY_LOCALE_INFO_DURING_SEND está habilitado.
Acción obligatoria
Los administradores e integradores de API deben hacer una de las siguientes acciones:
- Alinear la configuración regional en las solicitudes de API con AVAILABLE_LOCALES y, si ALLOW_LOCALE_SELECTION_DURING_SEND es falso, hacer coincidir exactamente con AGREEMENT_LOCALE
- o -
- Permitir la selección de la configuración regional al enviar estableciendo:
- ALLOW_LOCALE_SELECTION_DURING_SEND = verdadero
- CAN_CHANGE_UI_LOCALE = verdadero
|
Informado por primera vez: diciembre de 2025 |
Eliminado de la lista actual: febrero de 2026 |
|---|
Adobe Acrobat Sign rotará el certificado SSL de Adobe Acrobat Sign el 7 de enero de 2026.
Acción necesaria
- Si tiene integraciones personalizadas con Acrobat Sign que usan las API REST y si alguna de estas integraciones ha "fijado" la clave pública existente, no se requiere ninguna otra acción.
- Si está utilizando los certificados SSL de Acrobat Sign para SSO, o si está fijando el certificado en sí (o utilizando otros métodos), puede encontrar los nuevos certificados SSL de Acrobat Sign en los requisitos del sistema de Adobe Acrobat Sign.
- Si tu configuración de SSO admite varias cadenas o certificados públicos, puedes añadir los nuevos certificados ahora y quitar la antigua cadena o certificado público de tu configuración tras el cambio de enero.
- Si su SSO no admite varios certificados/cadenas públicos, deberá sincronizar su cambio SSL con Acrobat Sign el 7 de enero de 2026.
Los nuevos certificados SSL estarán principales el 7 de enero de 2026.
|
Primera notificación: marzo de 2026 |
Actual Eliminado de la lista actual: junio de 2026 |
|---|
Hay programada una actividad de mantenimiento planificado de la base de datos para el 11 de abril de 2026, a las 7:30 p. m., hora del Pacífico. Se espera que la ventana de mantenimiento dure hasta 30 minutos.
Este mantenimiento afectará a todos los entornos de Acrobat Sign y se aplica únicamente a las cuentas administradas por Adobe (IMS). Las cuentas que administran a sus usuarios directamente en Acrobat Sign no se verán afectadas.
Durante este tiempo:
- La creación de nuevas cuentas y el aprovisionamiento de usuarios se retrasarán.
- Un número limitado de usuarios puede experimentar problemas de inicio de sesión.
- Las solicitudes de consumo de transacciones de cuenta desde las interfaces administrativas de Adobe pueden fallar, lo que puede impedir temporalmente la asignación de derechos.
Se espera que todos los servicios afectados vuelvan a funcionar con normalidad cuando se complete el mantenimiento.
|
Primera notificación: marzo de 2026 |
Eliminado de la lista actual: junio de 2026 |
|---|
Los ID de documento devueltos por la API ahora usan un formato de codificación de 16 bits en lugar del formato de codificación de 12 bits anterior y pueden incluir caracteres de asterisco finales como parte del valor devuelto. Acrobat Sign acepta ID de documento con o sin estos caracteres finales, pero algunas aplicaciones pueden no manejar correctamente el formato expandido, lo que puede afectar la recuperación o la visualización de los documentos.
Esta actualización refleja un cambio en el manejo del ID de documento en el servicio. Si su integración recupera documentos usando ID de documento devueltos por la API, revise su lógica actual para asegurarse de que admita el formato de ID más largo y pueda aceptar el valor devuelto tal como se proporciona. Si es necesario, los caracteres de asterisco finales se pueden omitir antes de volver a intentar la solicitud.
No se espera que el acceso directo a través de Acrobat Sign se vea afectado.
|
Primera notificación: febrero de 2026. Actualización: abril de 2026 |
Eliminado de la lista actual: junio de 2026 |
|---|
La página Inicio de Acrobat Sign se está rediseñando para facilitar el inicio de acuerdos, monitorizar la actividad y acceder a características clave, incluyendo la capacidad de copiar acuerdos enviados recientemente, ver mosaicos de acción en un orden más intuitivo, identificar rápidamente los elementos En curso y Pendiente, y experimentar un banner Novedades optimizado que reduce el desorden visual, ayudando a los usuarios a moverse más rápido, reducir la pérdida de acuerdos y navegar por una experiencia de Inicio más centrada.
La nueva página Inicio se lanzará durante los 10 días posteriores a la versión:
Fecha |
Fragmentos |
5 de mayo de 2026 |
IN1, JP1, AU1, SG1 |
11 de mayo de 2026 |
EU1, EU2, NA4 |
14 de mayo de 2026 |
NA1, NA2, NA3 |
Nota
La programación de despliegue se proporciona como guía y puede ajustarse a medida que avance el despliegue.
|
Primera notificación: marzo de 2026 |
Eliminado de la lista actual: junio de 2026 |
|---|
A partir de la versión 17.0.1 de 17 de marzo, la pestaña Tokens de acceso en el menú Preferencias personales muestra la fecha de caducidad de cada clave de integración. Esta actualización mejora la visibilidad en la administración del ciclo de vida de las claves al permitir que los titulares de las claves vean cuándo caducará una clave.
Las claves de integración tienen un período de validez de 10 años. Después de la fecha de vencimiento, la clave ya no se puede usar y debe reemplazarse con una nueva clave.
Este cambio no afecta al funcionamiento de las claves existentes ni modifica el ciclo de vida de las claves. Solo expone la fecha de vencimiento en la interfaz para que los administradores puedan monitorizar la antigüedad de las claves y planificar los reemplazos con antelación.
No se requiere ninguna acción. Los administradores deben revisar periódicamente sus claves de integración y reemplazar las que se acerquen al vencimiento para evitar interrupciones del servicio.
|
Primera notificación: marzo de 2026 |
Eliminado de la lista actual: junio de 2026 |
|---|
A partir de la versión del 5 de mayo de 2026, los Informes de auditoría registrarán el método de firma utilizado cuando un firmante aplique su firma.
Para cada evento ESIGNED y DIGSIGNED, la pista de auditoría identifica si el firmante utilizó un método de firma basado en escritorio (TYPE, DRAW, IMAGE) o un método de firma basado en dispositivo móvil (MOBILE_TYPE, MOBILE_DRAW, MOBILE_IMAGE).
Esta actualización mejora la visibilidad del cumplimiento al permitir que los administradores y equipos de cumplimiento verifiquen el método de firma directamente en el informe de auditoría, reduciendo la ambigüedad y minimizando los rechazos innecesarios de acuerdos durante los procesos de revisión y auditoría. Esta actualización está habilitada de forma predeterminada para todos los clientes, sin opción de configuración.
Nota
La aplicación de una firma solo con un sello no se incluye en los tipos de firmas identificadas.
|
Primera notificación: diciembre de 2025. Actualización: febrero de 2026 |
Eliminado de la lista actual: junio de 2026 |
|---|
La experiencia de la página de inicio de sesión de Acrobat Sign se actualizará para todos los usuarios como parte de la versión 17.0, programada para el 3 de febrero de 2026. - El nuevo proceso de inicio de sesión ofrece una experiencia más limpia y coherente al solicitar a todos los usuarios que proporcionen su correo electrónico y nada más. Tan pronto como se acepta la dirección de correo electrónico, se hace referencia a la cuenta del usuario y la página de seguimiento muestra las opciones de autenticación que la cuenta está configurada para usar, eliminando pasos innecesarios y pantallas heredadas. Esto hace que iniciar la sesión sea más rápido, más sencillo y más intuitivo para todos.
- Como parte de la nueva experiencia de inicio de sesión, el formato del correo electrónico para los usuarios de Acrobat Sign para empresas que inician sesión directamente en la interfaz web ahora aplica un límite de 64 caracteres a la parte local de una dirección de correo electrónico (la parte anterior al símbolo “@”).
Esta experiencia de inicio de sesión actualizada se está desplegando en fases por el entorno de servidor de Acrobat Sign. La programación del despliegue se muestra a continuación:
|
Entorno de Acrobat Sign |
Fecha de despliegue gradual |
|
IN1 (India) SG1 (Singapur) |
03 de febrero de 2026 |
|
AU1 (Australia) NA3 (Norteamérica) |
10 de febrero de 2026 |
|
JP1 (Japón) |
17 de febrero de 2026 |
|
EU2 (Europa) NA4 (Norteamérica) |
02 de marzo de 2026 |
|
EU1 (Europa) NA2 (Norteamérica) |
05 de marzo de 2026 |
|
NA1 (Norteamérica) |
10 de marzo de 2026 |
Nota
La programación de despliegue se proporciona como guía y puede ajustarse a medida que avance el despliegue.
|
Primera notificación: febrero de 2026 |
Eliminado de la lista actual: junio de 2026 |
|---|
