Prima segnalazione: agosto 2024
Ultimo aggiornamento il
9 feb 2026
Le notifiche tecniche di adobe sign sono ordinate di seguito con l'aggiornamento più vecchio in alto e procedendo in avanti nel tempo scorrendo verso il basso la pagina.
|
|
Rimosso dall’elenco attuale: gennaio 2025 |
|---|
La precedente intestazione Accept-Charset verrà rimossa da tutte le notifiche webhook e callback con la versione di novembre 2024.
Tutti i clienti che usano a questa intestazione per qualsiasi motivo devono ridefinire il codice per tenere in conto la sua mancanza.
|
Prima segnalazione: settembre 2024 |
Rimosso dall’elenco attuale: gennaio 2025 |
|---|
|
Prima segnalazione: novembre 2024 |
Rimosso dall’elenco attuale: gennaio 2025 |
|---|
Con la versione di novembre 2024, le etichette modificabili nella Progettazione flussi di lavoro personalizzati sono state limitate a 100 caratteri. Questo limite viene valutato quando viene creato o aggiornato il flusso di lavoro.
I flussi di lavoro preesistenti con etichette superiori a 100 caratteri possono comunque essere inviati correttamente, ma se il flusso di lavoro viene aggiornato, prima di poterlo salvare, è necessario ridurre l’etichetta a 100 caratteri o meno. Le etichette dannose sono contrassegnate in rosso per facilitarne l’individuazione.
Nei nuovi flussi di lavoro, il limite di etichette verrà segnalato prima che vengano salvati.
Azione necessaria
Si consiglia agli amministratori con controllo sui flussi di lavoro personalizzati di aprire e di rivedere ogni flusso di lavoro per garantire che nel modello non vengano generati errori.
|
Prima segnalazione: novembre 2024 |
Rimosso dall’elenco Attuale: febbraio 2025 |
|---|
La nuova esperienza del destinatario contiene miglioramenti della firma sia per browser web desktop che per dispositivi mobili.Questa nuova esperienza verrà implementata nei primi mesi del 2025, ma sarà disponibile nell’ambiente sandbox nella prima settimana di dicembre 2024.
|
Prima segnalazione: dicembre 2024 |
Rimosso dall’elenco Attuale: febbraio 2025 |
|---|
Adobe Acrobat Sign sostituirà il certificato SSL di Adobe Acrobat Sign il 22 gennaio 2025.
Inoltre, viene distribuito un nuovo certificato SSL per supportare le modifiche alla rete WAF apportate a gennaio 2025. Questo nuovo certificato influisce direttamente sull’accesso al servizio Acrobat Sign e deve essere installato prima che il WAF sia messo online.
Azione necessaria
- Ogni account cliente che garantisce esplicitamente l’attività della rete deve includere il nuovo certificato SSL WAF nel suo elenco di certificati archiviati.
- Se sono state implementate integrazioni personalizzate con Acrobat Sign utilizzando le API SOAP o REST e se alcune di tali integrazioni richiedono il “pinning” della chiave pubblica esistente, non è necessario alcun intervento.
- Se stai utilizzando i Certificati SSL di acrobat sign per SSO o se stai agganciando il certificato stesso (o utilizzando altri metodi), puoi trovare i nuovi Certificati SSL di acrobat sign nei requisiti di sistema di adobe acrobat sign.
- Se la configurazione SSO supporta più certificati/catene di certificati pubbliche, si possono aggiungere subito i nuovi certificati e rimuovere dalla configurazione quelli precedenti dopo la sostituzione in gennaio.
- Se SSO non supporta più certificati/catene di certificati pubbliche, sarà necessario sincronizzare il passaggio al nuovo SSL con Acrobat Sign il 22 gennaio 2025.
I nuovi certificati SSL saranno attivi dal 22 gennaio 2025.
|
Prima segnalazione: settembre 2024 - Aggiornamento: febbraio 2025 |
Rimosso dall'elenco corrente: marzo 2025 |
|---|
Per migliorare la sicurezza e l’affidabilità del servizio Adobe Acrobat Sign, inizieremo a introdurre le modifiche apportate alla rete per includere un firewall per applicazioni web (WAF, Web Application Firewall) a febbraio 2025. Queste modifiche indirizzeranno il traffico ai server dell’applicazione Acrobat Sign tramite il servizio WAF. Questo indirizzamento sarà invisibile per la maggior parte della clientela. L’utilizzo non interferirà con l’accesso ad Acrobat Sign da parte di qualsiasi client o integrazione Adobe.
Azione necessaria
Nessuna.
Questa modifica non avrà alcun impatto sulle integrazioni della clientela, poiché i nomi del dominio API e le API di Acrobat Sign non cambieranno. Questa soluzione è retrocompatibile con gli intervalli di IP pubblicati.
I clienti che hanno aggiornato i loro dispositivi di sicurezza non devono ripristinare o apportare altre modifiche.
La pianificazione corrente dell’aggiornamento è la seguente:
- La sandbox di produzione viene aggiornata il 24 febbraio 2025.
- Le partizioni di produzione IN1, JP1, AU1 e SG1 verranno aggiornate il 3 marzo 2025.
- Le partizioni di produzione NA2, NA3 e EU2 verranno aggiornate il 6 marzo 2025.
- Le partizioni di produzione NA1, NA4 e EU1 verranno aggiornate l’11 marzo 2025.
-
Accesso in ingresso e in uscita da Acrobat Sign
L’elenco degli indirizzi IP in entrata del server non saranno più rimossi da Acrobat Sign come annunciato in precedenza.
Gli indirizzi IP in entrata e in uscita del server, come documentato alla pagina Requisiti di sistema per Acrobat Sign, resteranno validi. -
Perché Acrobat Sign sta apportando queste modifiche?
L’utilizzo di un WAF migliora la protezione di Acrobat Sign dal traffico dannoso e aiuta a soddisfare meglio i requisiti di sicurezza, solidità e conformità.
-
Dispongo di un’integrazione personalizzata con Acrobat Sign. La mia applicazione sarà interessata?
No, non ci aspettiamo alcun impatto negativo sulle integrazioni.
-
Sono disponibili nuovi elenchi di indirizzi IP da sostituire?
No.
Le informazioni nella pagina requisiti di sistema per acrobat sign rimangono accurate. -
La mia organizzazione ha implementato il filtro della rete utilizzando l’elenco dei domini pubblicato di Acrobat Sign per il traffico dalla nostra rete aziendale. Queste modifiche avranno un impatto per noi?
No.
Le modifiche di rete descritte qui non influiscono sull'elenco dei domini di acrobat sign, come documentato nella pagina requisiti di sistema per acrobat sign.Il filtro a livello di dominio rimane inalterato. -
La mia organizzazione utilizza la convalida dell’indirizzo IP per l’invio delle e-mail dai server di Acrobat Sign. Queste modifiche avranno un impatto per noi?
No.
Gli intervalli IP per i relay di posta in uscita, come elencati nella pagina requisiti di sistema per acrobat sign, non cambiano. -
La mia organizzazione ha configurato l’account Acrobat Sign per limitare l’accesso ai nostri stessi indirizzi IP. Queste modifiche avranno un impatto per noi?
No.
acrobat sign può essere configurato per convalidare il traffico in entrata rispetto agli indirizzi IP scelti dal cliente, come descritto nella pagina Limita l'accesso al tuo account utilizzando intervalli di indirizzi IP.Tale utilizzo non sarà interessato da questa modifica. -
La mia organizzazione ha implementato il filtro della rete utilizzando l’elenco pubblicato di indirizzi IP di ingresso di Acrobat Sign. Queste modifiche avranno un impatto per noi?
No.
La nuova configurazione WAF è retrocompatibile con l’architettura di rete esistente, quindi non dovrebbe essere necessario regolare i dispositivi di sicurezza.
Nota:Tieni presente che questo si riferisce al filtro a livello IP per l’ambiente di hosting dell’applicazione. Il filtro a livello di dominio rimane inalterato.
-
Utilizzo l’integrazione Salesforce con elenchi degli IP consentiti configurati in modo esplicito. Devo fare qualcosa?
No.
Al momento, l’installazione WAF non richiede modifiche per le installazioni Salesforce esistenti.
La configurazione o il processo esistente, come descritto nella documentazione della Guida, rimane invariato e gli amministratori devono seguire tutti i passaggi relativi all’elenco degli IP consentiti.
Per ulteriori domande, ISV e partner Embed possono contattare il proprio Success Manager.
|
Prima segnalazione: novembre 2024 - Aggiornamento: gennaio 2025 |
Rimosso dall'elenco corrente: marzo 2025 |
|---|
I mittenti possono fornire una visualizzazione aggiuntiva degli accordi per i destinatari sui dispositivi mobili che elenca solo il campo all’interno dell’accordo disponibile per il destinatario.
I mittenti possono organizzare l’elenco dei campi in base alle proprie esigenze e raggruppare i campi in sezioni logiche per aiutare i firmatari a passare attraverso le immissioni dei campi con un minimo scorrimento.
I destinatari possono visualizzare l’elenco dei campi adatti per dispositivi mobili o la vista originale del PDF con i campi inseriti nel contenuto del documento.
Questa funzione verrà rilasciata:
- Verrà distribuita nell’ambiente sandbox l’11 dicembre 2024
- Verrà distribuita nell’ambiente di produzione il 4 marzo 2025
|
Prima segnalazione: maggio 2024 |
Rimosso dall'elenco corrente: marzo 2025 |
|---|
Nella nuova esperienza Richiedi firma, l’opzione per utilizzare un’unità esterna per caricare i file sarà limitata solo a OneDrive.
A chi utilizza altre opzioni per il caricamento dei file, si consiglia di utilizzare l’applicazione di un fornitore specifico per fornire un’unità di rete a cui è possibile accedere tramite il selettore di file nativo sul sistema locale dell’utente.
- 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
|
Prima segnalazione: maggio 2024 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
Azione necessaria
Per garantire la continuità delle funzioni, tutte le integrazioni e le applicazioni che utilizzano le API SOAP di Adobe Acrobat Sign devono essere migrate all’ultima versione delle API REST v6 prima della data di disattivazione.
L’accesso alle API SOAP sarà rimosso per tutti i partner Embed a partire dal 1° marzo 2025.
Per garantire la continuità funzionale, tutti i partner Embed che utilizzano le API SOAP di Adobe Acrobat Sign devono migrare alla più recente API REST v6 prima del 1°marzo 2025.
Consulta la documentazione di riferimento su REST v6 e migrazione:
- Metodi API REST versione 6 per Adobe Acrobat Sign
- Migrazione da SOAP
Per qualsiasi richiesta, contatta il PSM designato per Adobe Acrobat Sign.
Nota:
Questo aggiornamento interessa solo la versione Commercial del servizio Acrobat Sign. Gli account Government Cloud non sono interessati.
Questo aggiornamento si applica solo alla pagina Invia (Richiedi firme elettroniche).I flussi di lavoro Firma autonoma strutturata non sono ancora inclusi.
|
Prima segnalazione: marzo 2024 - Aggiornamento: gennaio 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
A partire dalla versione di aprile 2025, il nuovo ambiente Richiedi firma diventerà l’esperienza predefinita per la creazione di un nuovo accordo.
- Non sarà più possibile passare dal nuovo ambiente a quello classico e viceversa, in quanto i collegamenti per cambiare ambiente saranno disabilitati.
- Tramite il menu di amministrazione, gli amministratori potranno comunque abilitare l’esperienza classica e ripristinare i collegamenti per passare da un ambiente all’altro.
- Chi utilizza l’integrazione Notarize non sarà interessato da questa modifica.
|
Prima segnalazione: marzo 2024 - Aggiornato aprile 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
Nota:
Questo aggiornamento interessa solo la versione Commercial del servizio Acrobat Sign. Gli account Government Cloud non sono interessati.
A partire dal rilascio di aprile 2025, l'ambiente moderno Request Signature diventerà l'esperienza predefinita disponibile durante la creazione di un nuovo modello Invia in blocco.
- Gli utenti non potranno tornare all'ambiente classico.
- Gli amministratori avranno la possibilità di abilitare l'esperienza classica e ripristinare i collegamenti di commutazione tramite il menu amministratore.
|
Prima segnalazione: febbraio 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
La scheda Account, disponibile per gli amministratori a livello di account di Acrobat Sign, verrà rinominata Amministrazione.
- Questo aggiornamento si applica esclusivamente all’ambiente autonomo di Acrobat Sign (Acrobat Sign Solutions e Acrobat Sign per la Pubblica Amministrazione).
- L’aggiornamento verrà implementato per l’ambiente Commercial ad aprile 2025 e per l’ambiente Government a maggio 2025.
Tenere presente che questa modifica è puramente estetica: non vi sono modifiche funzionali, solo aggiornamenti alle etichette delle schede.
Nota:
L’etichetta Gruppo per gli amministratori a livello di gruppo non cambierà.
|
Prima segnalazione: marzo 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
- Esperienza di accesso utente migliorata: Acrobat Sign ha semplificato il processo di accesso e di autenticazione tramite il Sistema di gestione delle identità di Adobe (IMS).
- Il profilo organizzativo dell’utente viene selezionato automaticamente durante il processo di accesso per quelli autorizzati al servizio Acrobat Sign (identificando la richiesta come proveniente da un’origine Acrobat Sign)
- Gli utenti che riscontrano errori durante l’accesso avranno collegamenti nei messaggi di errore per contattare gli amministratori di Acrobat Sign per ricevere assistenza.
- A tutti gli utenti a cui è stato assegnato un diritto attivo ma che non hanno effettuato l’accesso al servizio verranno inviati fino a due promemoria e-mail. (Questo vale anche per gli utenti inattivi esistenti prima della data di rilascio)
Questi miglioramenti semplificano l’accesso, riducendo gli ostacoli e favorendo un’esperienza utente ottimale.
Ambienti disponibili: Commercial | Livelli di servizio disponibili: Acrobat Signs Solutions | Ambito di configurazione: abilitata per impostazione predefinita; non configurabile
|
Prima segnalazione: marzo 2025 - Aggiornato: aprile 2025 |
Rimosso dall'elenco corrente: giugno 2025 |
|---|
A partire da maggio 2025, Acrobat Sign implementerà limiti più rigidi per il numero di webhook creati negli account a livello Sviluppatore.
Questi limiti sono state appositamente selezionati per garantire l’affidabilità dell’infrastruttura webhook e ottimizzati per la verifica dei flussi di lavoro.
|
Che cosa cambia |
Limite precedente |
Nuovo limite |
Descrizione |
|---|---|---|---|
|
Numero di webhook attivi creati per canale |
10 |
1 |
È consentito un webhook per canale per evento di abbonamento del webhook. |
|
Numero di webhook attivi creati per un account |
100 |
2 |
Sono consentiti due webhook a livello di account per evento di abbonamento del webhook. |
|
Numero di webhook attivi creati per gruppo |
100 |
2 |
Sono consentiti due webhook di livello per gruppo per evento di abbonamento del webhook. |
|
Numero di webhook attivi creati per risorsa accordo |
50 |
1 |
È consentito un webhook per accordo per evento di abbonamento del webhook. |
|
Numero di webhook attivi creati per utente |
100 |
1 |
È consentito un webhook per utente per evento di abbonamento del webhook. |
Ambienti disponibili: Commercial Livelli di servizio disponibili:Sviluppatore Ambito di configurazione:abilitato per impostazione predefinita; non configurabile
|
Prima segnalazione: marzo 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
La clientela di Acrobat Sign può abbonarsi al servizio webhook di Acrobat Sign per ricevere notifiche proattive su disservizi, interruzioni ed eventi di manutenzione tramite il portale di Adobe Status.
Gestisci e aggiungi abbonamenti qui: guida per l’abbonamento ad Adobe Status.
Nota che il servizio Adobe Acrobat Sign è elencato nell’intestazione Document Cloud:
|
Prima segnalazione: marzo 2025 |
Rimosso dall'elenco corrente: giugno 2025 |
|---|
Nella versione di maggio 2025, l’API GET/agreements verrà ottimizzata per ridurre significativamente i tempi di risposta. I test interni mostrano miglioramenti con tempi fino a 10 volte inferiori.
Che cosa cambia
- Dimensioni di pagina più piccole: per supportare questi miglioramenti, il numero massimo di accordi restituiti per richiesta è stato ridotto a 500, ma questo limite potrebbe cambiare nelle versioni future. Ogni risposta include:
- Il numero effettivo di accordi restituiti
- Un collegamento alla pagina successiva dei risultati (se disponibile)
- Conteggio dei risultati dinamici: è comunque possibile richiedere un numero specifico di accordi, ma l’API restituirà tutti gli accordi che il servizio può fornire. Ogni risposta include:
Che cosa aspettarsi
In alcuni casi, potrebbe verificarsi un leggero ritardo tra la creazione di un accordo e il recupero utilizzando l’API GET/agreements. Questo ritardo è in genere molto breve; una richiesta di follow-up deve restituire il nuovo accordo.
Ambienti disponibili: Commercial, Government | Livelli di servizio disponibili: Acrobat Sign Services, Government | Ambito di configurazione: abilitato per impostazione predefinita; non configurabile
|
Prima segnalazione: aprile 2025 |
Rimosso dall'elenco corrente: agosto 2025 |
|---|
Tutti gli account che utilizzano il servizio Acrobat Sign for Government otterranno l'accesso per abilitare il nuovo ambiente Request Signature, insieme a diverse funzionalità create di recente che dipendono da esso:
- eWitnessing
- Accesso limitato agli accordi
- Applica tipo di firma
- Verifica identità
- CC per destinatario
- L’elenco dei destinatari e le proprietà dei destinatari sono modificabili dopo l’authoring
|
Prima segnalazione: settembre 2024 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Azione necessaria
Tutti i clienti che utilizzano l'API devono aggiornare le proprie API per utilizzare gli endpoint versione 6 il prima possibile per garantire la disponibilità ininterrotta.
Le versioni 1 a 4 dell’API REST di Acrobat Sign sono state disattivate e verranno rimosse dal servizio il 1° dicembre 2025.
L’aggiornamento delle API può comportare un impegno considerevole, pertanto si consiglia vivamente a tutta la clientela di definire l’ambito e il budget del proprio aggiornamento il prima possibile, in modo che il supporto possa pienamente dedicarsi a risolvere eventuali domande o problemi che potrebbero sorgere prima della data di scadenza, a dicembre 2025.
Sebbene le API REST v1-4 siano obsolete, continueranno a funzionare e le applicazioni continueranno a operare fino al 1 dicembre 2025, quando verranno rimosse le API REST v1-4.
Dopo il 1° dicembre 2025, le applicazioni basate sull’API REST v1–4 cesseranno di funzionare.
|
Prima segnalazione: aprile 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Tutti gli account che utilizzano il servizio Acrobat Sign for Government otterranno l'accesso per abilitare il nuovo ambiente Request Signature, insieme a diverse funzionalità create di recente che dipendono da esso:
- eWitnessing
- Accesso limitato agli accordi
- Applica tipo di firma
- Verifica identità
- CC per destinatario
- L’elenco dei destinatari e le proprietà dei destinatari sono modificabili dopo l’authoring
|
Prima segnalazione: settembre 2024 - Aggiornamento: aprile 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
L’infrastruttura Webhook 2.0 è stata implementata per tutta la clientela e, con il completamento di questa operazione, le notifiche per i firmatari sono state rimosse. Di conseguenza, il parametro webhookNotificationApplicableUsers del payload webhook non fornisce più dati utili e verrà rimosso da tutti i payload webhook.
L’ambiente sandbox verrà aggiornato nella versione di giugno.
Gli ambienti di produzione verranno aggiornati nella versione di luglio 2025.
L’ID utente e l’e-mail di invio possono essere trovati utilizzando i parametri initiatingUserId e initiatingUserEmail nel payload di notifica.
|
Prima segnalazione: agosto 2025 - Aggiornato ottobre 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Per contribuire a mantenere la stabilità del sistema e migliorare le prestazioni, Acrobat Sign introdurrà una soglia di polling nel rilascio del 4 novembre 2025 (versione 16.2.1). Questa modifica limita la frequenza con cui le applicazioni client possono effettuare il polling di specifici endpoint API.
- I clienti hanno due mesi dopo il rilascio della versione 16.2.1 per implementare le modifiche di polling raccomandate nel loro codice. Durante questa finestra temporale, il sistema si limiterà a REGISTRARE gli eventi di soglia dell'intervallo di polling.
- Dopo dicembre 2025, i criteri di protezione del polling verranno impostati su APPLICA e gli errori inizieranno a essere attivati per gli utenti.
Il polling ad alta frequenza crea un carico non necessario sui sistemi backend, con conseguente degrado delle prestazioni e tempi di risposta più lenti. Gli sviluppatori di API sono incoraggiati a passare ai webhook per gli aggiornamenti in tempo reale.
Cosa cambia
Questo criterio di polling si applica a tutti gli GET endpoint API.
Esempi di endpoint interessati
Recupero dello stato:
- GET /agreements/{agreementId) – Recupera lo stato corrente di un accordo.
- GET /agreements/{agreementId)/documents/{documentId) – Recupera il flusso di file di un documento all'interno di un accordo.
Elenco:
- GET /agreements – Recupera gli accordi per l'utente.
- GET /agreements/{agreementId)/events – Recupera le informazioni sugli eventi per un accordo.
Viene applicato un limite alla frequenza con cui l'utente effettivo può effettuare la stessa chiamata API al servizio Acrobat Sign. Viene restituito un errore se la stessa chiamata viene effettuata entro l'intervallo minimo di polling dallo stesso utente effettivo.
Dettagli della politica di polling
- Intervallo minimo di polling degli oggetti (MOPI): L'MOPI predefinito varia a seconda del livello di servizio e dei tipi di applicazione:
- Applicazioni partner Acrobat Sign: L'MOPI per un'app partner è determinato dal livello dell'account dell'utente.
- Livello GLOBAL/ENTERPRISE: 3 chiamate per intervallo di un minuto
- Tutti gli altri livelli: 1 chiamata univoca per intervallo di dieci minuti
- Applicazioni cliente sotto account Global/Enterprise: Tre chiamate identiche per intervallo di un minuto.
- Applicazioni cliente sotto account sviluppatore: Una chiamata univoca per intervallo di 10 minuti.
- Applicazioni partner Acrobat Sign: L'MOPI per un'app partner è determinato dal livello dell'account dell'utente.
- Richieste duplicate all'interno di MOPI: Se lo stesso Utente effettivo effettua richieste get identiche (stesso percorso e intestazioni) più di quanto consentito dal proprio livello all'interno del MOPI, il sistema restituirà:
- Codice di stato 304 Non modificato per le richieste HTTP condizionali che utilizzano un ETag.
- Codice di stato 429 Troppe richieste con un retry-after per altre richieste.
- Gestione ETag: Questa politica si applica quando i valori ETag vengono forniti nell'intestazione If-None-Match per gli endpoint che già supportano 304 Non modificato .
Azione necessaria
Webhook: Se l'applicazione richiede aggiornamenti quasi in tempo reale, utilizza webhook invece del polling. I webhook offrono un modo più efficiente e scalabile per ricevere aggiornamenti tempestivi.
Se non è possibile implementare i webhook, le applicazioni devono implementare meccanismi di caching lato client per memorizzare e riutilizzare le risposte API. Quando si riceve una risposta 304 Non modificato, è necessario utilizzare i dati memorizzati nella cache invece di effettuare un'altra chiamata API.
I clienti hanno due mesi dopo il rilascio della versione 16.2.1 per implementare le modifiche di polling raccomandate nel loro codice. Durante questo periodo, il sistema REGISTRERÀ gli eventi di soglia dell'intervallo di polling.
Dopo dicembre 2025, i criteri di protezione del polling passeranno all'APPLICAZIONE e gli errori inizieranno a essere attivati per gli utenti.
Contatta il tuo CSM se hai bisogno di assistenza o hai domande.
L'ambiente sandbox attiverà il criterio di polling per REGISTRARE gli errori il 17 settembre 2025 e lo imposterà su APPLICAZIONE il 25 settembre 2025.
|
Prima segnalazione: agosto 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Per supportare i requisiti FedRAMP CSP, stiamo abilitando il protocollo IPv6 nel nostro ambiente Acrobat Sign for Government :
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Prima segnalazione: settembre 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
La convalida delle impostazioni della lingua è stata rafforzata durante la creazione di un accordo tramite API. Se le impostazioni locali di un accordo non sono consentite dalle politiche dell'account, l'API rifiuta la richiesta con un errore chiaro. Questo riduce le discrepanze linguistiche involontarie e mantiene le esperienze dei destinatari allineate con le impostazioni approvate.
Chi è interessato
- Account che impostano le impostazioni locali dell'accordo nelle richieste API.
- Account che limitano le impostazioni locali disponibili o non consentono modifiche alle impostazioni locali durante l'invio.
Cosa è cambiato
Quando l'impostazione DISPLAY_LOCALE_INFO_DURING_SEND è abilitata (livello GLOBAL), l'API applica:
- Le impostazioni locali dell'accordo devono essere incluse nelle AVAILABLE_LOCALES dell'Utente.
- Se ALLOW_LOCALE_SELECTION_DURING_SEND è falso, le impostazioni locali dell'accordo devono corrispondere all'AGREEMENT_LOCALE dell'Utente.
Le violazioni causano il fallimento di POST /agreements con: "Le impostazioni locali non sono valide o mancanti."
Errore comune e come risolverlo
Errore: "Le impostazioni locali non sono valide o mancanti."
- Controlla le impostazioni locali utilizzate nella richiesta API (ad esempio, en_US).
- Conferma che le impostazioni locali appaiano in AVAILABLE_LOCALES per l'Utente chiamante.
- Se ALLOW_LOCALE_SELECTION_DURING_SEND è falso, assicurati che le impostazioni locali della richiesta corrispondano ad AGREEMENT_LOCALE.
- Se è necessaria flessibilità tra le regioni, abilita la selezione delle impostazioni locali al momento dell'invio (vedi Azione richiesta).
Compatibilità con le versioni precedenti
- Prima di questa modifica, alcune richieste con impostazioni locali non corrispondenti potevano avere successo. Tali richieste ora falliscono con un errore chiaro quando le convalide non passano.
- Nessuna modifica allo schema API; il comportamento di convalida cambia solo quando DISPLAY_LOCALE_INFO_DURING_SEND è abilitato.
Azioni necessarie
Gli amministratori e gli integratori API dovrebbero fare una delle seguenti operazioni:
- Allineare le impostazioni locali nelle richieste API con AVAILABLE_LOCALES e, se ALLOW_LOCALE_SELECTION_DURING_SEND è falso, far corrispondere esattamente AGREEMENT_LOCALE
- Oppure -
- Consentire la selezione delle impostazioni locali al momento dell'invio impostando:
- ALLOW_LOCALE_SELECTION_DURING_SEND = vero
- CAN_CHANGE_UI_LOCALE = vero
|
Prima segnalazione: dicembre 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Adobe Acrobat Sign ruoterà il certificato SSL di Adobe Acrobat Sign il 7 gennaio 2026.
Azione necessaria
- Se hai integrazioni personalizzate con Acrobat Sign che utilizzano le API REST e se una di queste integrazioni ha 'bloccato' la chiave pubblica esistente, non è richiesta alcuna altra azione.
- Se stai utilizzando i certificati SSL di Acrobat Sign per SSO, o se stai bloccando il certificato stesso (o utilizzando altri metodi), puoi trovare i nuovi certificati SSL di Acrobat Sign nei requisiti di sistema di Adobe Acrobat Sign.
- Se la configurazione SSO supporta più certificati/catene di certificati pubbliche, si possono aggiungere subito i nuovi certificati e rimuovere dalla configurazione quelli precedenti dopo la sostituzione in gennaio.
- Se il tuo SSO non supporta più certificati/catene pubblici, dovrai sincronizzare il cambio SSL con Acrobat Sign il 7 gennaio 2026.
I nuovi certificati SSL saranno primario il 7 gennaio 2026.
|
Prima segnalazione: settembre 2024 - Aggiornamento: aprile 2025 |
Attuale |
|---|
L’infrastruttura Webhook 2.0 è stata implementata per tutta la clientela e, con il completamento di questa operazione, le notifiche per i firmatari sono state rimosse. Di conseguenza, il parametro webhookNotificationApplicableUsers del payload webhook non fornisce più dati utili e verrà rimosso da tutti i payload webhook.
L’ambiente sandbox verrà aggiornato nella versione di giugno.
Gli ambienti di produzione verranno aggiornati nella versione di luglio 2025.
L’ID utente e l’e-mail di invio possono essere trovati utilizzando i parametri initiatingUserId e initiatingUserEmail nel payload di notifica.