Primer informe: agosto de 2024
Última actualización el
9 feb. 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 webhook de Acrobat Sign para recibir notificaciones proactivas sobre cortes, interrupciones y eventos de mantenimiento a través del portal de estado de Adobe.
Puedes administrar y añadir suscripciones aquí: Ayuda para la suscripción de estado de Adobe.
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 que cambien a webhooks para obtener actualizaciones en tiempo real.
Qué está cambiando
Esta directiva de sondeo se aplica a todos los puntos finales de GET API.
Ejemplos de puntos de conexión 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.
Listado:
- 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 a la API al servicio Acrobat Sign. Se devuelve un error si el mismo usuario efectivo realiza la misma llamada dentro del intervalo mínimo de sondeo.
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 bajo cuentas Global/Enterprise: Tres llamadas idénticas por intervalo de un minuto.
- Aplicaciones de cliente bajo 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 solicitudes get idénticas (misma ruta y encabezados) más de lo que permite su nivel dentro del MOPI, el sistema devolverá:
- Código de estado 304 No modificado para las solicitudes HTTP condicionales que utilizan un ETag.
- Código de estado 429 Demasiadas solicitudes con un "retry-after" para otras solicitudes.
- Gestión de ETag: Esta política se aplica cuando se proporcionan valores de ETag en el encabezado If-None-Match para los puntos de conexión que ya admiten 304 No modificado .
Acción necesaria
Webhooks: Si su aplicación requiere actualizaciones casi en tiempo real, utilice webhooks en lugar de sondeo. 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 las respuestas de la 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 pruebas habilitará la directiva de sondeo para REGISTRAR errores el 17 de septiembre de 2025 y se configurará para 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.
|
Primer informe: septiembre de 2024. Actualización: abril de 2025 |
Actual |
|---|
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.