Een webhook is een door de gebruiker gedefinieerd HTTPS-verzoek dat wordt geactiveerd wanneer een subscribed gebeurtenis plaatsvindt op de bronsite (in dit geval Adobe Acrobat Sign).

Een webhook is dus gewoon een REST-service die gegevens of een gegevensstroom accepteert.

Webhooks zijn bedoeld voor service-tot-service communicatie in een PUSH-model.

Wanneer zich een subscribed gebeurtenis voordoet, construeert Acrobat Sign een HTTPS-POST met een JSON-hoofdtekst en levert deze aan de opgegeven URL.

Voordat u webhooks configureert, moet u ervoor zorgen dat uw netwerk de IP-bereiken accepteert die nodig zijn voor functionaliteit.

Webhooks bieden meerdere voordelen ten opzichte van de vorige callbackmethode, bijvoorbeeld:

Beheerders kunnen hun eigen webhooks inschakelen zonder Acrobat Sign-ondersteuning voor het weergeven van de callback-URL
Webhooks zijn beter betreffende "versheid" van gegevens, de efficiëntie van communicatie en beveiliging. Geen polling vereist
Met webhooks wordt het gebruik van verschillende bereiken eenvoudiger (Account/Groep/Gebruiker/Bron).
Webhooks bieden een modernere API-oplossing, waardoor moderne applicaties eenvoudiger kunnen worden geconfigureerd
U kunt meerdere webhooks per bereik configureren (Account/Groep/Gebruiker/Bron), terwijl callbacks uniek moesten zijn
Bij webhooks kunt u specifiek aangeven welke gegevens worden geretourneerd. Bij callbacks is dit een "alles of niets"-optie
De metagegevens die zijn opgenomen in een webhook, kunnen worden geconfigureerd (standaard of gedetailleerd)
Webhooks kunnen veel eenvoudiger worden gemaakt, bewerkt of, indien nodig, uitgeschakeld, omdat de gebruikersinterface volledig binnen de controle van de beheerder valt.

Opmerking:

Dit document is voornamelijk gericht op de webhooks-UI in de Acrobat Sign-internettoepassing (voorheen Adobe Sign).

Ontwikkelaars die meer willen weten over API kunnen hier de gewenste informatie vinden:

Informatie over REST v6

Vereisten

U moet de IP-bereiken voor webhooks toestaan via uw netwerkbeveiliging om de service te laten werken.

De verouderde callback-URL-service in REST v5 gebruikt dezelfde IP-bereiken als de webhookservice.

Beheerders kunnen zich aanmelden bij de Adobe Admin Console om gebruikers toevoegen. Als u bent aangemeld, gaat u naar het beheerdersmenu en scrolt u omlaag naar Webhooks.

Aanmelden bij Admin Console

Gebruik

Beheerders moeten eerst een webhookservice hebben waarmee binnenkomende pushmeldingen van Acrobat Sign worden geaccepteerd. Er zijn in dit opzicht veel opties en zolang de service POST- en GET-verzoeken kan accepteren, zal de webhook succesvol zijn.

Zodra de service is ingesteld, kan een Acrobat Sign-beheerder een nieuwe webhook maken via de Webhook-interface in het menu Account van de Acrobat Sign-site.

Beheerders kunnen de webhook zodanig configureren dat deze wordt geactiveerd voor Overeenkomst-, Webformulier (Widget)- of 'In bulk verzenden' (MegaSign)-gebeurtenissen. Bibliotheeksjabloonbron (Bibliotheekdocument) kan ook worden geconfigureerd via de API.

Het bereik van de webhook kan een heel account of afzonderlijke groepen omvatten. Dit gebeurt via de beheerinterface. De API maakt meer granulariteit mogelijk door de selectie van de bereiken GEBRUIKER of BRON.

Het type gegevens dat naar de URL wordt gepusht, is configureerbaar en kan zaken omvatten zoals informatie over de overeenkomst, de deelnemer, het document, enzovoort.

Zodra de webhook is geconfigureerd en opgeslagen, pusht Acrobat Sign een nieuw JSON-object naar de gedefinieerde URL telkens wanneer de subscribed gebeurtenis wordt geactiveerd. U hoeft de webhook niet voortdurend te bewerken of te controleren, tenzij u de criteria voor triggergebeurtenissen of de JSON-payload wilt wijzigen.

Verificatie van de bedoeling van de webhook -URL

Voordat een webhook succesvol wordt geregistreerd, verifieert Acrobat Sign of de webhook-URL die in het registratieverzoek is opgegeven, bedoeld is om meldingen te ontvangen of niet. Daarom dient Acrobat Sign, wanneer het een nieuw webhook-registratieverzoek ontvangt, eerst een verificatieverzoek in bij de webhook-URL. Dit verificatieverzoek is een HTTPS GET-aanvraag die naar de webhook-URL is verzonden. Deze aanvraag heeft een aangepaste HTTP-header X-AdobeSign-ClientId. De waarde in deze header is ingesteld op de client-ID (applicatie-ID) van de API-applicatie die de aanvraag voor het maken/registreren van de webhook indient. Voordat een webhook succesvol kan worden geregistreerd, moet de webhook-URL aan dit verificatieverzoek voldoen met een 2XX-antwoordcode EN daarnaast MOET dezelfde client-ID-waarde worden teruggestuurd op een van de volgende twee manieren:

In een X-AdobeSign-ClientId-responsheader. Dit is dezelfde koptekst die is doorgegeven in de oorspronkelijke aanvraag en die in de respons moet worden 'teruggekaatst'.
In de JSON-hoofdtekst van de respons met de sleutel xAdobeSignClientId en de waarde die gelijk is aan de client-ID die in de koptekst van de aanvraag is verzonden.

De webhook wordt alleen geregistreerd bij een succesvolle respons (2XX-responscode) en validatie van de client-ID in de kop- of hoofdtekst van de respons.Het doel van dit verificatieverzoek is om aan te tonen dat uw webhook-URL ook daadwerkelijk meldingen wil ontvangen op de desbetreffende URL. Als u per ongeluk een verkeerde URL hebt ingevoerd, reageert de URL niet correct op de verificatieaanvraag en stuurt Acrobat Sign geen meldingen meer naar die URL. Daarnaast kan de webhook-URL ook valideren dat de URL alleen meldingen ontvangt via de webhooks die zijn geregistreerd bij een specifieke applicatie. Hiervoor moet u de client-ID van de toepassing valideren die wordt doorgegeven in de X-AdobeSign-ClientId-header. Als deze client-ID niet wordt herkend door de webhook-URL, moet deze NIET reageren met de antwoordcode voor succes. Acrobat Sign zal er in dat geval voor zorgen dat de URL niet als webhook wordt geregistreerd.

Verificatie van de webhook-URL-aanroep wordt in de volgende gevallen uitgevoerd:

Bij registratie van de webhook: als de verificatie van de webhook-URL-aanroep mislukt, wordt de webhook niet gemaakt.
Bij het bijwerken van de webhook van NIET-ACTIEF naar ACTIEF: als de verificatie van de webhook-URL-aanroep mislukt, wordt de status van de webhook niet gewijzigd naar ACTIEF.

Reageren op een webhookmelding

Acrobat Sign voert een impliciete verificatie van de intentie uit in elk webhookmeldingsverzoek dat naar de webhook-URL wordt verzonden. Zo bevat elk webhookmeldings-HTTPS-verzoek ook de aangepaste HTTP header genaamd X-AdobeSign-ClientId. De waarde van deze header is de client-ID (Application ID) van de toepassing waarmee de webhook is gemaakt De levering van de webhookmelding geldt alleen als succesvol wanneer een succesreactie (2XX antwoordcode) wordt geretourneerd en de client-ID wordt verzonden in de HTTP-header (X-AdobeSign-ClientId) of in een JSON-antwoordtekst met sleutel als xAdobeSignClientId en waarde als dezelfde client-ID, anders proberen we de melding opnieuw naar de webhook-URL te sturen totdat de nieuwe pogingen zijn opgebruikt.

Zoals hierboven vermeld, moet de waarde van de client-ID in de koptekst 'X-AdobeSign-ClientId' die is opgenomen in elke meldingsaanvraag van Sign, op een van de volgende twee manieren worden 'teruggekaatst':

1. HTTP-koptekst X-AdobeSign-ClientId en de waarde van deze client-ID

Voorbeeld van Javascript-code voor het ophalen, valideren en retourneren van de client-ID naar de koptekst van het antwoord
//Client-ID ophalen var clientid = request.headers['X-ADOBESIGN-CLIENTID']; //Valideren if (clientid ==="BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt { //Retourneren in de koptekst van de respons response.headers['X-AdobeSign-ClientId'] = clientid; response.status = 200; // standaardwaarde }

Voorbeeld van PHP-code voor het ophalen, valideren en retourneren van de client-ID naar de koptekst van het antwoord
<?php //Client-ID ophalen $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Valideren if($clientid == "BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt { //Retourneren in de koptekst van de respons header("X-AdobeSign-ClientId:$clientid"); header("HTTP/1.1 200 OK"); // standaardwaarde } ?>

2. JSON-hoofdtekst van de respons met de sleutel xAdobeSignClientId en de waarde van dezelfde client-ID

Voorbeeld van Javascript-code voor het ophalen, valideren en retourneren van de client-ID naar de hoofdtekst van hat antwoord
//Client-ID ophalen var clientid = request.headers['X-ADOBESIGN-CLIENTID']; //Valideren if (clientid ==="BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt { var responseBody = { "xAdobeSignClientId" : clientid // Client-ID retourneren in de hoofdtekst van de respons }; response.headers['Content-Type'] = 'application/json'; response.body = responseBody; response.status = 200; }

Voorbeeld van Javascript-code voor het ophalen, valideren en retourneren van de client-ID naar de hoofdtekst van hat antwoord

//Client-ID ophalen

var clientid = request.headers['X-ADOBESIGN-CLIENTID'];

//Valideren

if (clientid ==="BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt

{

var responseBody = {

"xAdobeSignClientId" : clientid // Client-ID retourneren in de hoofdtekst van de respons

};

response.headers['Content-Type'] = 'application/json';

response.body = responseBody;

response.status = 200;

}

Voorbeeld van PHP-code voor het ophalen, valideren en retourneren van de client-ID naar de hoofdtekst van de respons
<?php //Client-ID ophalen $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Valideren if($clientid == "BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt { //Retourneren in de hoofdtekst van de respons header("Content-Type: application/json"); $body = array('xAdobeSignClientId' => $clientid); echo json_encode($body); header("HTTP/1.1 200 OK"); // standaardwaarde } ?>

Voorbeeld van PHP-code voor het ophalen, valideren en retourneren van de client-ID naar de hoofdtekst van de respons

<?php

//Client-ID ophalen

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Valideren

if($clientid == "BGBQIIE7H253K6") //Vervang de waarde 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt

{

//Retourneren in de hoofdtekst van de respons

header("Content-Type: application/json");

$body = array('xAdobeSignClientId' => $clientid);

echo json_encode($body);

header("HTTP/1.1 200 OK"); // standaardwaarde

}

Voorbeeld van JSON-hoofdtekst van de respons
{ "xAdobeSignClientId": "BGBQIIE7H253K6" }

Vereisten

U hebt het volgende nodig:

Een Microsoft-account met een licentie om Azure Functions-toepassingen te maken
Een bestaande Azure Function-toepassing. U kunt deze maken met behulp van https://docs.microsoft.com/nl-nl/azure/azure-functions/functions-create-first-azure-function
Standaardkennis van Javascript, zodat u de code in een taal van uw keuze kunt begrijpen en schrijven

Stappen voor het maken van een Azure Functions-trigger die fungeert als Acrobat Sign-webhook

Een Javascript HTTP-triggerfunctie maken:

1. Meld u aan via uw Microsoft-account https://portal.azure.com/

2. Open de Azure Functie-applicatie die wordt weergegeven op het tabblad Functie-apps.

Hiermee wordt uw lijst met Azure Function-toepassingen geopend:

3. Kies de toepassing waarin u deze nieuwe functie wilt maken

4. Klik op de knop Maken (+) om een nieuwe Azure-functie te maken

5. Selecteer Webhook + API als scenario en Javascript als taal

6. Klik op Deze functie maken

Er wordt een nieuwe functie gemaakt waarmee een binnenkomende API-aanvraag kan worden verwerkt.

Logica toevoegen voor registratie van de Acrobat Sign-webhook

Voordat een webhook kan worden geregistreerd, controleert Acrobat Sign of de webhook-URL in de registratieaanvraag daadwerkelijk is bedoeld om meldingen te ontvangen. Wanneer Acrobat Sign een nieuwe aanvraag voor webhookregistratie ontvangt, wordt dan ook eerst een verificatieaanvraag gestuurd naar de webhook-URL. Hierbij gaat het om een HTTPS GET-aanvraag die naar de webhook-URL wordt gestuurd met de aangepaste HTTP-header X-AdobeSign-ClientId. De waarde in deze header is ingesteld op de client-ID van de toepassing die de aanvraag voor het maken/registreren van de webhook indient. Voordat een webhook kan worden geregistreerd, moet de webhook-URL aan dit verzoek voldoen met een 2XX-responscode. Bovendien moet dezelfde waarde voor de client-ID worden teruggestuurd op een van de volgende twee manieren.

U hebt twee opties:

Optie 1: De client-ID in X-AdobeSign-ClientId doorgeven als koptekst van de respons

Geef de X-AdobeSign-ClientId door in de koptekst van de respons. Dit is dezelfde koptekst die was doorgegeven in de oorspronkelijke aanvraag en die in de respons moet worden 'teruggekaatst'.

Vervang het bestand Index.js door het volgende:

module.exports = function (context, req) {

var clientId = req.headers['x-adobesign-clientid'];

// Bevestigen dat de binnenkomende ClientID ook echt is

if (clientId === '123XXX456') {

context.res = {

// status: 200, /* Defaults to 200 */ // elke 2XX-respons is acceptabel

body: "Melding geaccepteerd",

headers : {

'x-adobesign-clientid' : req.headers['x-adobesign-clientid']

}

};

}

else {

context.res = {

status: 400,

body: "Oeps!! Ongeldige aanroep geïdentificeerd"

};

}

context.done();

};

Test het gedrag door de aanvraag na te bootsen:

1. Klik op de knop Test in de rechterhoek

2. Boots de aanvraag na

Hoewel antwoordheaders hierboven niet worden weergegeven, kunt u het bekijken door nabootsing via postman/DHC of een andere dienst.

Optie 2: De client-ID doorgeven in de hoofdtekst van het antwoord met de sleutel xAdobeSignClientId

In de JSON-hoofdtekst van de respons met de sleutel xAdobeSignClientId en de waarde die gelijk is aan de client-ID die in de koptekst van de aanvraag was verzonden.

Vervang het bestand Index.js door het volgende:

De inhoud van het index.js-bestand bijwerken

module.exports = function (context, req) {

var clientId = req.headers['x-adobesign-clientid'];

// Bevestigen dat de binnenkomende ClientID ook echt is

if (clientId === '123XXX456') {

context.res = {

// status: 200, /* Defaults to 200 */ // elke 2XX-respons is acceptabel

body: {

'xAdobeSignClientId' : clientId

headers : {

'Content-Type' : 'application/json'

}

};

}

else {

context.res = {

status: 400,

body: "Oeps!! Ongeldige aanroep geïdentificeerd"

};

}

context.done();

};

Test het gedrag door de aanvraag na te bootsen

1. Klik op de knop Test in de rechterhoek

2. Boots de aanvraag na

Merk op dat hetzelfde gedrag voor clientID wordt verwacht wanneer de webhook-URL een POST-melding ontvangt.

Klaar voor gebruik

Nadat u het gedrag hebt geverifieerd, is de webhook-URL functioneel volgens de Acrobat Sign-normen. U kunt de aangepaste logica verder bijwerken op basis van uw vereisten.

De functie-URL ophalen

Klik op Functie-URL ophalen

Kopieer de URL en gebruik deze om webhooks te maken in Acrobat Sign.

De AWS Lambda-functie maken

Om een AWS Lambda-functie te maken meldt u zich aan bij uw AWS Management Console en selecteert u de AWS Lambda-service in de lijst met services.

Klik op Een Lambda-functie maken met de optie Nieuw ontwerpen
Voer op de pagina Functie configureren de functienaam lambdaWebhooks in en selecteer Node.js 4.3 als Runtime
Kies voor de Rol een bestaande rol of maak een nieuwe rol op basis van sjablonen
- Als u hebt gekozen voor Nieuwe rol maken op basis van sjablonen, voert u een rolnaam in (bijv. rol-lamda) en selecteert u Vereenvoudigde microservices-machtigingen in de lijst Beleidsjablonen
Klik op de knop Functie maken

Selecteer op de nieuwe AWS lambda-functiepagina Code inline bewerken als Type code-invoer, bewaar de index.handler als Handler.
Logica toevoegen om de Acrobat Sign-webhook te registreren
Voordat een webhook kan worden geregistreerd, controleert Acrobat Sign of de webhook-URL in de registratieaanvraag daadwerkelijk is bedoeld om meldingen te ontvangen. Wanneer Acrobat Sign een nieuwe aanvraag voor webhookregistratie ontvangt, wordt dan ook eerst een verificatieaanvraag gestuurd naar de webhook-URL. Hierbij gaat het om een HTTPS GET-aanvraag die naar de webhook-URL wordt gestuurd met de aangepaste HTTP-header X-AdobeSign-ClientId. De waarde in deze header is ingesteld op de client-ID van de toepassing die de aanvraag voor het maken/registreren van de webhook indient. Voordat een webhook kan worden geregistreerd, moet de webhook-URL aan dit verzoek voldoen met een 2XX-responscode. Bovendien moet dezelfde waarde voor de client-ID worden teruggestuurd op een van de volgende twee manieren. Merk op dat hetzelfde gedrag voor clientID wordt verwacht wanneer de webhook-URL een POST-melding ontvangt.

Volg een van de twee gevallen:

Geval 1: Client-ID doorgeven in X-AdobeSign-ClientId als koptekst van de respons
- Geef de X-AdobeSign-ClientId door in de koptekst van de respons. Dit is dezelfde koptekst die was doorgegeven in de oorspronkelijke aanvraag en die in de respons moet worden 'teruggekaatst'.
  
  Codefragment
  In het index.js-bestand vervangt u het automatisch gegenereerde codefragment door de volgende code:

Voorbeeld van de JS-code van de node om de client-ID op te halen, deze te valideren en vervolgens terug te sturen naar de koptekst van de respons
exports.handler = function index(event, context, callback) { // Client-ID ophalen var clientid = event.headers['X-AdobeSign-ClientId']; //Valideren if (clientid =="BGBQIIE7H253K6") //Vervang 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt { var response = { statusCode: 200, headers: { "X-AdobeSign-ClientId": clientid } }; callback(null,response); } else { callback("Oops!! illegitimate call"); } }

Voorbeeld van de JS-code van de node om de client-ID op te halen, deze te valideren en vervolgens terug te sturen naar de koptekst van de respons

exports.handler = function index(event, context, callback) {

// Client-ID ophalen

var clientid = event.headers['X-AdobeSign-ClientId'];

//Valideren

if (clientid =="BGBQIIE7H253K6") //Vervang 'BGBQIIE7H253K6' door de client-ID van de toepassing waarmee de webhook is gemaakt

{

var response = {

statusCode: 200,

headers: {

"X-AdobeSign-ClientId": clientid

}

};

callback(null,response);

}

else {

callback("Oops!! illegitimate call");

}

Geval 2: Client-ID doorgeven in de hoofdtekst van de respons met de sleutel xAdobeSignClientId

In de JSON-hoofdtekst van de respons met de sleutel xAdobeSignClientId en de waarde die gelijk is aan de client-ID die in de koptekst van de aanvraag was verzonden.

Codefragment

Vervang het bestand Index.js door het volgende:

Voorbeeld van de JS-code van de node om de client-ID op te halen, deze te valideren en vervolgens terug te sturen naar de koptekst van de respons
exports.handler = function index(event, context, callback) { // Client-ID ophalen var clientid = event.headers['X-AdobeSign-ClientId']; //Valideren if (clientid =="BGBQIIE7H253K6") //Vervang 'BGBQIIE7H253K6' door de client-ID van de applicatie waarmee de webhook is gemaakt { var responseBody = { xAdobeSignClientId : clientid }; var response = { statusCode: 200, body: JSON.stringify(responseBody) }; callback(null,response); } else { callback("Opps!! illegitimate call"); } }

Voorbeeld van de JS-code van de node om de client-ID op te halen, deze te valideren en vervolgens terug te sturen naar de koptekst van de respons

exports.handler = function index(event, context, callback) {

// Client-ID ophalen

var clientid = event.headers['X-AdobeSign-ClientId'];

//Valideren

if (clientid =="BGBQIIE7H253K6") //Vervang 'BGBQIIE7H253K6' door de client-ID van de applicatie waarmee de webhook is gemaakt

{

var responseBody = {

xAdobeSignClientId : clientid

};

var response = {

statusCode: 200,

body: JSON.stringify(responseBody)

};

callback(null,response);

}

else {

callback("Opps!! illegitimate call");

}

Sla de functie op. Lambda-functie is gemaakt en we zijn bijna klaar om deze te gebruiken in een realtimewebhook

De AWS API-gateway configureren

Om deze Lambda openbaar toegankelijk te maken via een HTTP-methode moeten we de AWS API Gateway configureren met onze functie (hierboven gemaakt) als de back-end voor de API.

Selecteer in de AWS Management Console de API-gateway van de AWS-services en klik op de knop API maken

Selecteer op de pagina Nieuwe API maken Nieuwe API en voer webhooks in als de API-naam.
Klik op de knop API maken
Selecteer de vervolgkeuzelijst Acties en selecteer de optie Bron maken
Selecteer de optie Configureren als proxybron en voer valideren in bij Bronnaam en {proxy+} in het Bronpad
Selecteer de optie API Gateway CORS inschakelen niet en klik op de knop Bron maken
Houd de Lambda-functieproxy geselecteerd als integratietype en selecteer het gebied waar u de Lambda-functie hebt gemaakt in de vervolgkeuzelijst Lambda-gebied (waarschijnlijk is dat hetzelfde gebied waar u de API-gateway maakt).
Voer valideren in als de Lambda-functie en klik op de knop Opslaan
Selecteer in het pop-upvenster Toestemming toevoegen aan Lambda-functie OK

Als alle bovenstaande stappen correct zijn uitgevoerd, ziet u zoiets als dit:

API implementeren

De volgende stap is het implementeren van deze API, zodat deze klaar is voor gebruik.

Selecteer in de vervolgkeuzelijst Acties API implementeren
Selecteer [Nieuw stadium] in de Implementatiefase en voer prod (of iets anders waarmee u dit stadium wilt identificeren) in de Stadiumnaam in
Klik op de knop Implementeren

API is nu klaar voor gebruik en u kunt de aanroep-URL vinden in het blauwe vak, zoals hieronder weergegeven:

Let op deze URL, want u moet deze invoeren als uw realtimewebhook-URL.

Klaar voor gebruik

Het is gereed. Gebruik deze bovenstaande URL met "/{nodeJSfunctionName}" toegevoegd als webhook-url in POST /webhooks API-verzoek. Nadat u het gedrag hebt geverifieerd, is de webhook-URL functioneel volgens de
Acrobat Sign-normen. U kunt de aangepaste logica verder bijwerken/toevoegen volgens uw vereisten.

In- of uitschakelen

Toegang tot de webhookfunctie is standaard ingeschakeld voor accounts op ondernemingslaag.

Beheerders op groepniveau kunnen webhooks maken/controleren die alleen binnen de groep functioneren.

Als u de pagina Webhooks wilt openen, gaat u naar de linkerkant van het menu Beheer.

Limiet voor snelheid op basis van gelijktijdigheid

Het maken van webhooks, callbacks en meldingsgebeurtenissen zijn beperkt in het aantal gelijktijdige meldingen dat actief vanuit het Acrobat Sign-systeem aan de klant wordt afgeleverd. Deze limiet geldt voor het account, inclusief alle groepen binnen het account.
Dit type limiet voor snelheid voorkomt dat één slecht ontworpen account een onevenredige hoeveelheid serverresources verbruikt, waardoor alle andere klanten in die serveromgeving negatief worden beïnvloed.

Het aantal gelijktijdige gebeurtenissen per account is berekend om ervoor te zorgen dat accounts met goed beheerde webhooks meldingen in de kortst mogelijke tijd ontvangen en zelden te maken krijgen met een situatie waarin meldingen worden vertraagd door te veel aanvragen. De huidige drempels zijn:

Actie (gebeurtenis)	Maximumaantal gelijktijdige gebeurtenissen	Beschrijving
Creatie van een webhook	10	Er worden per account maximaal 10 gelijktijdige aanvragen voor het maken van een webhook toegestaan. Aanvragen die deze limiet overschrijden, resulteren in de antwoordcode 429 TOO_MANY_REQUESTS.
Webhook-/callbackmelding	30	Er zijn maximaal 30 gelijktijdige webhook- en callbackmeldingen per account toegestaan. Voor meldingen die deze limiet overschrijden, wordt een nieuwe poging gedaan volgens een exponentiele back-off totdat ze worden afgeleverd.

Best practices

Meld u aan voor specifieke, noodzakelijke gebeurtenissen om het aantal HTTPS-verzoeken aan de server te beperken - Hoe specifieker u uw webhooks kunt maken, hoe minder volume u hoeft door te nemen.
Bestand tegen duplicatie - Als u één en dezelfde webhook-URL deelt met meerdere apps, en als dezelfde gebruiker is toegewezen aan elke app, wordt dezelfde gebeurtenis meerdere keren naar uw webhook verzonden (één keer per app). In sommige gevallen kan uw webhook dubbele gebeurtenissen ontvangen. Uw webhooktoepassing moet hiermee kunnen omgaan en dedupliceren op gebeurtenis-ID.
Altijd snel antwoorden op webhooks - Uw app heeft slechts tien seconden om te reageren op webhookverzoeken. Voor het verificatieverzoek is dit slechts zelden een probleem, aangezien uw app hoeft geen echt werk hoeft te doen om te reageren. Bij meldingsverzoeken doet de app als reactie op het verzoek meestal iets dat tijd kost. Het wordt aanbevolen om met een wachtrij aan een aparte thread of asynchroon te werken om ervoor te zorgen dat u binnen vijf seconden kunt reageren
Gelijktijdigheid beheren - Wanneer een gebruiker snel achter elkaar een aantal veranderingen aanbrengt, ontvangt uw app waarschijnlijk meerdere meldingen voor dezelfde gebruiker op ongeveer hetzelfde tijdstip. Als u niet goed oplet bij het beheer van gelijktijdigheid, is het mogelijk dat de app dezelfde wijzigingen voor dezelfde gebruiker meermalen aanbrengt. Om te profiteren van Acrobat Sign-webhooks moet u een duidelijk begrip hebben van het gebruik van de informatie. Stel uzelf de volgende vragen:
- Welke gegevens wilt u retourneren in de payload?
- Wie heeft toegang tot deze informatie?
- Welke beslissing of rapportage wordt hierdoor gegenereerd?
Aanbevelingen voor het ontvangen van een ondertekend document - Er zijn verschillende factoren waarmee u rekening moet houden bij het bepalen hoe u een ondertekende PDF van Acrobat Sign in uw documentbeheersysteem ontvangt.

Hoewel het volkomen acceptabel is om gewoon de optie Overeenkomst van ondertekend document te selecteren tijdens het maken van een webhook, kunt u overwegen de Acrobat Sign-API te gebruiken om de documenten op te halen wanneer een activerende gebeurtenis (zoals de overeenkomststatus Voltooid) is ontvangen.

Dingen om rekening mee te houden...

Beperking van JSON-grootte

De grootte van de JSON-lading is beperkt tot 10 MB.

Als een gebeurtenis een grotere payload genereert, wordt een webhook geactiveerd, maar de attributen van voorwaardelijke parameters, als die aanwezig zijn in het verzoek, worden verwijderd om de payload te verkleinen.

Wanneer dit gebeurt, wordt 'ConditionalParametersTrimmed' in het antwoord geretourneerd om de client te informeren dat de informatie over de conditionalParameters is verwijderd.

“conditionalParametersTrimmed” is een array-object met informatie over de sleutels die zijn afgekapt.

De afkapping vindt plaats in de onderstaande volgorde:

includeSignedDocuments
includeParticipantsInfo
includeDocumentsInfo
includeDetailedInfo

De ondertekende documenten worden eerst worden afgekapt, gevolgd door deelnemerinformatie op, documentgegevens en de uiteindelijke gedetailleerde informatie.

Dit kan bijvoorbeeld op een gebeurtenis ook gebeuren als het agreement ondertekend document (versleutelde grondtal 64) of voor een agreement met meerdere formuliervelden bevat

Webhook-meldingen

Acrobat Sign-webhooks leveren meldingen aan de afzender van de overeenkomst, en aan elke webhook die is geconfigureerd binnen de groep van waaruit de overeenkomst is verzonden. Webhooks met accountbereik ontvangen alle gebeurtenissen.

Afzender: Gebruiker A | Ondertekenaar: Gebruiker B | Gedeeld met: Gebruiker C

Gebruiker A en gebruiker B hebben verschillende accounts

Gebruiker A en gebruiker C hebben verschillende accounts

Gebruiksscenario	Melding?	Opmerkingen/opmerkingen
Het account van gebruiker A heeft een webhook op ACCOUNT-niveau (gemaakt door gebruiker A of de accountbeheerder).	Ja	Een webhook op ACCOUNT-niveau wordt op de hoogte gebracht van alle gebeurtenissen die in dat account zijn geactiveerd.
Het account van gebruiker A heeft een webhook op GROEP-niveau (gemaakt door gebruiker A of de account/groepsbeheerder). Veronderstelling: Gebruiker A en de groepsbeheerder zitten in dezelfde groep.	Ja	Een webhook op GROEP-niveau wordt op de hoogte gebracht van alle gebeurtenissen die in die groep zijn geactiveerd.
Gebruiker A heeft een webhook op GEBRUIKER-niveau.	Ja	Als afzender, wordt de webhook van gebruiker A op GEBRUIKER-niveau geactiveerd
Gebruiker A heeft een webhook op BRON-niveau (voor de bovenstaande verzonden overeenkomst).	Ja

Het account van gebruiker B heeft een webhook op ACCOUNT-niveau (gemaakt door gebruiker B of de accountbeheerder).	Nee	De webhook van gebruiker B op ACCOUNT-niveau wordt beschouwd als een ondertekenaar-webhook.
Het account van gebruiker B heeft een webhook op GROEP-niveau (gemaakt door gebruiker B of de account/groepsbeheerder). Veronderstelling: Gebruiker B en de groepsbeheerder zitten in dezelfde groep.	Nee	De webhook van gebruiker B op GROEP-niveau wordt beschouwd als een ondertekenaar-webhook.
Gebruiker B heeft een webhook op GEBRUIKER-niveau.	Nee	De webhook van gebruiker B op GEBRUIKER-niveau wordt beschouwd als een ondertekenaar-webhook.

Het account van gebruiker C heeft een webhook op ACCOUNT-niveau (gemaakt door gebruiker C of de accountbeheerder).	Nee	De webhook van gebruiker C op ACCOUNT-niveau wordt beschouwd als een webhook die niet afkomstig is van de oorspronkelijke maker.
Het account van gebruiker C heeft een webhook op GROEP-niveau (gemaakt door gebruiker C of de account/groepsbeheerder). Veronderstelling: Gebruiker C en de groepsbeheerder zitten in dezelfde groep.	Nee	De webhook van gebruiker C op GROEP-niveau wordt beschouwd als een webhook die niet afkomstig is van de oorspronkelijke maker.
Gebruiker C heeft een webhook op GEBRUIKER-niveau.	Nee	De webhook van gebruiker C op GEBRUIKER-niveau wordt beschouwd als een webhook die niet afkomstig is van de oorspronkelijke maker.

Afzender: Gebruiker A | Ondertekenaar: Gebruiker B | Gedeeld met: Gebruiker C

Gebruiker A, gebruiker B en gebruiker C zitten in hetzelfde account

Gebruiksscenario	Melding?	Opmerkingen
Het account van gebruiker A heeft een webhook op ACCOUNT-niveau (gemaakt door gebruiker A of de accountbeheerder).	Ja	Webhooks op ACCOUNT-niveau melden gebeurtenissen die door het account worden geactiveerd.
Het account van gebruiker A heeft een webhook op GROEP-niveau (gemaakt door gebruiker A of de account/groepsbeheerder). Veronderstelling: Gebruiker A en de groepsbeheerder zitten in dezelfde groep.	Ja	Webhooks op GROEP-niveau melden gebeurtenissen die worden geactiveerd door de gebruikers in hun groep.
Gebruiker A heeft een webhook op GEBRUIKER-niveau.	Ja	Als afzender, wordt de webhook van gebruiker A op GEBRUIKER-niveau geactiveerd
Gebruiker A heeft een webhook op BRON-niveau (voor de bovenstaande verzonden overeenkomst).	Ja

Het account van gebruiker B heeft een webhook op ACCOUNT-niveau (gemaakt door gebruiker B of de accountbeheerder).	Ja	Aangezien gebruiker A en gebruiker B zich in hetzelfde account bevinden, worden webhooks op ACCOUNT-niveau op de hoogte gebracht van alle gebeurtenissen die in dat account worden geactiveerd.
Het account van gebruiker B heeft een webhook op GROEP-niveau (gemaakt door gebruiker B of de account/groepsbeheerder). Veronderstelling: Gebruiker A, gebruiker B en de groepsbeheerder zitten in dezelfde groep.	Ja	Aangezien gebruiker A en gebruiker B zich in dezelfde groep bevinden, wordt een webhook op GROEP-niveau op de hoogte gebracht van alle gebeurtenissen die in die groep worden geactiveerd.
Het account van gebruiker B heeft een webhook op GROEP-niveau (gemaakt door gebruiker B of de account/groepsbeheerder). Veronderstelling: Gebruiker A en gebruiker B zitten in andere groepen.	Nee	De webhook van gebruiker B op GROEP-niveau wordt beschouwd als een ondertekenaar-webhook. De webhook van gebruiker A (BRON/GEBRUIKER/GROEP/ACCOUNT) wordt geactiveerd.
Gebruiker B heeft een webhook op GEBRUIKER-niveau.	Nee	Als ontvanger wordt de webhook van gebruiker B op GEBRUIKER-niveau niet geactiveerd.

Het account van gebruiker C heeft een webhook op ACCOUNT-niveau (gemaakt door gebruiker C of de accountbeheerder).	Ja	Aangezien gebruiker A en gebruiker C zich in hetzelfde account bevinden, worden webhooks op ACCOUNT-niveau op de hoogte gebracht van alle gebeurtenissen die in dat account worden geactiveerd.
Het account van gebruiker C heeft een webhook op GROEP-niveau (gemaakt door gebruiker C of de account/groepsbeheerder). Veronderstelling: Gebruiker A, gebruiker C en de groepsbeheerder zitten in dezelfde groep.	Ja	Aangezien gebruiker A en gebruiker C zich in dezelfde groep bevinden, wordt een webhook op GROEP-niveau op de hoogte gebracht van alle gebeurtenissen die in die groep worden geactiveerd.
Het account van gebruiker C heeft een webhook op GROEP-niveau (gemaakt door gebruiker C of de account/groepsbeheerder). Veronderstelling: Gebruiker A en gebruiker C zitten in andere groepen.	Nee	De webhook van gebruiker C op GROEP-niveau wordt beschouwd als een webhook die niet afkomstig is van de oorspronkelijke maker. De webhook van gebruiker A (BRON/GEBRUIKER/GROEP/ACCOUNT) wordt geactiveerd.
Gebruiker C heeft een webhook op GEBRUIKER-niveau.	Nee	De webhook van gebruiker C op GEBRUIKER-niveau wordt beschouwd als een webhook die niet afkomstig is van de oorspronkelijke maker.

Probeer het opnieuw wanneer de listening-service niet beschikbaar is

Als de doel-URL voor de webhook om welke reden dan ook niet beschikbaar is, zal Acrobat Sign de JSON in de wachtrij plaatsen en de push opnieuw proberen in een progressieve cyclus van 72 uur.

De niet-afgeleverde gebeurtenissen worden bewaard in een wachtrij voor opnieuw proberen en er wordt de komende 72 uur alles aan gedaan om de meldingen af te leveren in de volgorde waarin ze zijn opgetreden.

De strategie voor het opnieuw proberen van de levering van meldingen is een verdubbeling van de tijd tussen pogingen, beginnend met een interval van 1 minuut oplopend tot elke 12 uur, wat resulteert in 15 nieuwe pogingen in een tijdsbestek van 72 uur.

Als de webhookontvanger niet binnen 72 uur reageert en er in de afgelopen zeven dagen geen succesvolle leveringen van meldingen zijn geweest, wordt de webhook uitgeschakeld. Geen meldingen worden naar dit URL opnieuw verzonden tot webhook wordt geactiveerd.

Alle meldingen webhook tussen het moment is uitgeschakeld en het later opnieuw ingeschakeld, zullen verloren gaan.

Krijg sneller en gemakkelijker hulp

Nieuwe gebruiker?

Overzicht van Acrobat Sign-webhooks

Overzicht

Vereisten

Gebruik

Verificatie van de bedoeling van de webhook -URL

Reageren op een webhookmelding

1. HTTP-koptekst X-AdobeSign-ClientId en de waarde van deze client-ID

2. JSON-hoofdtekst van de respons met de sleutel xAdobeSignClientId en de waarde van dezelfde client-ID

Vereisten

Stappen voor het maken van een Azure Functions-trigger die fungeert als Acrobat Sign-webhook

Logica toevoegen voor registratie van de Acrobat Sign-webhook

Optie 1: De client-ID in X-AdobeSign-ClientId doorgeven als koptekst van de respons

Optie 2: De client-ID doorgeven in de hoofdtekst van het antwoord met de sleutel xAdobeSignClientId

Klaar voor gebruik

De AWS Lambda-functie maken

Geval 1: Client-ID doorgeven in X-AdobeSign-ClientId als koptekst van de respons

Geval 2: Client-ID doorgeven in de hoofdtekst van de respons met de sleutel xAdobeSignClientId

De AWS API-gateway configureren

API implementeren

Klaar voor gebruik

In- of uitschakelen

Limiet voor snelheid op basis van gelijktijdigheid

Best practices

Dingen om rekening mee te houden...

Beperking van JSON-grootte

Webhook-meldingen

Probeer het opnieuw wanneer de listening-service niet beschikbaar is

Krijg sneller en gemakkelijker hulp

Vraag het de community

Contact met ons opnemen