Relatado pela primeira vez em: agosto de 2024
Última atualização em
27/04/2026
As Notificações técnicas do Adobe Sign estão ordenadas abaixo com a atualização atual na parte superior e em ordem cronológica à medida que você rola a página para baixo.
|
|
Removido da lista atual: janeiro de 2025 |
|---|
O cabeçalho Accept-Charset legado será removido de todas as notificações de webhook e retorno de chamada com a versão de novembro de 2024.
Todos os clientes que dependem desse cabeçalho por qualquer motivo devem redefinir o código, levando em consideração sua ausência.
|
Relatado pela primeira vez em: setembro de 2024 |
Removido da lista atual: janeiro de 2025 |
|---|
|
Relatado pela primeira vez em: novembro de 2024 |
Removido da lista atual: janeiro de 2025 |
|---|
Com a versão de novembro de 2024, as rótulos editáveis no designer de fluxo de trabalho personalizado foram limitados a 100 caracteres. Esse limite é avaliado quando o fluxo de trabalho é criado ou atualizado.
Os fluxos de trabalho pré-existentes com rótulos acima de 100 caracteres ainda podem ser enviados com sucesso, mas se o fluxo de trabalho for atualizado, o rótulo deve ser reduzido a 100 caracteres ou menos antes de poder ser salvo. Os rótulos incorretos são destacados em vermelho para facilitar a descoberta.
Os novos fluxos de trabalho alertarão sobre o limite dos rótulos antes de serem salvos.
Ação necessária
Recomenda-se que admins com controle sobre fluxos de trabalho personalizados abram e revisem cada fluxo de trabalho para garantir que não tenham erros no modelo.
|
Relatado pela primeira vez em: novembro de 2024 |
Removido da lista atual em: fevereiro de 2025 |
|---|
A nova experiência do destinatário traz melhorias de assinatura para navegadores web em desktop e dispositivos móveis. Essa nova experiência será lançada nos primeiros meses de 2025, mas estará disponível no ambiente de sandbox na primeira semana de dezembro de 2024.
|
Relatado pela primeira vez em: dezembro de 2024 |
Removido da lista atual em: fevereiro de 2025 |
|---|
O Adobe Acrobat Sign mudará o Certificado SSL do Adobe Acrobat Sign em 22 de janeiro de 2025.
Além disso, um novo certificado SSL está sendo implantado para dar suporte às alterações na rede WAF que serão feitas em janeiro de 2025. Este novo certificado afeta diretamente o acesso ao serviço do Acrobat Sign e deve ser instalado antes que o WAF fique online.
Ação necessária
- Cada conta de cliente que protege explicitamente a atividade de rede deve incluir o novo certificado SSL do WAF em sua lista de certificados armazenados.
- Se você tiver integrações personalizadas com o Acrobat Sign usando as APIs SOAP ou REST e se alguma dessas integrações tiver “fixado” a chave pública existente, nenhuma outra ação será necessária.
- Se você estiver usando os certificados SSL do Acrobat Sign para SSO, ou se estiver fixando o próprio certificado (ou usando outros métodos), você pode encontrar os novos certificados SSL do Acrobat Sign em Requisitos do sistema do Adobe Acrobat Sign.
- Se sua configuração de SSO aceitar várias cadeias/certificados públicos, você poderá adicionar os novos certificados agora e remover a cadeia/certificado público antigo da sua configuração após a alteração de janeiro.
- Se o SSO não oferecer suporte a várias cadeias/certificados públicos, você precisará sincronizar a alteração do SSL com o Acrobat Sign em 22 de janeiro de 2025.
Os novos certificados SSL estarão ativos em 22 de janeiro de 2025.
|
Relatado pela primeira vez em: setembro de 2024 - Atualizado em: fevereiro de 2025 |
Removido da lista atual em: março de 2025 |
|---|
Para melhorar a segurança e a robustez do serviço Adobe Acrobat Sign, começaremos a implementar mudanças na rede para incluir um firewall de aplicativos da Web (WAF) em fevereiro de 2025. Essas alterações direcionarão o tráfego para os servidores de aplicativos do Acrobat Sign por meio do serviço WAF. Esse roteamento será imperceptível para a maioria dos clientes. O uso não interferirá com o acesso ao Acrobat Sign de qualquer cliente ou integração da Adobe.
Ação necessária
Nenhum.
Essa alteração não afetará as integrações com os clientes, pois a API do Acrobat Sign e os nomes de domínio da API não mudarão. Esta solução é compatível com versões anteriores dos intervalos de IP publicados.
Os clientes que atualizaram os dispositivos de segurança não precisarão reverter ou fazer mais alterações.
Confira abaixo a programação atual da atualização:
- A sandbox de produção será atualizada em 24 de fevereiro de 2025.
- Partes da produção: IN1, JP1, AU1 e SG1 serão atualizados em 3 de março de 2025.
- Partes da produção: NA2, NA3 e EU2 serão atualizados em 6 de março de 2025.
- Partes da produção: NA1, NA4 e EU1 serão atualizados em 11 de março de 2025.
-
Acesso de entrada e saída ao Acrobat Sign
O Acrobat Sign não retirará a lista de endereços IP de entrada do servidor, conforme anunciado anteriormente.
Os endereços IP de entrada e saída do servidor, conforme documentado na página Requisitos de sistema para o Acrobat Sign, permanecerão utilizáveis. -
Por que o Acrobat Sign está fazendo essas alterações?
O uso de um WAF melhora a proteção do Acrobat Sign contra tráfego prejudicial e nos ajuda a atender melhor aos requisitos de segurança, robustez e conformidade.
-
Tenho uma integração personalizada no Acrobat Sign. Meu aplicativo será afetado?
Não, não esperamos que nenhuma integração seja afetada negativamente.
-
Existem listas de novos endereços IP que podem ser substituídas?
Não.
As informações na página Requisitos de sistema do Acrobat Sign permanecem precisas. -
Minha organização implementou filtragem de rede usando a lista de domínios publicada do Acrobat Sign para tráfego da nossa rede corporativa. Seremos afetados?
Não.
As alterações de rede descritas aqui não afetam a lista de domínios do Acrobat Sign, conforme documentado na página Requisitos de sistema do Acrobat Sign. A filtragem em nível de domínio não é afetada. -
Minha organização utiliza validação de endereço IP para entrega de email de servidores do Acrobat Sign. Seremos afetados?
Não.
Os intervalos de IP para retransmissões de email de saída, conforme listados na página Requisitos de sistema do Acrobat Sign, não mudarão. -
Minha organização configurou nossa conta do Acrobat Sign para restringir o acesso aos nossos próprios endereços IP. Seremos afetados?
Não.
O Acrobat Sign pode ser configurado para validar o tráfego de entrada em relação aos endereços IP escolhidos pelo cliente, conforme descrito na página Restringir o acesso à conta usando intervalos de endereços IP. Esse uso não será afetado por essa alteração. -
Minha organização implementou a filtragem de rede usando a lista publicada de endereços IP de entrada do Acrobat Sign. Seremos afetados?
Não.
A nova configuração do WAF é compatível com as versões antigas da arquitetura de rede existente. Portanto, não é necessário fazer ajustes nos seus dispositivos de segurança.
Observação:Observe que isso se refere à filtragem no nível de IP, no ambiente que hospeda seu aplicativo. A filtragem em nível de domínio não é afetada.
-
Estou usando a integração do Salesforce com a lista de permissões de IP configurada explicitamente. Preciso fazer alguma coisa?
Não.
Neste momento, a instalação do WAF não requer alterações nas instalações existentes do Salesforce.
A configuração/processo existente, conforme descrito na documentação de ajuda, permanece o mesmo, e os administradores devem seguir todas as etapas de inclusão de IP na lista de permissões.
Os ISVs e parceiros integrados devem entrar em contato com seu gerente de sucesso para esclarecer outras dúvidas.
|
Relatado pela primeira vez em: novembro de 2024 - Atualizado em: janeiro de 2025 |
Removido da lista atual em: março de 2025 |
|---|
Os remetentes podem fornecer uma exibição adicional de contratos para destinatários móveis que lista apenas o campo no contrato disponível para o destinatário.
Os remetentes podem organizar a lista de campos como quiserem e agrupar os campos em seções lógicas para ajudar os signatários a percorrer a entrada de campos com o mínimo de rolagem.
Os destinatários têm a opção de exibir a lista de campos compatíveis com dispositivos móveis ou a visualização original em PDF com os campos colocados no conteúdo do documento.
Esse recurso está programado para ser lançado:
- A ser implantado no ambiente de sandbox em 11 de dezembro de 2024
- A ser implantado no ambiente de produção no dia 4 de março de 2025
|
Relatado pela primeira vez em: maio de 2024 |
Removido da lista atual em: março de 2025 |
|---|
A opção de usar uma unidade externa para fazer upload de arquivos será limitada ao OneDrive na nova experiência de Solicitar assinatura.
É recomendado que os clientes que usam outras opções de upload de arquivos usem o aplicativo específico do fornecedor para fornecer uma unidade conectada à rede que possa ser acessada por meio do seletor de arquivos nativo do sistema local do usuário.
- 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
|
Relatado pela primeira vez em: maio de 2024 |
Removido da lista atual em: abril de 2025 |
|---|
Ação necessária
Todas as integrações e aplicativos que usam a API SOAP do Adobe Acrobat Sign devem ser migrados para a API REST v6 mais recente antes da data de desativação para garantir a continuidade da função.
O acesso à API SOAP será removido para todos os parceiros integrados a partir de 1° de março de 2025.
Para garantir que a continuidade da função, todos os parceiros integrados que usam a API SOAP do Adobe Acrobat Sign devem migrar para a versão mais recente da API REST V6 antes de 1° de março de 2025.
Consulte a documentação da REST v6 e da migração como referência:
- Métodos da API REST do Adobe Acrobat Sign versão 6
- Migração da SOAP
Para quaisquer consultas, entre em contato com o PSM do Adobe Acrobat Sign designado.
Observação:
Essa atualização se aplica somente à versão Comercial do serviço do Acrobat Sign. As contas da Government Cloud não serão afetadas.
Esta atualização se aplica apenas à página Enviar (Solicitar assinaturas eletrônicas). Os fluxos de trabalho de Autoassinatura estruturada ainda não foram incluídos.
|
Relatado pela primeira vez em: março de 2024 - Atualizado em: janeiro de 2025 |
Removido da lista atual em: abril de 2025 |
|---|
A partir da versão de abril de 2025, o ambiente de Solicitar assinatura moderno se tornará a experiência padrão ao criar um novo contrato.
- Os usuários não poderão mais alternar entre o ambiente novo e o clássico, pois os links de alternância serão desabilitados.
- Admins ainda terão a opção de habilitar a experiência clássica e restaurar os links de alternância por meio do menu de administração.
- Essa alteração não afetará clientes que usam a integração com a Notarize.
|
Relatado pela primeira vez em: março de 2024 – Atualizado em: abril de 2025 |
Removido da lista atual em: abril de 2025 |
|---|
Observação:
Essa atualização se aplica somente à versão Comercial do serviço do Acrobat Sign. As contas da Government Cloud não serão afetadas.
A partir da versão de abril de 2025, o ambiente moderno Solicitar assinatura será a experiência padrão ao criar um novo modelo de envio em massa.
- Os usuários não poderão voltar ao ambiente clássico.
- Os administradores terão a opção de habilitar a experiência clássica e restaurar os links de alternância pelo menu de administração.
|
Relatado pela primeira vez em: fevereiro de 2025 |
Removido da lista atual em: abril de 2025 |
|---|
A guia Conta, disponível para admins de nível de conta do Acrobat Sign, será renomeada como Admin.
- Esta atualização aplica-se exclusivamente ao ambiente autônomo do Acrobat Sign (Acrobat Sign Solutions e Acrobat Sign for Government).
- A atualização será implementada no ambiente comercial em abril de 2025 e no ambiente governamental em maio de 2025.
Observe que essa alteração é puramente cosmética: não há modificações funcionais, apenas atualizações para os rótulos das guias.
Observação:
O rótulo Grupo para admins de nível de grupo não será alterado.
|
Relatado pela primeira vez em: março de 2025 |
Removido da lista atual em: abril de 2025 |
|---|
- Experiência de logon de usuário aprimorada - O Acrobat Sign simplificou o processo de logon e autenticação por meio do Sistema de gerenciamento de identidade da Adobe (IMS).
- O perfil organizacional do usuário é selecionado automaticamente durante o processo de logon de usuários autorizados com o serviço do Acrobat Sign (a solicitação é identificada como oriunda do Acrobat Sign)
- Os usuários que encontrarem erros durante o logon terão links em suas mensagens de erro para entrar em contato com os administradores do Acrobat Sign para obter ajuda.
- Todos os usuários que receberem um direito ativo, mas não fizerem logon no serviço, receberão até dois lembretes por email. (Isso também se aplica a usuários inativos existentes antes da data de lançamento)
Essas melhorias simplificam o logon, reduzem a complexidade e melhoram a experiência geral do usuário.
Ambientes disponíveis: comercial | Níveis de serviço disponíveis: Acrobat Sign Solutions | Escopo de configuração: habilitado por padrão; não configurável
|
Relatado pela primeira vez em: março de 2025 — Atualizado em: abril de 2025 |
Removido da lista atual em: junho de 2025 |
|---|
A partir da versão de maio de 2025, o Acrobat Sign implementará limites mais rígidos no número de webhooks criados em contas de nível de desenvolvedor.
Esses limites foram escolhidos intencionalmente para garantir a confiabilidade da infraestrutura de webhooks e alinhar-se melhor aos fluxos de trabalho de teste.
|
O que está mudará |
Limite anterior |
Novo limite |
Descrição |
|---|---|---|---|
|
Número de webhooks ativos criados por canal |
10 |
1 |
Um webhook é permitido para o canal por evento de assinatura de webhook. |
|
Número de webhooks ativos criados para uma conta |
100 |
2 |
Dois webhooks no nível da conta são permitidos por evento de assinatura de webhook. |
|
Número de webhooks ativos criados por grupo |
100 |
2 |
Dois webhooks de nível de grupo são permitidos por grupo e por evento de assinatura de webhook. |
|
Número de webhooks ativos criados por recurso de contrato |
50 |
1 |
1 webhook é permitido por contrato e por evento de assinatura de webhook. |
|
Número de webhooks ativos criados por usuário |
100 |
1 |
1 webhook é permitido por usuário por evento de assinatura de webhook. |
Ambientes disponíveis: comercial | Níveis de serviço disponíveis: desenvolvedor | Escopo de configuração: habilitado por padrão; não configurável
|
Relatado pela primeira vez em: março de 2025 |
Removido da lista atual em: abril de 2025 |
|---|
Agora, os clientes do Acrobat Sign podem assinar o serviço de webhook do Acrobat Sign para receber notificações ativas sobre cortes, interrupções e eventos de manutenção por meio do portal de status da Adobe.
Gerencie e adicione assinaturas aqui: Ajuda para assinaturas de status da Adobe.
Observe que o serviço do Adobe Acrobat Sign está listado sob o título Document Cloud:
|
Relatado pela primeira vez em: março de 2025 |
Removido da lista atual em: junho de 2025 |
|---|
Na versão de maio de 2025, otimizaremos a API GET /agreements para reduzir significativamente os tempos de resposta; nossos testes internos apresentaram resultados até 10 vezes superiores.
O que mudou
- Tamanhos de página menores: para permitir essas melhorias, reduzimos o número máximo de contratos retornados por solicitação para 500, mas esse limite pode mudar nas versões futuras. Cada resposta inclui:
- O número real de contratos retornados
- Um link para a próxima página de resultados (se disponível)
- Contagem dinâmica de resultados: ainda é possível solicitar um número específico de contratos, mas a API retornará a quantidade que o serviço for capaz de fornecer. Cada resposta inclui:
O que esperar
Em alguns casos, pode haver um leve atraso entre a criação e a recuperação de um contrato usando a API GET /agreements. Esse atraso geralmente é muito curto; uma solicitação de acompanhamento deve retornar o novo contrato.
Ambientes disponíveis: comercial, governamental | Níveis de serviço disponíveis: Acrobat Sign Services, Government | Escopo de configuração: habilitado por padrão; não configurável
|
Relatado pela primeira vez em: abril de 2025 |
Removido da lista atual em: agosto de 2025 |
|---|
Todas as contas que usam o serviço Acrobat Sign for Government terão acesso para habilitar o novo ambiente Solicitar assinatura, além de vários recursos recentes que dependem dele:
- eWitnessing
- Acesso restrito aos contratos
- Impor tipo de assinatura
- Verificação de identidade
- CCs por destinatário
- A lista de destinatários e as propriedades de destinatários são editáveis após a criação
|
Relatado pela primeira vez em: setembro de 2024 |
Removido da lista atual em: fevereiro de 2026 |
|---|
Ação necessária
Todos os clientes que usam a API devem atualizá-la para utilizar os pontos de acesso da versão 6 o quanto antes, para garantir a continuidade do serviço sem interrupções.
As versões de 1 a 4 da API REST do Acrobat Sign foram descontinuadas e serão removidas do serviço em 1º de dezembro de 2025.
Atualizar APIs pode envolver um esforço considerável, portanto, todos os clientes são enfaticamente incentivados a definir o escopo e o orçamento de sua atualização o mais rápido possível para que o suporte possa ser totalmente envolvido para resolver dúvidas ou problemas que surjam antes da data limite em dezembro de 2025.
Embora estejam obsoletas, as APIs REST v1-4 continuarão ativas, e seus aplicativos continuarão funcionando até 1º de dezembro de 2025, quando serão então removidas.
Após 1º de dezembro de 2025, os aplicativos criados nas APIs REST v1-4 deixarão de funcionar.
|
Relatado pela primeira vez em: abril de 2025 |
Removido da lista atual em: fevereiro de 2026 |
|---|
Todas as contas que usam o serviço Acrobat Sign for Government terão acesso para habilitar o novo ambiente Solicitar assinatura, além de diversos recursos recentes que dependem dele:
- eWitnessing
- Acesso restrito aos contratos
- Impor tipo de assinatura
- Verificação de identidade
- CCs por destinatário
- A lista de destinatários e as propriedades de destinatários são editáveis após a criação
|
Relatado pela primeira vez em: setembro de 2024. Atualizado em abril de 2025 |
Removido da lista atual em: fevereiro de 2026 |
|---|
A infraestrutura do Webhook 2.0 foi implantada para todos os clientes e, com isso concluída. As notificações do signatário foram descontinuadas. Como resultado, o parâmetro webhookNotificationApplicableUsers da carga útil do webhook não fornecerá mais dados úteis e será removido de todas as cargas úteis do webhook.
O ambiente de sandbox será atualizado na versão de junho.
Os ambientes de produção serão atualizados na versão de julho de 2025.
A userID de envio e o email podem ser encontrados usando os parâmetros initiatingUserId e initiatingUserEmail no conteúdo de notificação.
|
Relatado pela primeira vez em: agosto de 2025 - atualizado em: outubro de 2025 |
Removido da lista atual em: fevereiro de 2026 |
|---|
Para ajudar a manter a estabilidade do sistema e melhorar o desempenho, o Acrobat Sign introduzirá um limite de sondagem na versão de 4 de novembro de 2025 (versão 16.2.1). Essa mudança limita a frequência com que os aplicativos clientes podem sondar pontos de acesso específicos da API.
- Os clientes têm dois meses após o lançamento da versão 16.2.1 para implementar as mudanças na sondagem recomendadas em seu código. Durante esse período, o sistema só REGISTRARÁ os eventos dentro do limite do intervalo de sondagem.
- Após dezembro de 2025, as políticas de proteção de sondagem serão alteradas para APLICAR, e os erros começarão a ser acionados para os usuários.
A sondagem de alta frequência cria uma carga desnecessária nos sistemas de back-end, resultando em desempenho degradado e tempos de resposta mais lentos. Os desenvolvedores de API são incentivados a mudar para webhooks para atualizações em tempo real.
O que está mudando
Esta política de sondagem aplica-se a todos os pontos de acesso da API GET.
Exemplos de endpoints afetados
Recuperação de status:
- GET /agreements/{agreementId) – Recupera o status atual de um acordo.
- GET /agreements/{agreementId)/documents/{documentId) – Recupera o fluxo de arquivo de um documento dentro de um acordo.
Listagem:
- GET /agreements – Recupera acordos para o usuário.
- GET /agreements/{agreementId)/events – Recupera informações de eventos para um acordo.
Um limite será aplicado à frequência com que o usuário efetivo pode fazer a mesma chamada da API para o serviço do Acrobat Sign. Um erro é retornado se a mesma chamada for feita dentro do intervalo mínimo de sondagem pelo mesmo usuário efetivo.
Detalhes da política de sondagem
- Intervalo mínimo de sondagem de objeto (MOPI, na sigla em inglês): o MOPI padrão varia de acordo com o nível de serviço e os tipos de aplicativo:
- Aplicativos parceiros do Acrobat Sign: o MOPI no caso de um aplicativo parceiro é determinado pelo nível da conta do usuário.
- Nível GLOBAL/EMPRESARIAL: três chamadas por intervalo de um minuto
- Todos os outros níveis: 1 chamada única por intervalo de dez minutos
- Aplicativos clientes em contas globais/empresariais: três chamadas idênticas por intervalo de um minuto.
- Aplicativos clientes em contas de desenvolvedor: uma chamada exclusiva por intervalo de 10 minutos.
- Aplicativos parceiros do Acrobat Sign: o MOPI no caso de um aplicativo parceiro é determinado pelo nível da conta do usuário.
- Solicitações duplicadas dentro do MOPI: se o mesmo usuário efetivo fizer solicitações GET idênticas (mesmos caminho e cabeçalhos) mais de uma vez dentro do MOPI, o sistema retornará:
- Código do status 304 Não modificado para solicitações condicionais em HTTP que usam uma ETag.
- Código do status 429 Excesso de solicitações com uma nova tentativa posterior para outras solicitações.
- Tratamento de ETags: esta política aplica-se quando os valores das ETags são fornecidos no cabeçalho If-None-Match para pontos de acesso que já são compatíveis com 304 Não modificado.
Ação necessária
Webhooks: se o seu aplicativo precisar de atualizações quase em tempo real, use webhooks em vez da sondagem. Os webhooks são uma maneira mais eficiente e dimensionável de receber atualizações em tempo hábil.
Se não for possível implementar webhooks, os aplicativos devem implementar mecanismos de cache no lado do cliente para armazenar e reutilizar as respostas da API. Quando uma resposta 304 Não modificado é recebida, os dados em cache devem ser usados em vez de fazer outra chamada à API.
Os clientes têm dois meses após o lançamento da versão 16.2.1 para implementar as mudanças na sondagem recomendadas em seu código. Durante esse período, o sistema irá REGISTRAR os eventos de limite do intervalo de polling.
Após dezembro de 2025, as políticas de proteção de polling serão alteradas para APLICAR e os erros começarão a ser acionados para os usuários.
Entre em contato com seu CSM se precisar de assistência ou tiver alguma dúvida.
O ambiente sandbox permitirá que a política de polling REGISTRE erros em 17 de setembro de 2025 e seja configurada para APLICAR em 25 de setembro de 2025.
|
Relatado pela primeira vez em: agosto de 2025 |
Removido da lista atual em: fevereiro de 2026 |
|---|
Para atender aos requisitos do FedRAMP CSP, estamos habilitando o protocolo IPv6 no ambiente do Acrobat Sign for Government :
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Relatado primeiro em: setembro de 2025 |
Removido da lista atual em: fevereiro de 2026 |
|---|
A validação das configurações de idioma foi reforçada ao criar um contrato via API. Se a localidade de um contrato não for permitida pelas políticas da conta, a API rejeitará a solicitação com um erro claro. Isso reduz incompatibilidades não intencionais de idioma e mantém as experiências dos destinatários alinhadas com as configurações aprovadas.
Quem é afetado
- Contas que definem a localidade do contrato em solicitações de API.
- Contas que restringem localidades disponíveis ou não permitem alterações de localidade durante o envio.
O que mudou
Quando a configuração DISPLAY_LOCALE_INFO_DURING_SEND está ativada (nível GLOBAL), a API impõe:
- A localidade do contrato precisa ser incluída nas AVAILABLE_LOCALES do usuário.
- Se a opção ALLOW_LOCALE_SELECTION_DURING_SEND for falsa, a localidade do contrato precisará corresponder à AGREEMENT_LOCALE do usuário.
Violações fazem com que POST /agreements falhe com: “Localidade inválida ou ausente”.
Erro comum e como corrigi-lo
Erro: “Localidade inválida ou ausente”.
- Verifique a localidade usada na solicitação da API (por exemplo, en_US).
- Confirme se a localidade aparece em AVAILABLE_LOCALES para o usuário que faz a chamada.
- Se ALLOW_LOCALE_SELECTION_DURING_SEND for falso, certifique-se de que a localidade da solicitação corresponda a AGREEMENT_LOCALE.
- Se for necessária flexibilidade entre regiões, habilite a seleção de localidade no momento do envio (veja “Ação necessária”).
Compatibilidade retroativa
- Antes dessa alteração, algumas solicitações com localidades incompatíveis podiam ser bem-sucedidas. Agora, essas solicitações falham com um erro claro quando as validações não são aprovadas.
- Sem alterações no esquema da API; o comportamento de validação muda apenas quando DISPLAY_LOCALE_INFO_DURING_SEND está ativado.
Ação necessária
Administradores e integradores de API devem fazer uma das seguintes ações:
- Alinhar a localidade nas solicitações de API com as AVAILABLE_LOCALES e, se a opção ALLOW_LOCALE_SELECTION_DURING_SEND for falsa, corresponder exatamente à AGREEMENT_LOCALE
- ou -
- Permitir a seleção de localidade no momento do envio configurando:
- ALLOW_LOCALE_SELECTION_DURING_SEND = verdadeiro
- CAN_CHANGE_UI_LOCALE = verdadeiro
|
Relatado primeiro em: dezembro de 2025 |
Removido da lista atual em: fevereiro de 2026 |
|---|
O Adobe Acrobat Sign mudará o certificado SSL do Adobe Acrobat Sign em 7 de janeiro de 2026.
Ação necessária
- Se você tiver integrações personalizadas com o Acrobat Sign por meio das APIs REST e se alguma dessas integrações tiver “fixado” a chave pública existente, nenhuma outra ação será necessária.
- Se você estiver usando os certificados SSL do Acrobat Sign para SSO, ou se estiver fixando o próprio certificado (ou usando outros métodos), você pode encontrar os novos certificados SSL do Acrobat Sign em Requisitos do sistema do Adobe Acrobat Sign.
- Se sua configuração de SSO aceitar várias cadeias/certificados públicos, você poderá adicionar os novos certificados agora e remover a cadeia/certificado público antigo da sua configuração após a alteração de janeiro.
- Se o SSO não permitir várias cadeias/certificados públicos, você precisará sincronizar a alteração do SSL com o Acrobat Sign em 7 de janeiro de 2026.
Os novos certificados SSL estarão ativos em 7 de janeiro de 2026.
|
Relatado pela primeira vez em: setembro de 2024. Atualizado em abril de 2025 |
Atual |
|---|
A infraestrutura do Webhook 2.0 foi implantada para todos os clientes e, com isso concluída. As notificações do signatário foram descontinuadas. Como resultado, o parâmetro webhookNotificationApplicableUsers da carga útil do webhook não fornecerá mais dados úteis e será removido de todas as cargas úteis do webhook.
O ambiente de sandbox será atualizado na versão de junho.
Os ambientes de produção serão atualizados na versão de julho de 2025.
A userID de envio e o email podem ser encontrados usando os parâmetros initiatingUserId e initiatingUserEmail no conteúdo de notificação.