Ta ett exempel på JavaScript-kod för att hämta klient-ID, validera det och returnera det sedan i svarshuvudet
Senast uppdaterad den
8 juli 2026
Översikt
En webhook är en användardefinierad HTTPS-begäran som utlöses när en prenumerationshändelse inträffar på källplatsen, (i detta fall Adobe Acrobat Sign).
En webhook är alltså en REST-tjänst som accepterar data eller en dataström.
Webhookar är avsedda för tjänst till tjänst -kommunikation i en PUSH-modell.
När en utlösande händelse inträffar, skapar Acrobat Sign en HTTPS-POST med JSON-text och skickar den till angiven URL.
Innan du konfigurerar webhookar, se till att ditt nätverk accepterar de IP-intervall som krävs för funktionalitet.
Webhookar erbjuder flera fördelar jämfört med den tidigare återanropsmetoden, varav några är:
- Administratörer kan aktivera sina egna webbhookar utan att behöva involvera Acrobat Signs support för att lista återanrops-URL
- Webhookar är bättre när det gäller ”uppdaterade” data, effektivitet i kommunikation, och säkerhet. Ingen avsökning krävs
- Webhooks tillåter enkelt olika nivåer av omfattning (konto/grupp/användare/resurs).
- Webhookar är en modernare API-lösning, som gör det enklare att konfigurera moderna program
- Flera webbhookar kan konfigureras per omfattning (konto/grupp/användare/resurs) där återanrop måste vara unika
- Webhookar gör det möjligt att välja data som ska returneras, där återanrop är en ”allt eller inget”-lösning
- Metadata som medföljer en webhook kan konfigureras (grundläggande eller detaljerad)
- Webhooks är mycket enklare att skapa, redigera eller inaktivera efter behov eftersom användargränssnittet är helt inom administratörens kontroll.
Obs!
Det här dokumentet är främst inriktat på webbhooks-gränssnittet i webbprogrammet Acrobat Sign (tidigare Adobe Sign).
Utvecklare som söker efter API-information hittar mer information här:
Förutsättningar
Du måste tillåta IP-intervallen för webhookar via din nätverkssäkerhet för att tjänsten ska fungera.
Den äldre tjänsten för återanrops-URL i REST v5 använder samma IP-intervall som webhook-tjänsten.
Administratörer kan logga in på Adobe Admin Console för att lägga till användare. När du har loggat in går du till administratörsmenyn och bläddrar ner till Webhookar.
Så här används det
Administratörer måste först ha en webhook-tjänst som är redo att acceptera den inkommande push-tjänsten från Acrobat Sign. Det finns många alternativ i detta avseende, och så länge tjänsten kan acceptera POST- och GET-förfrågningar kommer denna webhook att lyckas.
När tjänsten är på plats, kan en Acrobat Sign-administratör skapa en ny webhook från Webhook-gränssnittet på kontomenyn på Acrobat Sign-webbplatsen.
Administratörer kan konfigurera webhooken för att utlösa händelser för avtal, webbformulär (Widget) och massutskick (MegaSign). Resursen Biblioteksmall (Biblioteksdokument) kan också konfigureras via API:et.
Omfattningen för en webhook kan inkludera hela kontot eller enskilda grupper via administratörsgränssnittet. API:et ger större justeringsmöjligheter genom val av användar- eller resursomfång.
Den typ av data som skickas till URL:en kan konfigureras och inkludera saker som avtalsinformation, deltagarinformation, dokumentinformation och så vidare.
När en webhook har konfigurerats och sparats, skickar Acrobat Sign ett nytt JSON-objekt till angiven URL varje gång prenumerationshändelsen utlöses. Ingen pågående manipulering av en webhook krävs om du inte vill ändra villkor för händelseutlösare eller JSON-nyttolasten.
Verifiering av avsikten med webhook-URL
Innan du registrerar en webhook kontrollerar Acrobat Sign om den webhook-URL som anges i registreringsbegäran har för avsikt att ta emot meddelanden eller inte. När Acrobat Sign får en ny begäran om registrering av en webhook gör den därför först en verifieringsbegäran till webhookens URL. Denna verifieringsbegäran är en HTTPS GET-begäran som skickas till webhook-URL:en. Denna begäran har ett anpassat HTTP-huvud X-AdobeSign-ClientId. Värdet i den här rubriken är inställt på klient-ID (program-ID) för det API-program som begär att en webhook ska skapas/registreras. För att kunna registrera en webhook, måste webhook-URL:en svara på denna verifieringsbegäran med en 2XX-svarskod och MÅSTE dessutom skicka tillbaka samma klient-ID-värde på något av följande två sätt:
- Antingen i en svarsrubrik med X-AdobeSign-ClientId. Det är samma rubrik som skickas i begäran och som sedan skickas tillbaka i svaret.
- Eller i JSON-svarstexten med nyckeln xAdobeSignClientId där värdet är samma klient-ID som skickades i begäran.
En webhook registreras endast vid framgångsrikt svar (2XX-svarskod) och valideringen av klient-ID i rubriken eller svarstexten. Syftet med denna verifieringsbegäran är att visa att webhook-URL:en verkligen vill ta emot meddelanden till avsedd URL. Om du av misstag har angett fel URL, kommer denna URL inte att svara korrekt på bekräftelsen av avsiktsbegäran och Acrobat Sign kommer inte att skicka några meddelanden till denna URL. Dessutom kan en webhook-URL även validera att den endast tar emot meddelanden via de webhookar som registreras av ett specifikt program. Detta kan göras genom att validera klient-ID för programmet som skickas i rubriken med X-AdobeSign-ClientId. Om en webhook-URL inte känner igen ett klient-ID, får den INTE svara med framgångsrik svarskod, och Acrobat Sign kommer att se till att denna URL inte registreras som en webhook.
Verifieringen av anrop till webhook-URL:en görs i följande situationer:
- Registrera webhook: om denna verifiering av ett anrop till en webhook-URL misslyckas, kommer denna webhook inte att skapas.
- Uppdatera webhook: INAKTIV till AKTIV: om denna verifiering av ett anrop till en webhook-URL misslyckas ändras inte tillståndet för denna webhook till AKTIV.
Så besvaras ett webhook-meddelande
Acrobat Sign utför en implicit avsiktsverifiering i varje begäran om webhook-meddelande som skickas till denna webhook-URL. Således innehåller varje HTTPS-begäran för webhook-avisering även det anpassade HTTP-huvudet som kallas X-AdobeSign-ClientId. Värdet på huvudet är klient-ID (program-ID) för programmet som skapade denna webhook. Vi kommer att betrakta webhook-meddelandet som framgångsrikt levererad om, och endast om, ett svar (2XX-svarskod) returneras och klient-ID skickas i HTTP-rubriken (X-AdobeSign-ClientId) eller via en JSON-svarstext med nyckeln xAdobeSignClientId och värdet som samma klient-ID. I annat fall försöker vi leverera meddelandet på nytt till webhook-URL:en tills alla nya försök har slutförts.
Som nämnts ovan, rubriken 'X-AdobeSign-ClientId' som ingår i varje aviseringsbegäran från Sign ska värdet på detta huvud (klient-ID) upprepas på något av följande två sätt:
1. HTTP-huvudet med X-AdobeSign-ClientId och värde som detta klient-id
|
|
|---|
|
// Hämta klient-ID var clientid = request.headers['X-ADOBESIGN-CLIENTID'];
//Validera det if (clientid ==="BGBQIIE7H253K6") //Ersätt 'BGBQIIE7H253K6' med klient-ID för programmet som denna webhook skapas med { //Returnera det i svarsrubriken response.headers['X-AdobeSign-ClientId'] = clientid; response.status = 200; // standardvärde } |
|
Ta ett exempel på PHP-kod för att hämta klient-ID, validera det och returnera det sedan i svarshuvudet |
|---|
|
<?php // Hämta klient-ID $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Validera det if($clientid == "BGBQIIE7H253K6") //Ersätt 'BGBQIIE7H253K6' med klient-ID för programmet som denna webhook skapas med { //Returnera det i svarsrubriken header("X-AdobeSign-ClientId:$clientid"); header("HTTP/1.1 200 OK"); // standardvärde } ?> |
2. JSON-svarstext med nyckel som xAdobeSignClientId och värde som samma klient-id
|
Ta ett exempel på JavaScript-kod för att hämta klient-ID, validera det och returnera det i svarstexten |
|---|
|
// Hämta klient-ID var clientid = request.headers['X-ADOBESIGN-CLIENTID'];
//Validera det if (clientid ==="BGBQIIE7H253K6") //Ersätt 'BGBQIIE7H253K6' med klient-ID för programmet som denna webhook skapas med { var responseBody = { "xAdobeSignClientId" : clientid // Returnera klient-ID i brödtexten }; response.headers['Content-Type'] = 'application/json'; response.body = responseBody; response.status = 200; } |
|
Ta ett exempel på PHP-kod för att hämta klient-ID, validera det och returnera det i svarstexten |
|---|
|
<?php // Hämta klient-ID $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Validera det if($clientid == "BGBQIIE7H253K6") //Ersätt 'BGBQIIE7H253K6' med klient-ID för programmet som denna webhook skapas med { //Returnera det i svarstexten header("Content-Type: application/json"); $body = array('xAdobeSignClientId' => $clientid); echo json_encode($body); header("HTTP/1.1 200 OK"); // standardvärde } ?> |
|
Exempel på JSON-brödtext för svaret |
|---|
|
{ "xAdobeSignClientId": "BGBQIIE7H253K6" } |
Förutsättningar
Du behöver:
- Ett Microsoft-konto med licens för att skapa Azure Functions-program
- Ett befintligt Azure-funktionsprogram kan du skapa med https://docs.microsoft.com/sv-se/azure/azure-functions/functions-create-first-azure-function
- Grundläggande kunskaper i Javascript, så att du kan förstå och skriva koden på valfritt språk
Steg för att skapa en utlösare för Azure-funktioner som fungerar som en Acrobat Sign-webhook
Så här skapar du en HTTP-utlösarfunktion för JavaScript:
1. Logga in via ditt Microsoft-konto https://portal.azure.com/
2. Öppna Azure Function-programmet som visas under fliken Function Apps.
Detta öppnar listan över Azure Function-program:
3. Välj programmet där du vill skapa den nya funktionen
4. Klicka på knappen Skapa (+) för att skapa en ny Azure-funktion
5. Välj Webhook + API som scenario och JavaScript som språk
6. Klicka på Skapa denna funktion
En ny funktion som kan hantera en inkommande API-begäran skapas.
Lägg till logik för att registrera en Acrobat Sign-webhook
Innan du registrerar en webhook kontrollerar Acrobat Sign att den webhook-URL som anges i registreringsbegäran verkligen har för avsikt att ta emot meddelanden eller inte. När en ny begäran om registrering av en webhook tas emot av Acrobat Sign gör den därför först en verifieringsbegäran till webhook-URL:en. Denna verifieringsbegäran är en HTTPS GET-begäran som skickas till webhook-URL med ett anpassat HTTP-huvud X-AdobeSign-ClientId. Värdet i detta huvud är inställt på klient-ID för programmet som begär att skapa/registrera denna webhook. För att kunna registrera en webhook svarar dess URL på denna verifieringsbegäran med en 2XX-svarskod OCH måste dessutom skicka tillbaka samma klient-ID-värde på något av följande två sätt.
Det finns två alternativ som du kan använda:
Alternativ 1: Skicka klient-ID i X-AdobeSign-ClientId som svarshuvud
Skicka X-AdobeSign-ClientId i svarshuvudet. Det är samma huvud som skickas i begäran och som sedan skickas tillbaka i svaret.
Ersätt filen Index.js med följande:
module.exports = function (context, req) {
var clientId = req.headers['x-adobesign-clientid'];
// Verifiera att inkommande ClientID är äkta
if (clientId === '123XXX456') {
context.res = {
// status: 200, /* Standardvärdet är 200 */ // Alla 2XX-svar accepteras
body: "Avisering accepterad",
headers : {
'x-adobesign-clientid' : req.headers['x-adobesign-clientid']
}
};
}
else {
context.res = {
status: 400,
body: "Opps!! Illegitimate Call identified"
};
}
context.done();
};
Testa beteendet genom att testa förfrågan:
1. Klicka på knappen Test längst ned till höger
2. Testa prov-förfrågan
Även om svarshuvuden inte visas ovan, kan du observera det genom testa det med postman/DHC eller någon annan tjänst.
Alternativ 2: Skicka klient-ID i svarstexten med nyckeln xAdobeSignClientId
I JSON-svarstexten med nyckeln xAdobeSignClientId och dess värde är det samma klient-ID som skickas i begäran.
Ersätt filen Index.js med följande:
module.exports = function (context, req) {
var clientId = req.headers['x-adobesign-clientid'];
// Verifiera att inkommande ClientID är äkta
if (clientId === '123XXX456') {
context.res = {
// status: 200, /* Standardvärdet är 200 */ // Alla 2XX-svar accepteras
body: {
'xAdobeSignClientId' : clientId
},
headers : {
'Content-Type' : 'application/json'
}
};
}
else {
context.res = {
status: 400,
body: "Opps!! Illegitimate Call identified"
};
}
context.done();
};
Testa beteendet genom att testa förfrågan
1. Klicka på knappen Test längst till höger
2. Testa prov-förfrågan
Observera också att samma beteende för clientID förväntas när webhook-URL tar emot POST-aviseringar.
Klar att använda
När du har verifierat beteendet, fungerar denna webhook-URL enligt Acrobat Sign-standarder. Du kan uppdatera den anpassade logiken efter dina behov.
Hämta funktions-URL
- Klicka på Hämta funktions-URL
Kopiera URL:en och använd den för att skapa webbhooks i Acrobat Sign.
Skapa AWS Lambda-funktion
Om du vill skapa en AWS Lambda-funktion, logga in på AWS Management Console och välj tjänsten AWS Lambda i listan med tjänster.
- Klicka på Skapa en Lambda-funktion med hjälp av alternativet “Skapa från grunden”
- På sidan Konfigurera funktion, ange funktionsnamn “lambdaWebhooks” och välj Node.js 4.3 som körning
- För Roll välj en befintlig roll eller skapa en ny roll från mallar
- Om du har valt Skapa ny roll från mallar, ange ett rollnamn (t.ex. roll-lamda) och välj Enkla Microservices-behörigheter från listan över Policymallar
- Klicka på knappen Skapa funktion
- På den nya sidan AWS lamda-funktion välj “Redigera kod inline” som “Typ av kodinmatning”, behåll index.handler som Handler.
- Lägg till logik för att registrera Acrobat Sign Webhook
Innan du registrerar en webhook kontrollerar Acrobat Sign att den webhook-URL som anges i registreringsbegäran verkligen har för avsikt att ta emot meddelanden eller inte. När en ny begäran om registrering av en webhook tas emot av Acrobat Sign gör den därför först en verifieringsbegäran till webhook-URL:en. Denna verifieringsbegäran är en HTTPS GET-begäran som skickas till webhook-URL med ett anpassat HTTP-huvud X-AdobeSign-ClientId. Värdet i detta huvud är inställt på klient-ID för programmet som begär att skapa/registrera denna webhook. För att kunna registrera en webhook svarar dess URL på denna verifieringsbegäran med en 2XX-svarskod OCH kan dessutom skicka tillbaka samma klient-ID-värde på något av följande två sätt. Observera även att samma beteende för clientID förväntas när en webhook-URL tar emot POST-aviseringar.
Gör något av följande:
Fall 1: Skicka klient-ID i X-AdobeSign-ClientId som svarshuvud
- Skicka X-AdobeSign-ClientId i svarshuvudet. Det är samma huvud som skickas i begäran och som sedan skickas tillbaka i svaret.
Kodfragment
Ersätt det automatiskt genererade kodfragmentet med följande kod i filen index.js:
- Skicka X-AdobeSign-ClientId i svarshuvudet. Det är samma huvud som skickas i begäran och som sedan skickas tillbaka i svaret.
|
Exempelnodens JS-kod för att hämta klient-ID, validera den och returnera den sedan i svarshuvudet |
|---|
|
exports.handler = function index(event, context, callback) { // Hämta klient-ID var clientid = event.headers['X-AdobeSign-ClientId'];
//Validera det if (clientid =="BGBQIIE7H253K6") //ersätt 'BGBQIIE7H253K6' med klient-ID för programmet som denna webhook skapas med { var response = { statusCode: 200, headers: { "X-AdobeSign-ClientId": clientid } }; callback(null,response); } else { callback("Oops!! illegitimate call"); } } |
Fall 2: Skicka klient-ID i svarstexten med nyckel xAdobeSignClientId
I JSON-svarstexten med nyckel för xAdobeSignClientId och dess värde är samma klient-ID som skickas i begäran.
Kodfragment
Ersätt filen Index.js med följande:
|
Exempelnodens JS-kod för att hämta klient-ID, validera den och returnera den sedan i svarshuvudet |
|---|
|
exports.handler = function index(event, context, callback) { // Hämta klient-ID var clientid = event.headers['X-AdobeSign-ClientId'];
//Validera det if (clientid =="BGBQIIE7H253K6") //Ersätt 'BGBQIIE7H253K6' med klient-ID för programmet som denna webhook skapas med { var responseBody = { xAdobeSignClientId : clientid };
var response = { statusCode: 200, body: JSON.stringify(responseBody) };
callback(null,response); } else { callback("Opps!! illegitimate call"); } } |
- Spara funktionen. Lambda-funktionen skapas och vi är nästan redo att använda den i en webhook i realtid.
Konfigurera AWS API Gateway
För att göra denna Lambda offentligt tillgänglig via en HTTP-metod måste vi konfigurera AWS API Gateway med hjälp av vår funktion (skapad ovan) som serverdel för detta API.
I AWS Management Console väljer du API Gateway från AWS-tjänsten och klicka på knappen Skapa API
- På sidan Skapa nytt API, välj Nytt API och ange webhooks som API-namn.
- Klicka på knappen Skapa API
- Välj Åtgärder i listrutan och välj alternativet Skapa resurs
- Kontrollera alternativet Konfigurera som proxyresurs och ange validera som Resursnamn och {proxy+} i Resurssökväg
- Lämna alternativet Aktivera API Gateway-CORS avmarkerat och klicka på knappen Skapa resurs
- Behåll Lambda Funktionsproxy markerad som Integrationstyp och välj det område där du har skapat lambdafunktionen i listrutan Lambdaregionen (förmodligen är det samma region där du skapar API Gateway).
- Ange validera som Lambda-funktion och klicka på knappen Spara
- I dialogrutan Lägg till behörighet till Lambda-funktion, välj OK
Om alla steg ovan utförs korrekt ser du ungefär det här:
Distribuera API
Nästa steg är att distribuera detta API så att det blir klart att användas.
- I listrutan Åtgärder, välj Distribuera API
- Välj [New Stage] i Distributionssteg och ange prod (eller något annat som du vill identifiera detta steg med) i Stegnamn
- Klicka på knappen Distribuera
API är nu klart att användas och du hittar anrops-URL i den blå rutan som visas nedan:
Notera denna URL eftersom den måste anges som webhook-URL i realtid.
Klar att använda
Det är gjort. Använd ovanstående URL ovan med “/{nodeJSfunctionName}” som läggs till som webhook-url i POST /webhooks API-begäran. När du har verifierat beteendet fungerar denna webhook-URL enligt
Acrobat Sign-standarder. Du kan uppdatera/lägga till anpassad logik efter dina behov.
Så här aktiverar och inaktiverar du
åtkomst till funktionen Webhooks är aktiverad som standard för konton med företagsplaner
administratörer på gruppnivå kan endast skapa/styra webhookar som fungerar inom gruppen.
Åtkomst till sidan Webhookar finns i den vänstra listen i Admininistrationsmenyn.
Samtidighetsbaserad hastighetsbegränsning
Skapande och aviseringshändelser av webhook (och återuppringning) är begränsade i antalet samtidiga meddelanden som aktivt levereras till kunden från Acrobat Sign-systemet. Denna gräns gäller för kontot, för att inkludera alla grupper inom kontot.
Denna typ av hastighetsbegränsning förhindrar ett dåligt utformat konto från att konsumera en oproportionerligt stor mängd resurser på servrar, vilket påverkar alla andra kunder i den servermiljön negativt.
Antalet samtidiga händelser per konto har beräknats för att säkerställa att konton med välordnade webhooks kommer att få sina meddelanden på kortast möjliga tid och bör sällan stöta på en situation där meddelanden blir försenade på grund av för många förfrågningar. Nuvarande tröskelvärden är:
|
Åtgärd |
Maximalt antal |
Beskrivning |
|
Skapande av webhook |
10 |
Det går att skapa minst tio webhook-förfrågningar samtidigt per konto. |
|
Meddelande om webhook/återanrop |
30 |
Högst 30 samtidiga webhook- och callback-meddelanden tillåts per konto. |
Bästa praxis
- Prenumerera på specifika händelser som behövs för att begränsa antalet HTTPS-begäranden till servern – ju mer specifika du kan göra dina webhookar, desto mindre volym behöver du gå igenom.
- Vara dublettresistent – om du har fler än ett program som delar samma webhook-URL och samma användare mappas till varje program, skickas samma händelse till din webhook flera gånger (en gång per program). I vissa fall kan din webhook ta emot dubbletthändelser. Webhook-applikationen bör vara tolerant mot detta och dedupera med händelse-ID.
- Besvara alltid webhookar snabbt – appen har bara tio sekunder på sig att besvara webhook-förfrågningar. För verifieringsbegäran är detta sällan ett problem eftersom din app inte behöver göra något egentligt arbete för att svara. För aviseringsförfrågningar kommer dock appen vanligtvis att göra något som tar tid vid svar på begäran. Vi rekommenderar att du arbetar på en separat tråd eller asynkront med en kö så att du säkert kan svara inom fem sekunder
- Hantera samtidighet – när en användare gör ett antal ändringar i snabb följd får din app troligen flera meddelanden för samma användare vid ungefär samma tidpunkt. Om du inte är försiktig med hur du hanterar samtidig användning kan det sluta med att programmet bearbetar samma ändringar för samma användare flera gånger. För att dra nytta av Acrobat Sign webhooks måste du ha en tydlig förståelse för användningen av informationen. Var noga med att ställa frågor som:
- Vilka data vill du returnera i nyttolasten?
- Vem kommer att få tillgång till denna information?
- Vilka beslut eller rapporter kommer att genereras?
- Rekommendationer för att ta emot signerade dokument – det finns flera faktorer att ta hänsyn till när du avgör hur du tar emot en signerad PDF-fil från Acrobat Sign i dokumenthanteringssystemet.
Även om det är helt acceptabelt att bara välja alternativet Signerat avtalsdokument när du skapar en webhook, kan du använda API för Acrobat Sign för att hämta dokumenten när en utlösande händelse (till exempel avtalsstatus slutförd) tas emot.
Saker att tänka på ...
JSON storleksbegränsning
JSON nyttolast är begränsad till 10 MB.
Om en händelse genererar en större nyttolast utlöses en webhook men attribut för villkorlig parameter, om sådana finns i begäran, tas bort för att minska nyttolastens storlek.
ConditionalParametersTrimmed returneras i svaret när detta händer för att informera klientorganisationen om att informationen conditionalParameters har tagits bort.
“conditionalParametersTrimmed” är ett matris-objekt som innehåller information om de nycklar som har trimmats.
Trunkeringen sker i följande ordning:
- includeSignedDocuments
- includeParticipantsInfo
- includeDocumentsInfo
- includeDetailedInfo
Signerade dokument trunkeras först, följt av deltagarinformation, dokumentinformation och slutligen detaljerad information.
Detta kan till exempel inträffa vid en händelse för avtalsslutförande om den inkluderar ett signerat dokument (base 64-kodad) eller för ett avtal med flera formulärfält
Via Acrobat Sign-webhookar skickas meddelanden till avtalets avsändare och eventuella webhookar som konfigurerats inom grupp som avtalet skickats från. Webbhooks med kontoomfattning mottar samtliga händelser.
Avsändare: användare A | Signerare: användare B | Part som delas med: användare C
Användare A och B finns på olika konton
Användare A och C finns på olika konton
Användningsfall |
Avisering? |
Kommentarer/anteckningar |
Kontot för användare A har webhook på nivå KONTO (skapad av användare A eller kontoadministratör). |
Ja |
Med webhook på nivå KONTO meddelas alla händelser som aktiveras för det kontot. |
Kontot för användare A har webhook på nivå GRUPP (skapad av användare A eller konto-/gruppadministratör). Antagande: Användare A och gruppadministratör finns i samma grupp. |
Ja |
Med webhook på nivå GRUPP meddela alla händelser som aktiveras för den här gruppen. |
Användare A har webhook på nivå ANVÄNDARE. |
Ja |
Webhook på nivå ANVÄNDARE för användare A har aktiverats då de är avsändare. |
Användare A har webhook på nivå RESURS (för avtalet ovan som skickats). |
Ja |
|
Kontot för användare B har webhook på nivå KONTO (skapad av användare B eller kontoadministratör). |
Nej |
Webhook på nivå KONTO för användare B klassas som webhook för signerare. |
Kontot för användare B har webhook på nivå GRUPP (skapad av användare B eller kontoadministratör). Antagande: Användare B och gruppadministratör finns i samma grupp. |
Nej |
Webhook på nivå GRUPP för användare B klassas som webhook för signerare. |
Användare B har webhook på nivå ANVÄNDARE. |
Nej |
Webhook på nivå ANVÄNDARE för användare B klassas som webhook för signerare. |
Kontot för användare C har webhook på nivå KONTO (skapad av användare C eller kontoadministratör). |
Nej |
Webhook på nivå KONTO för användare C klassas som webhook för icke-upphovsman. |
Kontot för användare C har webhook på nivå GRUPP (skapad av användare C eller kontoadministratör). Antagande: Användare C och gruppadministratör finns i samma grupp. |
Nej |
Webhook på nivå GRUPP för användare C klassas som webhook för icke-upphovsman. |
Användare C har webhook på nivå ANVÄNDARE. |
Nej |
Webhook på nivå ANVÄNDARE för användare C klassas som webhook för icke-upphovsman. |
Avsändare: användare A | Signerare: användare B | Part som delas med: användare C
Användare A, B och C finns på samma konto
Användningsfall |
Avisering? |
Anteckningar |
Kontot för användare A har webhook på nivå KONTO (skapad av användare A eller kontoadministratör). |
Ja |
Webhookar på nivå KONTO meddelar om händelser som aktiverats för kontot. |
Kontot för användare A har webhook på nivå GRUPP (skapad av användare A eller konto-/gruppadministratör). Antagande: Användare A och gruppadministratör finns i samma grupp. |
Ja |
Webhookar på nivå GRUPP meddelar om händelser som aktiveras av användarna i deras grupp. |
Användare A har webhook på nivå ANVÄNDARE. |
Ja |
Webhook på nivå ANVÄNDARE för användare A har aktiverats då de är avsändare. |
Användare A har webhook på nivå RESURS (för avtalet ovan som skickats). |
Ja |
|
Kontot för användare B har webhook på nivå KONTO (skapad av användare B eller kontoadministratör). |
Ja |
Eftersom användare A och B finns på samma konto kan webhookar på nivå KONTO meddela om alla händelser som aktiveras för det kontot. |
Kontot för användare B har webhook på nivå GRUPP (skapad av användare B eller kontoadministratör). Antagande: Användare A, B och gruppadministratör finns i samma grupp. |
Ja |
Eftersom användare A och B finns i samma grupp kan webhookar på nivå GRUPP meddela om alla händelser som aktiveras för den här gruppen. |
Kontot för användare B har webhook på nivå GRUPP (skapad av användare B eller kontoadministratör). Antagande: Användare A och B finns i olika grupper. |
Nej |
Webhook på nivå GRUPP för användare B klassas som webhook för signerare. Webhook för användare A (RESURS/ANVÄNDARE/GRUPP/KONTO) aktiveras. |
Användare B har webhook på nivå ANVÄNDARE. |
Nej |
Webhook för användare B på nivå ANVÄNDARE aktiveras inte då de är mottagare. |
Kontot för användare C har webhook på nivå KONTO (skapad av användare C eller kontoadministratör). |
Ja |
Eftersom användare A och C finns på samma konto kan webhookar på nivå KONTO meddela om alla händelser som aktiveras för det kontot. |
Kontot för användare C har webhook på nivå GRUPP (skapad av användare C eller kontoadministratör). Antagande: Användare A, C och gruppadministratör finns i samma grupp. |
Ja |
Eftersom användare A och C finns i samma grupp kan webhookar på nivå GRUPP meddela om alla händelser som aktiveras för den här gruppen. |
Kontot för användare C har webhook på nivå GRUPP (skapad av användare C eller kontoadministratör). Antagande: Användare A och Användare C finns i olika grupper. |
Nej |
Webhook på nivå GRUPP för användare C klassas som webhook för icke-upphovsman. Webhook för användare A (RESURS/ANVÄNDARE/GRUPP/KONTO) aktiveras. |
Användare C har webhook på nivå ANVÄNDARE. |
Nej |
Webhook på nivå ANVÄNDARE för användare C klassas som webhook för icke-upphovsman. |
Försök igen när lyssningstjänsten är nere
Om aktuell mål-URL för en webhook av någon anledning inte fungerar, ställer Acrobat Sign JSON-servern i kö och försöker sedan köra push-funktionen på nytt i en progressiv cykel under 72 timmar.
De ej levererade händelserna sparas i en kö för återförsök och under de kommande 72 timmarna görs allt för att leverera meddelandena i den ordning de inträffade.
Strategin för att försöka leverera meddelanden på nytt är en fördubbling av tiden mellan försöken, med ett intervall som startar på 1 minut och ökar till var 12:e timme, vilket resulterar i 15 försök under 72 timmar.
Om webhook-mottagaren inte svarar inom 72 timmar och inga meddelanden har skickats under de senaste sju dagarna kommer aktuell webhook att bli inaktiverad. Inga meddelanden skickas till denna URL förrän denna webhook är aktiverad igen.
Alla meddelanden mellan den tidpunkt då aktuell webhook inaktiverades och sedan aktiverades igen kommer att förloras.
Effektivisera ditt arbete med Acrobat Sign
Hantera och signera dokument online snabbt och enkelt.
