Esempio di codice Javascript per recuperare l’ID client, convalidarlo e quindi restituirlo nell’intestazione della risposta
- Installare il pacchetto
- Configurare il pacchetto
- Guida utente
- Abilitare l’autenticazione dell’identità digitale
- Guida per sviluppatori
- Guida alla personalizzazione avanzata
- Guida alla mappatura dei campi e ai modelli
- Guida utente dell’app per dispositivi mobili
- Guida all’automazione dei flussi
- Guida di Document Builder
- Configurare documenti di grandi dimensioni
- Guida all’aggiornamento
- Note sulla versione
- Domande frequenti
- Guida alla risoluzione dei problemi
- Articoli aggiuntivi
- Acrobat Sign per Microsoft 365
- Acrobat Sign per Outlook
- Acrobat Sign per Word/PowerPoint
- Acrobat Sign per Teams
- Acrobat Sign per Microsoft PowerApps e Power Automate
- Connettore Acrobat Sign per ricerca Microsoft
- Acrobat Sign per Microsoft Dynamics
-
Acrobat Sign per Microsoft SharePoint
- Panoramica
- SharePoint On-Prem: guida all’installazione
- SharePoint On-Prem: guida alla mappatura dei modelli
- SharePoint On-Prem: guida utente
- SharePoint On-Prem: note sulla versione
- SharePoint Online: guida all’installazione
- SharePoint Online: guida alla mappatura dei modelli
- SharePoint Online: guida utente
- SharePoint Online: guida alla mappatura dei moduli web
- SharePoint Online: note sulla versione
- Integrazioni di Adobe Acrobat Sign
- Versioni del prodotto e ciclo di vita
-
Acrobat Sign per Salesforce
- Installare il pacchetto
- Configurare il pacchetto
- Guida utente
- Abilitare l’autenticazione dell’identità digitale
- Guida per sviluppatori
- Guida alla personalizzazione avanzata
- Guida alla mappatura dei campi e ai modelli
- Guida utente dell’app per dispositivi mobili
- Guida all’automazione dei flussi
- Guida di Document Builder
- Configurare documenti di grandi dimensioni
- Guida all’aggiornamento
- Note sulla versione
- Domande frequenti
- Guida alla risoluzione dei problemi
- Articoli aggiuntivi
-
Acrobat Sign per Microsoft
- Acrobat Sign per Microsoft 365
- Acrobat Sign per Outlook
- Acrobat Sign per Word/PowerPoint
- Acrobat Sign per Teams
- Acrobat Sign per Microsoft PowerApps e Power Automate
- Connettore Acrobat Sign per ricerca Microsoft
- Acrobat Sign per Microsoft Dynamics
-
Acrobat Sign per Microsoft SharePoint
- Panoramica
- SharePoint On-Prem: guida all’installazione
- SharePoint On-Prem: guida alla mappatura dei modelli
- SharePoint On-Prem: guida utente
- SharePoint On-Prem: note sulla versione
- SharePoint Online: guida all’installazione
- SharePoint Online: guida alla mappatura dei modelli
- SharePoint Online: guida utente
- SharePoint Online: guida alla mappatura dei moduli web
- SharePoint Online: note sulla versione
- Acrobat Sign per ServiceNow
- Acrobat Sign per HR ServiceNow
- Acrobat Sign per SAP SuccessFactors
- Acrobat Sign per Workday
- Acrobat Sign per NetSuite
- Acrobat Sign per SugarCRM
- Acrobat Sign per VeevaVault
- Acrobat Sign per Coupa BSM Suite
- Acrobat Sign per Zapier
Panoramica
Un webhook è una richiesta HTTPS definita dall’utente che viene attivata quando si verifica un evento di abbonamento nel sito di origine (Adobe Acrobat Sign in questo caso).
In pratica, un webhook non è altro che un servizio REST che accetta dati o flussi di dati.
I webhook sono pensati per la comunicazione service-to-service in un Modello PUSH.
Quando viene attivato un evento di abbonamento, Acrobat Sign crea un POST HTTPS con un corpo JSON e lo invia all’URL specificato.
I webhook offrono numerosi vantaggi rispetto al precedente metodo di richiamata, tra cui:
- Gli amministratori possono abilitare i propri webhook senza dover coinvolgere il supporto di Acrobat Sign per indicare l’URL di richiamata
- I webhook sono migliori in termini di “freschezza” dei dati, efficienza della comunicazione e sicurezza. Nessuna votazione richiesta
- I webhook consentono facilmente diversi livelli di ambito (Account/Gruppo/Utente/Risorsa).
- I webhook sono una soluzione API più moderna, che consente una configurazione più semplice per applicazioni moderne
- È possibile configurare più webhook per ambito (Account/Gruppo/Utente/Risorsa) in cui le richiamate devono essere univoche.
- I webhook consentono di restituire la selezione dei dati, in cui le richiamate sono una soluzione “tutto o niente”
- È possibile configurare i metadati trasportati con un webhook (di base o dettagliato)
- I webhook sono molto più facili da creare, modificare o disabilitare in base alle esigenze, poiché l’interfaccia utente è interamente sotto il controllo dell’amministratore.
Questo documento è incentrato principalmente sull’interfaccia utente dei webhook nell’applicazione web Acrobat Sign (in precedenza Adobe Sign).
Gli sviluppatori alla ricerca di dettagli API possono trovare ulteriori informazioni qui:
Come utilizzare questa funzione
Gli amministratori dovranno prima disporre di un servizio webhook, in grado di accettare il push in entrata da Acrobat Sign. In merito, ci sono numerose opzioni e fino a quando il servizio può accettare richieste POST e GET, il webhook andrà a buon fine.
Una volta installato il servizio, un amministratore di Acrobat Sign può creare un nuovo webhook dall'interfaccia Webhook nel menu Account del sito Acrobat Sign.
Gli amministratori possono configurare il webhook per attivare gli eventi Accordo, Moduli Web (Widget) o Invio in modalità collettiva (MegaSign). La risorsa Modello libreria (Documento libreria) può anche essere configurata tramite l’API.
L’ambito del webhook può includere l’intero account o i singoli gruppi tramite l’interfaccia di amministrazione. L'API consente una maggiore granularità attraverso la selezione degli ambiti UTENTE o RISORSA.
Il tipo di dati che vengono inviati all’URL è configurabile e può includere informazioni sull’accordo, sul partecipante, sul documento e così via.
Una volta configurato e salvato il webhook, Acrobat Sign trasmetterà un nuovo oggetto JSON all’URL definito ogni volta che l’evento di abbonamento viene attivato. Non è necessaria alcuna modifica in corso del webhook, a meno che non si desideri modificare i criteri di attivazione dell’evento o il payload JSON.
Verifica dell’intento dell’URL del webhook
Prima di registrare correttamente un webhook, Acrobat Sign verifica che l’URL del webhook indicato nella richiesta di registrazione sia effettivamente in grado di ricevere notifiche. A questo scopo, quando Acrobat Sign riceve una nuova richiesta di registrazione del webhook, effettua prima una richiesta di verifica all’URL del webhook. Questa richiesta di verifica è un GET HTTPS inviato all'URL del webhook. Questa richiesta ha un'intestazione HTTP personalizzata X-AdobeSign-ClientId. Il valore in questa intestazione viene impostato sull’ID client (ID applicazione) dell’applicazione API che richiede di creare/registrare il webhook. Per registrare correttamente un webhook, il relativo URL deve rispondere a questa richiesta di verifica con un codice di risposta 2XX E, inoltre, DEVE restituire lo stesso valore di ID client in uno dei due modi seguenti:
- In un’intestazione di risposta X-AdobeSign-ClientId. Si tratta della stessa intestazione trasmessa nella richiesta, inclusa anche nella risposta.
- Oppure nel corpo della risposta JSON con chiave xAdobeSignClientId. Il suo valore corrisponde all’ID client inviato nella richiesta.
Il webhook sarà registrato correttamente solo su risposta corretta (codice di risposta 2XX) e convalida dell'ID client sia nell'intestazione che nel corpo della risposta. Lo scopo di questa richiesta di verifica è dimostrare che l’URL del webhook desidera effettivamente ricevere notifiche su tale URL. Se hai inserito involontariamente l’URL errato, questo non risponderà correttamente alla verifica della richiesta di intento e Acrobat Sign non invierà alcuna notifica a tale URL. Inoltre, l’URL del webhook può anche convalidare la ricezione di notifiche solo attraverso i webhook registrati da una specifica applicazione. Questo può essere fatto convalidando l’ID client dell’applicazione approvata nell'intestazione X-AdobeSign-ClientId. Se l’URL del webhook non riconosce l’ID client, NON DEVE rispondere con il codice di risposta positivo e Acrobat Sign farà in modo che l’URL non sia registrato come webhook.
La verifica della chiamata all’URL del webhook verrà effettuata nei seguenti casi:
- Registrazione webhook: se la verifica della chiamata all’URL del webhook ha esito negativo, il webhook non verrà creato.
- Aggiornamento webhook: da INATTIVO a ATTIVO: se la verifica della chiamata all’URL del webhook ha esito negativo, lo stato del webhook non verrà modificato in ATTIVO.
Come rispondere a una notifica webhook
Acrobat Sign esegue una verifica implicita dell’intento in ogni richiesta di notifica webhook inviata all’URL del webhook. Pertanto, ogni richiesta HTTPS di notifica webhook contiene anche l’intestazione HTTP personalizzata X-AdobeSign-ClientId. Il valore di questa intestazione è l’ID client (ID applicazione) dell’applicazione che ha creato il webhook. Considereremo l’avvenuto recapito della notifica webhook se, e solo se, viene restituita una risposta di esito positivo (codice di risposta 2XX) e viene inviato l’ID client nell’intestazione HTTP (X-AdobeSign-ClientId) oppure in un corpo della risposta JSON con chiave xAdobeSignClientId e con il valore dello stesso ID client. In caso contrario, riproveremo a recapitare la notifica all’URL del webhook fino a quando non saranno esauriti i tentativi.
Opzioni di configurazione
La configurazione del webhook richiede la definizione di cinque elementi:
- Nome: scegli un nome intuitivo che gli altri amministratori possano riconoscere facilmente.
- Ambito: ampiezza della rete che deve essere coperta dal webhook Nell’interfaccia sono disponibili gli ambiti Account e Gruppo.
- L’API supporta gli ambiti Account, Gruppo, Utente e Risorsa.
- È possibile definire un solo ambito per webhook.
- URL: l’URL di destinazione a cui Acrobat Sign ha trasmesso il payload JSON.
- Eventi: il trigger in risposta al quale Acrobat Sign genera il codice JSON e lo trasmette all’URL.
- Ogni evento crea un payload diverso relativo all’evento trigger.
- In un webhook si possono includere più Eventi.
- Parametri di notifica: la proprietà Parametri di notifica identifica le sezioni del payload dell’Evento JSON, consentendoti di selezionare solo le sezioni dell’Evento che sono importanti per questo webhook, riducendo così i dati non necessari inviati all’URL.
Una volta definito il webhook, fai clic su Salva: il nuovo webhook inizierà subito a reagire agli eventi trigger.
Configura l’URL del webhook affinché risponda alle richieste di verifica e notifica del webhook in base al protocollo di verifica descritto in precedenza. L’ID client (ID applicazione) che verrà inviato ai webhook creati dall’applicazione Web Acrobat Sign sarà - UB7E5BXCXY
Ambiti
- Account: tutti gli eventi di abbonamento che si verificano nell’account attivano il push.
- Gli amministratori degli account possono visualizzare tutti i webhook definiti per l’account e tutti i gruppi all’interno di quell’account.
- Gruppo: tutti gli eventi di abbonamento che si verificano in quel gruppo attivano il push. NOTA: I webhook con ambito di gruppo esistono solo per quel gruppo.
- Gli amministratori dei gruppi possono visualizzare solo i webhook del proprio gruppo. Non possono visualizzare i webhook a livello di account o associati ad altri gruppi.
- Gli account per i quali è attivata l’opzione Utenti in più gruppi visualizzeranno l’opzione per impostare il gruppo a cui deve essere applicato l’ambito.
- Account utente: tutti gli eventi di abbonamento per un account utente attivano il push. I webhook a livello di utente possono essere creati solo tramite API.
- Webhook a livello di risorsa: verrà creato per una risorsa specifica. Gli eventi specifici di questa risorsa verranno inviati all’URL del webhook. I webhook a livello di risorsa possono essere creati solo tramite API.
URL
Un URL webhook è un server che intercetta i messaggi di notifica HTTPS POST in entrata che vengono attivati quando si verificano eventi.
Per iscriversi al webhook degli eventi, è necessario questo URL.
- Il client deve includere un URL HTTPS dove Acrobat Sign può POST. Questo URL deve essere disponibile su Internet.
- Ad esempio, gli URI 127.0.0.1 e localhost non funzioneranno.
- L'endpoint dell’URL deve essere in ascolto sulla porta 443 o 8443 (deciso dal cliente durante la definizione dell’URL di richiamata).
- Assicurati che il webhook supporti le richieste POST per le notifiche degli eventi in arrivo e le richieste GET per la richiesta di verifica.
- L'URL non deve essere bloccato da un firewall.
Di seguito sono riportati gli eventi che possono attivare un push all’URL del webhook, raggruppati per oggetto ed elencati nell’ordine trovato nell’interfaccia utente.
Il valore a sinistra è il valore che verrà visualizzato nell’interfaccia utente di Acrobat Sign. Il valore a destra è il nome del webhook all’interno dell’API.
Per informazioni complete sui webhook e i relativi payload, consultare la Guida per sviluppatori di Acrobat Sign.
Gli accordi:
Elemento interfaccia utente | Nome webhook |
Tutti gli eventi dell’accordo | AGREEMENT_ALL |
Accordo creato | AGREEMENT_CREATED |
Accordo inviato | AGREEMENT_ACTION_REQUESTED |
Partecipante accordo completato | AGREEMENT_ACTION_COMPLETED |
Flusso di lavoro accordo completato | AGREEMENT_WORKFLOW_COMPLETED |
Accordo scaduto | AGREEMENT_EXPIRED |
Accordo eliminato | AGREEMENT_DOCUMENTS_DELETED |
Accordo annullato | AGREEMENT_RECALLED |
Accordo rifiutato | AGREEMENT_REJECTED |
Accordo condiviso | AGREEMENT_SHARED |
Accordo delegato | AGREEMENT_ACTION_DELEGATED |
Partecipante accordo sostituito | AGREEMENT_ACTION_REPLACED_SIGNER |
Accordo modificato | AGREEMENT_MODIFIED |
Modifica accordo confermata | AGREEMENT_USER_ACK_AGREEMENT_MODIFIED |
E-mail accordo visualizzata | AGREEMENT_EMAIL_VIEWED |
E-mail accordo non recapitata | AGREEMENT_EMAIL_BOUNCED |
Creazione dell’accordo non riuscita | AGREEMENT_AUTO_CANCELLED_CONVERSION_PROBLEM |
Accordo sincronizzato dopo evento offline | AGREEMENT_OFFLINE_SYNC |
Accordo caricato dal mittente | AGREEMENT_UPLOADED_BY_SENDER |
Accordo archiviato | AGREEMENT_VAULTED |
Identità social partecipante autenticata | AGREEMENT_WEB_IDENTITY_AUTHENTICATED |
Identità partecipante verificata da autenticazione KBA | AGREEMENT_KBA_AUTHENTICATED |
Promemoria accordo inviato | AGREEMENT_REMINDER_SENT |
Nome del firmatario dell’accordo modificato dal firmatario | AGREEMENT_SIGNER_NAME_CHANGED_BY_SIGNER |
Webhook degli accordi disponibili solo tramite API | |
N/A | AGREEMENT_EXPIRATION_UPDATED |
N/A |
AGREEMENT_READY_TO_NOTARIZE |
N/A |
AGREEMENT_READY_TO_VAULT |
Invia in modalità collettiva:
Elemento interfaccia utente | Nome webhook |
Invio in modalità collettiva - Tutti gli eventi | MEGASIGN_ALL |
Invio in modalità collettiva creato |
MEGASIGN_CREATED |
Invio in modalità collettiva condiviso |
MEGASIGN_SHARED |
Invio in modalità collettiva richiamato |
MEGASIGN_RECALLED |
Moduli Web:
Elemento interfaccia utente | Nome webhook |
Modulo web - Tutti gli eventi | WIDGET_ALL |
Modulo Web creato |
WIDGET_CREATED |
Modulo Web abilitato |
WIDGET_ENABLED |
Modulo Web disabilitato |
WIDGET_DISABLED |
Modulo Web modificato |
WIDGET_MODIFIED |
Modulo Web condiviso |
WIDGET_SHARED |
Creazione modulo Web non riuscita |
WIDGET_AUTO_CANCELLED_CONVERSION_PROBLEM |
Modelli libreria (solo API):
Elemento interfaccia utente | Nome webhook |
N/A | LIBRARY_DOCUMENT_ALL |
N/A | LIBRARY_DOCUMENT_CREATED |
N/A | LIBRARY_DOCUMENT_AUTO_CANCELLED_CONVERSION_PROBLEM |
N/A | LIBRARY_DOCUMENT_MODIFIED |
Parametri di notifica
I parametri di notifica consentono di personalizzare il payload JSON solo per elementi specifici dell’evento.
Ad esempio, in un evento di tipo Partecipante all’accordo sostituito, è possibile richiedere solo le proprietà Informazioni accordo e Informazioni partecipante, escludendo Informazioni documento e riducendo il volume totale del JSON nell’URL del webhook.
- Accordo
- Informazioni accordo: informazioni dettagliate in base allo stato dell’accordo al momento dell’evento di attivazione.
- Informazioni documento accordo: include tutte le informazioni sul documento generate a seguito dell’evento.
- Informazioni sul partecipante all’accordo: include le informazioni sui partecipanti risultanti dall’evento.
- Documento accordo firmato: fornisce il PDF firmato.
- Applicabile agli eventi Flusso di lavoro degli accordi completato e Tutti gli accordi.
- Invia in modalità collettiva
- Invia in modalità collettiva: informazioni dettagliate sull’oggetto Invia in modalità collettiva che ha attivato l’evento.
- Modulo web
- Informazioni sul widget: informazioni dettagliate sul modulo web che ha attivato l’evento.
- Widget informazioni documento: informazioni sul documento associate al modello di modulo web.
- Widget informazioni partecipante: informazioni sui partecipanti definiti nel modello di modulo web.
Autenticazione SSL bidirezionale
L’SSL bidirezionale, spesso chiamato Client-Side SSL, o TLS reciproco, è una modalità SSL in cui sia il server che il client (browser Web) emettono certificati per identificare se stessi.
Gli amministratori dell’account possono configurare un certificato lato client sulla pagina Impostazioni di sicurezza.
Acrobat Sign verifica i certificati SSL durante la distribuzione dei payload nell’URL del webhook. I webhook che non superano la verifica del certificato SSL non consegnano correttamente il payload JSON.
Utilizza l’SSL bidirezionale per autenticare il client (Acrobat Sign) e il servizio di ascolto per garantire che solo Acrobat Sign possa raggiungere l’URL del webhook.
Se il webhook è stato creato da un’applicazione partner, utilizzerà un certificato client (se disponibile) dall’account di tale applicazione per identificarsi quando invia notifiche al webhook.
Di seguito sono riportate le domande più comuni relative sia al processo di verifica del server Web che alla verifica della certificazione client.
Verifica del server Web
Durante la registrazione di un webhook, Acrobat Sign verifica l’URL del server webhook.
I clienti non potranno registrare il webhook se la connessione all’URL di richiamata del webhook non può essere completata da Acrobat Sign.
Verifica dei certificati client
Attivazione e disattivazione
L’accesso alla funzione Webhook è attivato per impostazione predefinita per gli account dei piani Enterprise.
Gli amministratori a livello di gruppo possono creare/controllare i webhook che operano solo all’interno del proprio gruppo.
L’accesso alla pagina Webhook si trova nella barra a sinistra del menu Amministratore: Account > Webhook
Attivare un webhook
Quando un webhook viene creato per la prima volta, viene creato in uno stato Attivo.
Nella pagina Webhook in Acrobat Sign, per impostazione predefinita vengono visualizzati i webhook attivi.
Per attivare un webhook inattivo:
- Fai clic sull’icona Opzioni (tre linee orizzontali) a destra della riga di intestazione dei webhook e seleziona Mostra tutti i webhook
- Fai un solo clic sul webhook intattivo per selezionarlo.
- In questo modo vengono visualizzate appena sotto l’intestazione le opzioni per il webhook
- Fai clic su Attiva
Il webhook attivo inizierà a inviare dati all’URL di destinazione non appena viene attivato l’evento successivo.
Disattivare un webhook
Per disattivare un webhook è sufficiente
- Passare alla pagina Webhooks
- Fare un solo clic sul webhook da disattivare
- Selezionare Disattiva dalle voci di menu sotto la riga di intestazione
- Una volta disattivato, il webhook mostra lo stato di Inattivo
Visualizzare o modificare un webhook
I webhook possono essere modificati e salvati in qualsiasi momento e, dopo aver salvato una nuova configurazione, la modifica ha effetto immediato.
Solo Eventi e Parametri di notifica possono essere modificati.
Per cambiare Nome, Ambito o URL è necessario creare un nuovo webhook.
Per modificare i parametri di un webhook:
- Passare alla pagina Webhooks
- Fare un solo clic sul webhook da modificare
- Fare clic sull’opzione Visualizza/Modifica sotto la riga di intestazione
- Applica le modifiche necessarie e fai clic su Salva
Eliminare un webhook
Un webhook può essere eliminato in qualsiasi momento.
L’eliminazione di un webhook lo distrugge nel sistema, quindi non è possibile recuperare un webhook eliminato.
I webhook non devono essere disattivati per primi.
Per eliminare un webhook:
- Passare a Webhook
- Selezionare il webhook da eliminare facendo un solo clic su di esso
- Fare clic sull’opzione Elimina sotto la riga di intestazione
- Viene presentata una richiesta di conferma dell’eliminazione del webhook. fare clic su OK
Best practice
- Per limitare il numero di richieste HTTPS al server, puoi abbonarti a specifici eventi: più specifici sono i webhook, meno volume sarà necessario esaminare.
- Resistente ai duplicati: se disponi di più app che condividono lo stesso URL del webhook e lo stesso utente è mappato su ciascuna app, lo stesso evento verrà inviato al webhook più volte (una volta per app). In alcuni casi, il webhook potrebbe ricevere eventi duplicati. L’applicazione webhook deve essere tollerante e deduplicata per ID evento.
- Rispondi sempre rapidamente ai webhook: l’app ha solo cinque secondi per rispondere alle richieste di webhook. Per la richiesta di verifica, questo è raramente un problema, poiché l’app non deve eseguire alcun lavoro reale per rispondere. Per le richieste di notifica, tuttavia, l’app solitamente esegue un’operazione che richiede tempo per rispondere alla richiesta. Si consiglia di lavorare su un thread separato o in modo asincrono utilizzando una coda per garantire una risposta entro cinque secondi
- Gestire la concomitanza: quando un utente apporta una serie di modifiche in rapida successione, è probabile che l’app riceva più notifiche per lo stesso utente più o meno nello stesso momento. Se non presti attenzione a come gestisci la concomitanza, l’app potrebbe elaborare le stesse modifiche per lo stesso utente più di una volta. Per sfruttare i webhook di Acrobat Sign, è necessario comprendere chiaramente l’utilizzo delle informazioni. Assicurati di porre domande quali:
- Quali dati desideri restituire nel payload?
- Chi accederà a queste informazioni?
- Quali decisioni o rapporti verranno generati?
- Raccomandazioni per la ricezione di un documento firmato: quando si determina come ricevere un PDF firmato da Acrobat Sign nel sistema di gestione dei documenti, è necessario considerare diversi fattori.
Anche se è perfettamente accettabile selezionare solo il Documento accordo firmato durante la creazione di un webhook, è possibile valutare l’utilizzo dell’API di Acrobat Sign per recuperare i documenti quando viene ricevuto un evento di attivazione (ad esempio, lo stato dell’accordo Completo).
Aspetti da considerare...
Limitazione della dimensione JSON
La dimensione del payload JSON è limitata a 10 MB.
Nel caso in cui un evento generi un payload più grande, verrà attivato un webhook, ma gli attributi dei parametri condizionali, se presenti nella richiesta, vengono rimossi per ridurre le dimensioni del payload.
Se questo si verifica, la risposta presenta “ConditionalParametersTrimmed” per informare che le informazioni conditionalParameters sono state rimosse.
“conditionalParametersTrimmed” è un oggetto array contenente informazioni sulle chiavi che sono state tagliate.
Il troncamento verrà eseguito nel seguente ordine:
- includeSignedDocuments
- includeParticipantsInfo
- includeDocumentsInfo
- includeDetailedInfo
I documenti firmati verranno troncati per primi, seguiti da informazioni sul partecipante, informazioni sul documento e, infine, informazioni dettagliate.
Questo può accadere, ad esempio, in un evento di completamento dell’accordo che include un documento firmato (codificato in base 64) o in un accordo con più campi modulo.
Notifiche webhook
I webhook di Acrobat Sign forniscono notifiche applicabili a tutti i partecipanti di un accordo se è configurato un webhook per tale utente, il suo gruppo o il suo account.
Gli eventi dell’accordo vengono elaborati in modo che, se è presente un webhook configurato per il partecipante applicabile all’evento, viene inviata una notifica all’URL del webhook. In altre parole, i webhook vengono attivati per gli eventi in tutti gli accordi applicabili, anche quelli esterni al gruppo o all’account in cui è configurato il webhook.
Le notifiche vengono inviate solo per gli eventi in cui è coinvolto il partecipante. Ad esempio, la proprietà Mittente di un accordo riceve quasi tutte le notifiche, mentre i Destinatari riceveranno notifiche solo dall’inizio del loro coinvolgimento nell’accordo e solo per gli eventi in cui sono coinvolti.
Le notifiche webhook seguono il modello di autenticazione e visibilità corrente di Acrobat Sign stesso, il che significa che gli utenti avranno accesso all’accordo solo una volta iniziata la loro partecipazione a un accordo.
Riprova quando il servizio di ascolto non è attivo
Se l’URL di destinazione per il webhook è inattivo per qualsiasi motivo, Acrobat Sign mette in coda il codice JSON e tenta di inviarlo di nuovo in un ciclo progressivo di 72 ore.
Gli eventi non consegnati vengono mantenuti in una coda di tentativi e nelle successive 72 ore verrà fatto il possibile per inviare le notifiche nell’ordine in cui si sono verificate.
La strategia di ripetere i tentativi di consegna delle notifiche prevede il raddoppiamento del tempo tra tentativi successivi, a partire da un intervallo di 1 minuto che aumenta fino a 12 ore, per un totale di 15 tentativi nell’arco di 72 ore.
Se il ricevitore del webhook non risponde entro 72 ore e negli ultimi sette giorni non sono state inviate notifiche, il webhook verrà disabilitato. Non verrà inviata alcuna notifica a questo URL finché il webhook non sarà nuovamente attivato.
Tutte le notifiche tra il momento in cui il webhook viene disattivato e successivamente riattivato verranno perse.