Eksempel på Javascript-kode for å hente klient-ID-en, validere den og så returnere den i svarhodet
Sist oppdatert
8. jul. 2026
Overblikk
En webhook er en brukerdefinert HTTPS-forespørsel som utløses når en bestemt hendelse oppstår på kildeområdet (Adobe Acrobat Sign i dette tilfellet).
En webhook er ikke mer enn en REST-tjeneste som aksepterer data eller en datastrøm.
Webhooks er ment for service-til-service-kommunikasjon i en PUSH-modell.
Når en abonnert hendelse oppstår, konstruerer Acrobat Sign en HTTPS POST med en JSON-tekst og leverer den til den angitte nettadressen.
Før du konfigurerer webhooks, må du kontrollere at nettverket ditt godtar IP-områdene som kreves for funksjonaliteten.
Webhooks tilbyr flere fordeler i forhold til den forrige tilbakekallingsmetoden. Noen av disse er:
- Administratorer kan aktivere sine egne webhooks uten å måtte involvere Acrobat Sign-støtte for å vise nettadressen for tilbakekall
- Webhooks er bedre når det gjelder «dataferskhet», effektiviteten i kommunikasjon og sikkerhet. Ingen avspørring påkrevd
- Webhooks tillater enkel ulike nivåer av omfang (konto/gruppe/bruker/ressurs).
- Webhooks er en mer moderne API-løsning, som muliggjør enklere konfigurasjon av moderne programmer
- Flere webhooks kan konfigureres per område (konto/gruppe/bruker/ressurs), der tilbakeringinger måtte være unike
- Webhooks gjør det mulig å velge dataene som skal returneres, der tilbakekall er en «alt eller ingenting»-løsning
- Metadata som bæres med en webhook kan konfigureres (grunnleggende eller detaljert)
- Webhooks er langt enklere å opprette, redigere eller deaktivere etter behov, siden brukergrensesnittet er fullstendig under administratorens kontroll.
Notat
Dette dokumentet er primært fokusert på Webhooks-grensesnittet i Acrobat Sign-webprogrammet (tidligere Adobe Sign).
Utviklere som ser etter API-detaljer, kan finne mer informasjon her:
Forutsetninger
Du må tillate IP-områdene for webhooks gjennom nettverkssikkerheten din for at tjenesten skal fungere.
Den eldre tjenesten for tilbakekall av nettadresse i REST v5 bruker de samme IP-områdene som webhook-tjenesten.
Administratorer kan logge på Adobe Admin Console for å legge til brukere. Når du er logget på, går du til administratormenyen og ruller ned til Webhooks.
Slik brukes det
Administratorer må først ha en webhook-tjeneste, klar til å godta innkommende push fra Acrobat Sign. Det er mange alternativer i denne forbindelse, og så lenge tjenesten kan godta POST- og GET-forespørsler, vil webhooken være vellykket.
Når tjenesten er på plass, kan en Acrobat Sign-administrator opprette en ny webhook fra Webhook-grensesnittet i Konto-menyen på Acrobat Sign-området.
Administratorer kan konfigurere webhooken til å utløse for avtale-, webskjema- (Widget) eller send samlet- (MegaSign) hendelser. Ressursen for bibliotekmal (biblioteksdokument) kan også konfigureres via API-en.
Omfanget av webhooken kan inkludere hele kontoen eller individuelle grupper gjennom administratorgrensesnittet. API-en gir mer detaljer ved valg av BRUKER- eller RESSURS-omfang.
Datatypen som pushes til nettadressen, kan konfigureres og kan inkludere ting som avtaleinformasjon, deltakerinformasjon, dokumentinformasjon og så videre.
Når webhooken er konfigurert og lagret, vil Acrobat Sign pushe et nytt JSON-objekt til den definerte nettadressen hver gang den abonnerte hendelsen er utløst. Ingen pågående manipulering av webhooken er nødvendig med mindre du vil endre hendelsesutløserkriteriene eller JSON-nyttelasten.
Bekreftelse av hensikten med webhook-URL-adressen
Før en webhook registreres, bekrefter Acrobat Sign om webhook-nettadressen som er angitt i registreringsforespørselen har til hensikt å motta varsler eller ikke. For dette formålet, når Acrobat Sign mottar en ny webhook-registreringsforespørsel, sender den først en bekreftelsesforespørsel til webhook-nettadressen. Denne bekreftelsesforespørselen er en HTTPS GET-forespørsel sendt til webhook-URL-adressen. Denne forespørselen har en tilpasset HTTP-topptekst X-AdobeSign-ClientId. Verdien i denne toppteksten er satt til klient-ID (program-ID) for API-programmet som forespør å opprette/registrere webhooken. For å lykkes med å registrere en webhook svarer webhook-nettadressen på denne bekreftelsesforespørselen med en 2XX-svarkode OG den MÅ dessuten sende tilbake samme klient-ID-verdi på én av følgende to måter:
- Enten i et svarhode X-AdobeSign-ClientId. Dette er den samme toppteksten som sendes i forespørselen, og blir gjentatt i svaret.
- Eller i JSON-svarteksten med nøkkelen til xAdobeSignClientId og tilhørende verdi er den samme klient-ID-en som sendes i forespørselen.
Webhooken vil bare bli registrert på et vellykket svar (2XX svarkode) og validering av klient-ID enten i toppteksten eller svarteksten. Hensikten med denne bekreftelsesforespørselen er å vise at webhook-nettadressen din virkelig ønsker å motta varsler på den nettadressen. Hvis du ved et uhell skrev inn feil nettadresse, vil nettadressen ikke svare riktig på bekreftelsen av hensiktsforespørselen, og Acrobat Sign vil ikke sende noen varsler til den nettadressen. I tillegg kan webhook-nettadressen også bekrefte at den bare vil motta varsler gjennom webhookene som er registrert av et bestemt program. Dette kan gjøres ved å validere klient-ID-en for programmet som er sendt i X-AdobeSign-ClientId-hodet. Hvis webhook-nettadressen ikke gjenkjenner klient-ID-en, MÅ DEN IKKE svare med suksessresponskoden, og Acrobat Sign vil sørge for at nettadressen ikke er registrert som en webhook.
Verifisering av webhook-nettadressekall vil bli foretatt i følgende scenarier:
- Registrerer Webhook: Hvis denne verifiseringen av webhook-nettadressekall mislykkes, blir ikke webhooken opprettet.
- Oppdaterer Webhook: INAKTIV til AKTIV: Hvis denne bekreftelsen av webhook-nettadressekall mislykkes, endres ikke webhook-tilstanden til AKTIV.
Slik svarer du på et webhook-varsel
Acrobat Sign utfører en implisitt intensjonsbekreftelse i hver webhook-varslingsforespørsel som sendes til webhook-nettadressen. Dermed inneholder hver webhook-varsling HTTPS-forespørsel også det egendefinerte HTTP-hodet kalt X-AdobeSign-ClientId. Verdien av denne overskriften er klient-IDen (Applikasjon-ID) til applikasjonen der webhooken ble opprettet. Vi vil vurdere webhook-varselet levert hvis, og bare hvis et vellykket svar (2XX svarkode) returneres og klient-ID-en sendes enten i HTTP-toppteksten (X-AdobeSign-ClientId) eller i en JSON-responstekst med nøkkelen som xAdobeSignClientId og verdi som samme klient-ID, ellers vil vi prøve å levere varselet til webhook-nettadressen til forsøkene er utløpt.
Som nevnt ovenfor bør overskriften 'X-AdobeSign-ClientId' som er inkludert i hver varslingsforespørsel fra Sign, verdien for denne overskriften (klient-ID) gjentas som svar på to måter:
1. HTTP-header X-AdobeSign-ClientId og verdi som denne klient-ID-en
|
|
|---|
|
// Hent klient-ID var clientid = request.headers['X-ADOBESIGN-CLIENTID'];
//Valider den if (clientid ==="BGBQIIE7H253K6") //Erstatt 'BGBQIIE7H253K6' med klient-ID-en til programmet der webhooken opprettes { //Returner den i svarhode response.headers['X-AdobeSign-ClientId'] = clientid; response.status = 200; // standardverdi } |
|
Eksempel PHP-kode for å hente klient-IDen, validere den og så returnere den i svarhodet |
|---|
|
<?php // Hent klient-ID $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Valider den if($clientid == "BGBQIIE7H253K6") //Erstatt 'BGBQIIE7H253K6' med klient-ID-en til programmet der webhooken opprettes { //Returner den i svarhode header("X-AdobeSign-ClientId:$clientid"); header("HTTP/1.1 200 OK"); // standardverdi } ?> |
2. JSON-responstekst med nøkkel som xAdobeSignClientId og verdi som samme klient-ID
|
Eksempel på Javascript-kode for å hente klient-ID-en, validere den og returnere den i svarteksten |
|---|
|
// Hent klient-ID var clientid = request.headers['X-ADOBESIGN-CLIENTID'];
//Valider den if (clientid ==="BGBQIIE7H253K6") //Erstatt 'BGBQIIE7H253K6' med klient-ID-en til programmet der webhooken opprettes { var responseBody = { "xAdobeSignClientId" : clientid // Returner klient-ID i brødteksten }; response.headers['Content-Type'] = 'application/json'; response.body = responseBody; response.status = 200; } |
|
Eksempel PHP-kode for å hente klient-IDen, validere den og returnere den i svarteksten |
|---|
|
<?php // Hent klient-ID $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Valider den if($clientid == "BGBQIIE7H253K6") //Erstatt 'BGBQIIE7H253K6' med klient-ID-en til programmet der webhooken opprettes { //Returner den som svartekst header("Content-Type: application/json"); $body = array('xAdobeSignClientId' => $clientid); echo json_encode($body); header("HTTP/1.1 200 OK"); // standardverdi } ?> |
|
Eksempel på JSON-kroppen i responsen |
|---|
|
{ "xAdobeSignClientId": "BGBQIIE7H253K6" } |
Forutsetninger
Du trenger:
- En Microsoft-konto med lisens til å opprette Azure-funksjonsprogrammer
- Et eksisterende Azure-funksjonsprogram, du kan opprette et ved hjelp av https://docs.microsoft.com/nb-no/azure/azure-functions/functions-create-first-azure-function
- Grunnleggende kunnskap om Javascript, slik at du kan forstå og skrive koden på et hvilket som helst språk du ønsker
Trinn for å opprette en Azure Functions Trigger som fungerer som en Acrobat Sign webhook
For å opprette en Javascript HTTP-utløserfunksjon:
1. Logg inn via din Microsoft-konto https://portal.azure.com/
2. Åpne Azure-funksjonsapplikasjon som vises under kategorien Funksjonsprogrammer.
Dette vil åpne listen over Azure-funksjonsprogrammer:
3. Velg applikasjonen hvor du vil opprette denne nye funksjonen.
4. Klikk på Opprett (+)-knappen for å opprette en ny Azure-funksjon
5. Velg Webhook + API som scenario og Javascript som språk
6. Klikk på Opprett denne funksjonen
Det opprettes en ny funksjon som har mulighet til å håndtere en innkommende API-forespørsel.
Legg til logikk for å registrere Acrobat Sign webhook
Før en webhook registreres, bekrefter Acrobat Sign at webhook-URL-adressen som er angitt i registreringsforespørselen, virkelig har til hensikt å motta varsler eller ikke. For dette formålet, når en ny webhook-registreringsforespørsel mottas av Acrobat Sign, sender den først en bekreftelsesforespørsel til webhook-nettadressen. Denne bekreftelsesforespørselen er en HTTPS GET-forespørsel sendt til webhook-URL-adressen med et tilpasset HTTP-hode X-AdobeSign-ClientId. Verdien i denne overskriften settes til klient-ID for applikasjonen som ber om å opprette/registrere webhook. For å lykkes med å registrere en webhook svarer webhook-URL-adressen på denne bekreftelsesforespørselen med en 2XX-svarkode, OG kan dessuten sende tilbake samme klient-ID-verdi på én av følgende to måter.
Det er to alternativer du kan følge:
Alternativ 1: Send klient-ID i X-AdobeSign-ClientId som svarhode
Send X-AdobeSign-ClientId i svarhodet. Det er det samme hodet som sendes i forespørselen, og det må bli gjentatt i svaret.
Erstatt Index.js-filen med følgende:
module.exports = function (context, req) {
var clientId = req.headers['x-adobesign-clientid'];
// Bekreft at den innkommende klient-ID-en er ekte
if (clientId === '123XXX456') {
context.res = {
// status: 200, /* Standard er 200 */ // hvilket som helst 2XX-svar er akseptabelt
body: "Varsel godtatt",
headers : {
'x-adobesign-clientid' : req.headers['x-adobesign-clientid']
}
};
}
else {
context.res = {
status: 400,
body: "Oi!! Ugyldig oppkall identifisert"
};
}
context.done();
};
Test adferden ved å etterligne anmodningen:
1. Klikk på Test-knappen ytterst i høyre hjørne
2. Etterligne dummy-forespørselen
Selv om svarhoder ikke vises ovenfor, men du kan observere det ved å etterligne det med postman/DHC eller en annen tjeneste.
Alternativ 2: Send klient-ID i svarteksten med nøkkelen xAdobeSignClientId
I JSON-svarteksten med nøkkelen xAdobeSignClientId og tilhørende verdi som er den samme klient-ID-en som sendes i forespørselen.
Erstatt Index.js-filen med følgende:
module.exports = function (context, req) {
var clientId = req.headers['x-adobesign-clientid'];
// Bekreft at den innkommende klient-ID-en er ekte
if (clientId === '123XXX456') {
context.res = {
// status: 200, /* Standard er 200 */ // hvilket som helst 2XX-svar er akseptabelt
body: {
'xAdobeSignClientId' : clientId
},
headers : {
'Content-Type' : 'application/json'
}
};
}
else {
context.res = {
status: 400,
body: "Oi!! Ugyldig oppkall identifisert"
};
}
context.done();
};
Test oppførselen ved å etterligne forespørselen
1. Klikk på Test-knappen ytterst i høyre hjørne
2. Etterligne dummy-forespørselen
Vær også oppmerksom på at samme atferd for klient-ID forventes når Webhook-URL-en mottar POST-varsler.
Klar til bruk
Når du har bekreftet atferden, fungerer webhook-URL-adressen i henhold til Acrobat Sign-standardene. Du kan videre oppdatere den egendefinerte logikken i henhold til dine krav.
Hent funksjonens URL-adresse
- Klikk på Hent funksjon-URL
Kopier URL-adressen og bruk den til å opprette webhooks i Acrobat Sign.
Opprette AWS Lambda-funksjonen
Hvis du vil opprette en AWS Lambda-funksjon, logger du på AWS Management Console og velger AWS Lambda-tjenesten fra tjenestelisten.
- Klikk på Opprett en Lambda-funksjon ved hjelp av «Forfatt fra bunnen av»-alternativet
- På siden Konfigurer funksjon angir du funksjonsnavnet «lambdaWebhooks» og velger Node.js 4.3 som kjøretid
- For rollen velger du en eksisterende rolle eller opprett en ny rolle fra mal(er)
- Hvis du har valgt Opprett ny rolle fra mal(er), skriver du inn et rollenavn (f.eks. rolle-lamda) og velger Simple Microservices-tillatelser fra Policymaler-listen
- Klikk på Opprett funksjon-knappen
- På den nye AWS lamda-funksjonssiden velger du «Rediger innebygd kode»som «Kodeoppføringstype», beholder du indeksbehandleren som Behandler.
- Legg til logikk for å registrere Acrobat Sign-webhooken
Før en webhook registreres, bekrefter Acrobat Sign at webhook-URL-adressen som er angitt i registreringsforespørselen, virkelig har til hensikt å motta varsler eller ikke. For dette formålet, når en ny webhook-registreringsforespørsel mottas av Acrobat Sign, sender den først en bekreftelsesforespørsel til webhook-nettadressen. Denne bekreftelsesforespørselen er en HTTPS GET-forespørsel sendt til webhook-URL-adressen med et tilpasset HTTP-hode X-AdobeSign-ClientId. Verdien i denne overskriften settes til klient-ID for applikasjonen som ber om å opprette/registrere webhook. For å lykkes med å registrere en webhook svarer webhook-URL-adressen på denne bekreftelsesforespørselen med en 2XX-svarkode, OG kan dessuten sende tilbake samme klient-ID-verdi på én av følgende to måter.Vær også oppmerksom på at samme atferd for klient-ID forventes når Webhook-URL-en mottar POST-varsler.
Følg en av de to sakene:
Sak 1: Send klient-ID i X-AdobeSign-ClientId som svarhode
- Send X-AdobeSign-ClientId i svarhodet. Det er det samme hodet som sendes i forespørselen, og det må bli gjentatt i svaret.
Kodebiten
I index.js-filen erstatter du den automatisk genererte kodebiten med følgende kode:
- Send X-AdobeSign-ClientId i svarhodet. Det er det samme hodet som sendes i forespørselen, og det må bli gjentatt i svaret.
|
Eksempelnode JS-kode for å hente klient-ID-en, validere den og deretter returnere den i svarhodet |
|---|
|
exports.handler = function index(event, context, callback) { // Hent klient-ID var clientid = event.headers['X-AdobeSign-ClientId'];
//Valider den if (clientid =="BGBQIIE7H253K6") //Erstatt 'BGBQIIE7H253K6' med klient-ID-en til programmet der webhooken opprettes { var response = { statusCode: 200, headers: { "X-AdobeSign-ClientId": clientid } }; callback(null,response); } else { callback("Oi!! illegitimate call"); } } |
Tilfelle 2: Pass klient-ID i svarteksten med nøkkelen xAdobeSignClientId
I JSON-svarteksten med nøkkelen xAdobeSignClientId og tilhørende verdi med den samme klient-ID-en som sendes i forespørseltoppteksten.
Kodesnutt
Erstatt Index.js-filen med følgende :
|
Eksempelnode JS-kode for å hente klient-ID-en, validere den og deretter returnere den i svarhodet |
|---|
|
exports.handler = function index(event, context, callback) { // Hent klient-ID var clientid = event.headers['X-AdobeSign-ClientId'];
//Valider den if (clientid =="BGBQIIE7H253K6") //Erstatt 'BGBQIIE7H253K6' med klient-ID-en til programmet der webhooken opprettes { var responseBody = { xAdobeSignClientId : clientid };
var response = { statusCode: 200, body: JSON.stringify(responseBody) };
callback(null,response); } else { callback("Oi!! illegitimate call"); } } |
- Lagre funksjonen. Lambda-funksjonen er opprettet, og vi er nesten klar til å bruke den i en sanntids webhook.
Konfigurere AWS API Gateway
For å gjøre denne Lambda offentlig tilgjengelig gjennom en HTTP-metode, må vi konfigurere AWS API Gateway ved hjelp av vår funksjon (opprettet ovenfor) som serverenden for API.
I AWS Management Console velger du API Gateway fra AWS-tjenestene og klikker på Opprett API-knappen
- På siden Opprett nytt API velger du Nytt API og angir webhooks som API-navn.
- Klikk på Opprett API-knappen
- Velg rullegardinlisten Handlinger og velg alternativet Opprett ressurs
- Merk av for alternativet Konfigurer som proxy-ressurs og angi valider som ressursnavn og {proxy+} i ressursbanen
- La alternativet Aktiver API Gateway CORS være umarkert og klikk på knappen Opprett ressurs
- Hold Lambda-funksjonsproxyen valgt som integrasjonstype og velg regionen der du har opprettet Lambda-funksjonen i rullegardinlisten for Lambda-regionen (sannsynligvis er det den samme regionen der du oppretter API-gatewayen).
- Angi valider som Lambda-funksjonen og klikk på Lagre-knappen
- I popup-vinduet Legg til tillatelse til Lambda-funksjon, velger du OK
Hvis alle trinnene ovenfor blir utført, ser du noe som dette:
Distribuerer API
Neste trinn er å distribuere dette API-et slik at det blir klart til bruk.
- I rullegardinmenyen Handlinger, velger du Distribuer API
- Velg [Nytt trinn] i distribusjonstrinnet og angi prod (eller det du vil identifisere dette trinnet som) i fasenavnet
- Klikk på Bruk-knappen
API er nå klart til bruk, og du kan finne start-nettadressen i den blå boksen som vist nedenfor:
Legg merke til denne nettadressen fordi du må oppgi den som nettadressen din i sanntid.
Klar til bruk
Det er gjort. Bruk denne nettadressen ovenfor med «/{nodeJSfunctionName}» vedlagt som webhook-nettadresse i POST /webhooks API-forespørsel. Når du har bekreftet atferden, fungerer Webhook-nettadressen i henhold til
Acrobat Sign-standarder. Du kan videre oppdatere/legge til den egendefinerte logikken i henhold til ditt krav.
Hvordan aktivere eller deaktivere
Tilgang til Webhook-funksjonen er aktivert som standard for kontoer på Enterprise-nivå.
Administratorer på gruppenivå kan opprette/kontrollere webhook som bare opererer i gruppen.
Tilgang til Webhook-siden finnes på venstre side av Administrator-menyen.
Samtidighetsbasert prisbegrensning
Webhook-opprettings- og varslingshendelser (og tilbakekall) er begrenset i antallet samtidige varsler som aktivt leveres til kunden fra Acrobat Sign-systemet. Denne grensen gjelder for kontoen, slik at den inkluderer alle grupper innenfor kontoen.
Denne typen hastighetsbegrensning forhindrer at en dårlig utformet konto konsumerer en uforholdsmessig stor mengde serverressurser, og påvirker dermed alle andre kunder i det servermiljøet negativt.
Antallet samtidige hendelser per konto er beregnet for å sikre at kontoer med velfungerende webhook mottar varslene sine på kortest mulig tid, og sjelden vil møte en situasjon der varsler blir forsinket på grunn av for mange forespørsler. Gjeldende grenseverdier er:
|
Handling |
Maksimum |
Beskrivelse |
|
Opprette webhook |
10 |
På det meste er 10 samtidige forespørsler om webhook-opprettelse er tillatt per konto. |
|
Webhook/tilbakeringingsvarsel |
30 |
Maksimalt 30 samtidige webhook- og tilbakeringingsvarsler er tillatt per konto. |
Anbefalte fremgangsmåter
- Abonner på spesifikke, nødvendige hendelser for å begrense antall HTTPS-forespørsler til serveren – desto mer spesifikk du kan gjøre webhooks, desto mindre volum må du bla gjennom.
- Vær motstandsdyktig mot duplikater – hvis du har mer enn én app som deler samme nettadresse og samme bruker som er tilordnet hver app, blir den samme hendelsen sendt til nettadressen flere ganger (én gang per app). I noen tilfeller kan webhooken din motta dupliserte hendelser. Webhook-applikasjonen din bør være tolerant for dette og trekke fra med hendelses-ID.
- Svar alltid raskt på webhooks – appen din har bare ti sekunder på seg til å svare på webhook-forespørsler. Når det gjelder bekreftelsesforespørselen er dette sjelden et problem, siden appen din ikke trenger å gjøre noe ordentlig arbeid for å svare. For varslingsforespørsler vil imidlertid appen vanligvis gjøre noe som tar tid som svar på forespørselen. Det anbefales å arbeide på en separat tråd eller asynkront ved hjelp av en kø for å sikre at du kan svare innen fem sekunder
- Administrer samtidighet – når en bruker gjør en rekke endringer i rask rekkefølge, vil appen sannsynligvis motta flere varsler for samme bruker omtrent samtidig. Hvis du ikke er forsiktig med hvordan du administrerer samtidighet, kan det ende med at appen din behandler de samme endringene for samme bruker mer enn én gang. For å kunne dra nytte av webhooks for Acrobat Sign, må en klar forståelse av bruken av informasjonen forstås. Sørg for å stille spørsmål som:
- Hvilke data vil du returnere i nyttelasten?
- Hvem får tilgang til denne informasjonen?
- Hvilke beslutninger eller rapportering vil bli generert?
- Anbefalinger for mottak av signert dokument – det er flere faktorer å ta hensyn til når du bestemmer hvordan du skal motta en signert PDF fra Acrobat Sign på dokumentbehandlingssystemet.
Selv om det er fullt akseptabelt å bare velge alternativet Signert avtaledokument mens du oppretter en webhook, kan du vurdere å bruke Acrobat Sign API for å hente dokumentene når en utløsende hendelse (for eksempel avtalestatusen Fullført) mottas.
Ting å huske på ...
JSON-størrelsesbegrensning
JSON-nyttelaststørrelsen er begrenset til 10 MB.
Hvis en hendelse genererer en større nyttelast, vil en webhook bli utløst. Men de betingede parameterattributtene, hvis de finnes i forespørselen, vil bli fjernet for å redusere størrelsen på nyttelasten.
«ConditionalParametersTrimmed» returneres i svaret når dette skjer for å informere klienten om at informasjonen med conditionalParameters har blitt fjernet.
“conditionalParametersTrimmed” er et matriseobjekt som inneholder informasjon om nøklene som er trimmet.
Avkortingen vil gjøres i følgende rekkefølge:
- includeSignedDocuments
- includeParticipantsInfo
- includeDocumentsInfo
- includeDetailedInfo
Signerte dokumenter vil bli avkortet først, etterfulgt av deltakerinfo, dokumentinfo og til slutt detaljert informasjon.
Dette kan for eksempel skje på en avtalefullføringshendelse hvis den inkluderer signert dokument (base 64-kodet), eller for en avtale med flere skjemafelt
Acrobat Sign-webhook leverer varsler til avsenderen av avtalen, og enhver webhook som er konfigurert i gruppen som avtalen ble sendt fra. Kontoomfangede webhook mottar alle hendelser.
Avsender: Bruker A | Underskriver: Bruker B | Deler: Bruker C
Bruker A og Bruker B er på forskjellige kontoer
Bruker A og Bruker C er på forskjellige kontoer
Brukssak |
Varsel? |
Kommentarer/notater |
Bruker A sin konto har KONTO-nivået for webhook (opprettet av bruker A eller kontoadministrator). |
Ja |
Et KONTO-nivå for webhook varsler om alle hendelser som utløses i den kontoen. |
Bruker A sin konto har GRUPPE-nivå for webhook (opprettet av bruker A eller konto-/gruppeadministrator). Antagelse: Bruker A og gruppeadministrator er i samme gruppe. |
Ja |
Et GRUPPE-nivå for webhook varsler om alle hendelser som utløses i den gruppen. |
Bruker A har BRUKER-nivå for webhook. |
Ja |
Som avsender, utløses bruker As BRUKER-nivå for webhook |
Bruker A har RESSURS-nivå for webhook (for oversendt avtale). |
Ja |
|
Bruker Bs konto har KONTO-nivå for webhook (opprettet av bruker B eller kontoadministrator). |
Nr. |
Bruker Bs KONTO-nivå for webhook regnes som en Underskriver-webhook. |
Bruker Bs konto har GRUPPE-nivå for webhook (opprettet av bruker B eller konto-/gruppeadministrator). Antagelse: Bruker B og gruppeadministrator er i samme gruppe. |
Nr. |
Bruker Bs GRUPPE-nivå for webhook regnes som en Underskriver-webhook. |
Bruker B har BRUKER-nivå for webhook. |
Nr. |
Bruker Bs BRUKER-nivå for webhook regnes som en Underskriver-webhook. |
Bruker Cs konto har KONTO-nivå for webhook (opprettet av bruker C eller kontoadministrator). |
Nr. |
Bruker Cs KONTO-nivå for webhook regnes som en ikke-opphavs-webhook. |
Bruker Cs konto har GRUPPE-nivå for webhook (opprettet av bruker C eller konto-/gruppeadministrator). Antagelse: Bruker C og gruppeadministrator er i samme gruppe. |
Nr. |
Bruker Cs GRUPPE-nivå for webhook regnes som en ikke-opphavs-webhook. |
Bruker C har BRUKER-nivå for webhook. |
Nr. |
Bruker Cs BRUKER-nivå for webhook regnes som en ikke-opphavs webhook. |
Avsender: Bruker A | Underskriver: Bruker B | Deler: Bruker C
Bruker A, bruker B og bruker C er på samme konto
Brukssak |
Varsel? |
notater |
Bruker A sin konto har KONTO-nivået for webhook (opprettet av bruker A eller kontoadministrator). |
Ja |
KONTO-nivå for webhook varsler for hendelser utløst av kontoen. |
Bruker A sin konto har GRUPPE-nivå for webhook (opprettet av bruker A eller konto-/gruppeadministrator). Antagelse: Bruker A og gruppeadministrator er i samme gruppe. |
Ja |
GRUPPE-nivå for webhook varsler for hendelser utløst av brukerne i gruppen deres. |
Bruker A har BRUKER-nivå for webhook. |
Ja |
Som avsender, utløses bruker As Bruker-nivå for webhook |
Bruker A har RESSURS-nivå for webhook (for den oversendte avtalen). |
Ja |
|
Bruker Bs konto har KONTO-nivå for webhook (opprettet av bruker B eller kontoadministrator). |
Ja |
Siden bruker A og bruker B er på samme konto, varslet et KONTO-nivå for webhook om alle hendelser som utløses i den kontoen. |
Bruker Bs konto har GRUPPE-nivå for webhook (opprettet av bruker B eller konto-/gruppeadministrator). Antagelse: Bruker A, bruker B og gruppeadministrator er i samme gruppe. |
Ja |
Siden bruker A og bruker B er i samme gruppe, varsles et GRUPPE-nivå for webhook om alle hendelser som utløses i den gruppen. |
Bruker Bs konto har GRUPPE-nivå for webhook (opprettet av bruker B eller konto-/gruppeadministrator). Antagelse: Bruker A og bruker B er i forskjellige grupper. |
Nr. |
Bruker Bs GRUPPE-nivå for webhook regnes som en Underskriver-webhook. Bruker A sin webhook (RESSURS/BRUKER/GRUPPE/KONTO) vil bli utløst. |
Bruker B har BRUKER-nivå for webhook. |
Nr. |
Som mottaker, utløses ikke bruker Bs BRUKER-nivå for webhook. |
Bruker Cs konto har KONTO-nivå for webhook (opprettet av bruker C eller kontoadministrator). |
Ja |
Siden bruker A og bruker C er på samme konto, varsles et KONTO-nivå for webhook om alle hendelser som utløses i den kontoen. |
Bruker Cs konto har GRUPPE-nivå for webhook (opprettet av bruker C eller konto-/gruppeadministrator). Forutsetning: Bruker A, bruker C og gruppeadministrator er i samme gruppe. |
Ja |
Siden bruker A og bruker C er i samme gruppe, varslet et GRUPPE-nivå for webhook om alle hendelser som utløses i den gruppen. |
Bruker Cs konto har GRUPPE-nivå for webhook (opprettet av bruker C eller konto-/gruppeadministrator). Antagelse: Bruker A og bruker C er i forskjellige grupper. |
Nr. |
Bruker Cs GRUPPE-nivå for webhook regnes som en ikke-opphavs-webhook. Bruker A sin webhook (RESSURS/BRUKER/GRUPPE/KONTO) vil bli utløst. |
Bruker C har BRUKER-nivå for webhook. |
Nr. |
Bruker Cs BRUKER-nivå for webhook regnes som en ikke-opphavs webhook. |
Prøv på nytt når lyttetjenesten er nede
Hvis måladressen for webhooken er nede av en eller annen grunn, setter Acrobat Sign JSON i kø og prøver pushet på nytt i en progressiv syklus over 72 timer.
De uleverte hendelsene blir værende i en prøv på nytt-kø, og det gjøres en best mulig innsats i løpet av de neste 72 timene for å levere varslene i den rekkefølgen de oppsto.
Strategien for å prøve å levere varsler på nytt er en dobling av tiden mellom forsøk, og starter med et ett minutts intervall som øker til hver 12. time, og resulterer i 15 nye forsøk i løpet av 72 timer.
Hvis webhook-mottakeren ikke svarer innen 72 timer, og det ikke har vært noen vellykkede varslingsleveranser de siste syv dagene, deaktiveres webhooken. Ingen varsler vil bli sendt til denne nettadressen før webhook er aktivert igjen.
Alle varsler mellom når webhook er deaktivert og deretter aktivert igjen, vil gå tapt.
Effektiviser arbeidet ditt med Acrobat Sign
Behandle og signer dokumenter på nettet raskt og enkelt.
