Ta ett exempel på JavaScript-kod för att hämta klient-ID, validera det och returnera det sedan i svarshuvudet
- Installera paketet
- Konfigurera paketet
- Användarhandbok
- Aktivera digital autentisering
- Användarhandbok för utvecklare
- Handbok om avancerad anpassning
- Användarhandbok för fältmappning och mallar
- Användarhandbok för den mobila appen
- Flödesautomatiseringsguide
- Användarhandbok för Document Builder
- Konfigurera stora dokument
- Användarhandbok för uppgraderingar
- Versionsinformation
- Svar på vanliga frågor
- Felsökningsguide
- Ytterligare artiklar
- Acrobat Sign för Microsoft 365
- Acrobat Sign för Outlook
- Acrobat Sign för Word/PowerPoint
- Acrobat Sign för Teams
- Acrobat Sign för Microsoft PowerApps och Power Automate
- Acrobat Sign Connector för Microsoft Search
- Acrobat Sign för Microsoft Dynamics
-
Acrobat Sign för Microsoft SharePoint
- Översikt
- SharePoint On-Prem: installationshandbok
- SharePoint On-Prem: användarhandbok för mallmappning
- SharePoint On-Prem: användarhandbok
- SharePoint On-Prem: versionsinformation
- SharePoint Online: installationshandbok
- SharePoint Online: användarhandbok för mallmappning
- SharePoint Online: användarhandbok
- SharePoint Online: användarhandbok för mappning av webbformulär
- SharePoint Online: versionsinformation
- Adobe Acrobat Sign-integreringar
- Produktversioner och livscykel
-
Acrobat Sign för Salesforce
- Installera paketet
- Konfigurera paketet
- Användarhandbok
- Aktivera digital autentisering
- Användarhandbok för utvecklare
- Handbok om avancerad anpassning
- Användarhandbok för fältmappning och mallar
- Användarhandbok för den mobila appen
- Flödesautomatiseringsguide
- Användarhandbok för Document Builder
- Konfigurera stora dokument
- Användarhandbok för uppgraderingar
- Versionsinformation
- Svar på vanliga frågor
- Felsökningsguide
- Ytterligare artiklar
-
Acrobat Sign för Microsoft
- Acrobat Sign för Microsoft 365
- Acrobat Sign för Outlook
- Acrobat Sign för Word/PowerPoint
- Acrobat Sign för Teams
- Acrobat Sign för Microsoft PowerApps och Power Automate
- Acrobat Sign Connector för Microsoft Search
- Acrobat Sign för Microsoft Dynamics
-
Acrobat Sign för Microsoft SharePoint
- Översikt
- SharePoint On-Prem: installationshandbok
- SharePoint On-Prem: användarhandbok för mallmappning
- SharePoint On-Prem: användarhandbok
- SharePoint On-Prem: versionsinformation
- SharePoint Online: installationshandbok
- SharePoint Online: användarhandbok för mallmappning
- SharePoint Online: användarhandbok
- SharePoint Online: användarhandbok för mappning av webbformulär
- SharePoint Online: versionsinformation
- Acrobat Sign för ServiceNow
- Acrobat Sign för HR ServiceNow
- Acrobat Sign för SAP SuccessFactors
- Acrobat Sign för Workday
- Acrobat Sign för NetSuite
- Acrobat Sign för SugarCRM
- Acrobat Sign för VeevaVault
- Acrobat Sign för Coupa BSM Suite
- Acrobat Sign för Zapier
Ö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.
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.
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:
Så fungerar 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.
Konfigurationsalternativ
Konfigurering av webhook kräver att fem element definieras:
- Namn – ett intuitivt namn som andra administratörer lätt kan förstå föreslås.
- Omfång – hur brett nätet är som används av en webhook? Kontot och gruppen är tillgängliga i gränssnittet.
- API:et stöder omfattningar för konto, grupper, användare och resurser.
- Endast ett omfång per webhook kan definieras.
- URL – mål-URL:en som Acrobat Sign skickade JSON-nyttolasten till.
- Händelser – utlösaren som gör att Acrobat Sign skapar JSON och skickar den till avsedd URL.
- Varje händelse skapar en egen nyttolast som är relevant för den utlösande händelsen.
- Flera Händelser kan inkluderas i en webhook.
- Meddelandeparametrar – meddelandeparametrarna identifierar de delar av Händelsens JSON-nyttolast, så att du kan välja endast de avsnitt som är viktiga för denna webhook i Händelsen (och därmed minska onödig data som skickas till URL:en).
När en webhook är helt definierad, klicka på Spara, och denna nya webhook börjar direkt reagera på utlösande händelser.
Konfigurera webhook-URL:en för att svara på begäranden om webhook-verifiering och webhook-meddelanden enligt verifieringsprotokoll ovan. Det klient-ID (program-ID) som skickas till webhooks som skapas från webbapplikationen Acrobat Sign, är – UB7E5BXCXY
Omfång
- Konto: Alla prenumerationshändelser som inträffar på kontot utlöser push-åtgärden.
- Kontoadministratörer har behörighet att se alla webbhookar definierade för kontot och alla grupper i kontot.
- Grupp: Alla prenumerationshändelser som inträffar i gruppen utlöser push-åtgärden. OBS! Webbhookar med gruppomfång finns bara för den gruppen.
- Gruppadministratörer kan bara se webhookar som är dedikerade till deras grupp. De kan inte se webbhooks på kontonivå eller webhooks som är bundna till andra grupper.
- Konton som har Användare i flera grupper aktiverat, ser alternativet att ange gruppen som omfånget ska tillämpas på.
- Användarkonto: Alla prenumerationshändelser för ett användarkonto utlöser push-åtgärd. Webhooks på användarnivå kan bara skapas via API.
- Webhook på resursnivå: Detta skapas för en specifik resurs. Händelser som är specifika för denna resurs överförs till aktuell webhook-URL. Webhookar på resursnivå kan bara skapas via API.
URL
En webhook-URL är en server som lyssnar efter inkommande HTTPS-POST-aviseringar som utlöses när händelser inträffar.
Du behöver denna URL för att prenumerera på webhook för händelser.
- Klienten måste innehålla en HTTPS URL som Acrobat Sign kan skicka POST-aviseringar till. Denna URL måste vara tillgänglig på offentligt Internet.
- Till exempel kommer 127.0.0.1 och localhost-URI:er inte att fungera.
- URL-slutpunkten måste lyssna på port 443 eller 8443 (bestäms av kunden när återanrops-URL:en definieras).
- Se till att webhooken stöder POST-förfrågningar för inkommande händelseaviseringar och GET-förfrågningar för verifieringsförfrågan.
- Webbadressen bör inte blockeras av en brandvägg.
Nedan visas de händelser som kan utlösa en push till webhook-URL:en, grupperade efter objekt och listade i den ordning som finns i användargränssnittet.
Värdet till vänster är det som visas i användargränssnittet i Acrobat Sign. Värdet till höger är webhookens namn i API:et.
Fullständig information om webbhookarna och deras nyttolaster finns i Utvecklarhandbok för Acrobat Sign.
Avtal:
Användargränssnittelement | Webhooknamn |
Avtal med alla händelser | AGREEMENT_ALL |
Avtalet har skapats | AGREEMENT_CREATED |
Avtal skickat | AGREEMENT_ACTION_REQUESTED |
Avtalsdeltagaren har slutfört | AGREEMENT_ACTION_COMPLETED |
Arbetsflöde för avtal slutfört | AGREEMENT_WORKFLOW_COMPLETED |
Avtalet har upphört att gälla | AGREEMENT_EXPIRED |
Avtalet har tagits bort | AGREEMENT_DOCUMENTS_DELETED |
Avtalet har avbrutits | AGREEMENT_RECALLED |
Avtalet har avvisats | AGREEMENT_REJECTED |
Avtalet har delats | AGREEMENT_SHARED |
Avtalet har delegerats | AGREEMENT_ACTION_DELEGATED |
Avtalsdeltagare har ersatts | AGREEMENT_ACTION_REPLACED_SIGNER |
Avtal har ändrats | AGREEMENT_MODIFIED |
Ändring av avtal har bekräftats | AGREEMENT_USER_ACK_AGREEMENT_MODIFIED |
Avtalets e-postmeddelande har lästs | AGREEMENT_EMAIL_VIEWED |
Avtalets e-postmeddelande studsade | AGREEMENT_EMAIL_BOUNCED |
Avtalet kunde inte skapas | AGREEMENT_AUTO_CANCELLED_CONVERSION_PROBLEM |
Avtal synkroniserades efter offline-händelse | AGREEMENT_OFFLINE_SYNC |
Avtalet har överförts av avsändaren | AGREEMENT_UPLOADED_BY_SENDER |
Avtalet placerat i valvet | AGREEMENT_VAULTED |
Avtalsdeltagarens sociala ID har autentiserats | AGREEMENT_WEB_IDENTITY_AUTHENTICATED |
Avtalsdeltagaren är KBA-autentiserad | AGREEMENT_KBA_AUTHENTICATED |
Avtalspåminnelse har skickats | AGREEMENT_REMINDER_SENT |
Namnet på avtalets signerare har ändrats av signeraren | AGREEMENT_SIGNER_NAME_CHANGED_BY_SIGNER |
Avtalswebbhookar är endast tillgängliga via API | |
Ej tillämpligt | AGREEMENT_EXPIRATION_UPDATED |
Ej tillämpligt |
AGREEMENT_READY_TO_NOTARIZE |
Ej tillämpligt |
AGREEMENT_READY_TO_VAULT |
Massutskick:
Användargränssnittelement | Webhooknamn |
Massutskicka alla händelser | MEGASIGN_ALL |
Massutskick skapade |
MEGASIGN_CREATED |
Massutskick delade |
MEGASIGN_SHARED |
Massutskick återkallat |
MEGASIGN_RECALLED |
Webbformulär:
Användargränssnittelement | Webhooknamn |
Alla händelser för webbformulär | WIDGET_ALL |
Webbformuläret har skapats |
WIDGET_CREATED |
Webbformuläret har aktiverats |
WIDGET_ENABLED |
Webbformuläret har inaktiverats |
WIDGET_DISABLED |
Webbformuläret har ändrats |
WIDGET_MODIFIED |
Webbformuläret har delats |
WIDGET_SHARED |
Det gick inte att skapa ett webbformulär |
WIDGET_AUTO_CANCELLED_CONVERSION_PROBLEM |
Biblioteksmallar (endast API):
Användargränssnittelement | Webhooknamn |
Ej tillämpligt | LIBRARY_DOCUMENT_ALL |
Ej tillämpligt | LIBRARY_DOCUMENT_CREATED |
Ej tillämpligt | LIBRARY_DOCUMENT_AUTO_CANCELLED_CONVERSION_PROBLEM |
Ej tillämpligt | LIBRARY_DOCUMENT_MODIFIED |
Meddelandeparametrar
Med meddelandeparametrar kan du anpassa JSON-nyttolasten till specifika element i händelsen.
I en händelse av Avtalsdeltagare ersatt kanske du bara vill ha Avtalsinformation och Deltagarinformation och utelämna Dokumentinformation, och minska den totala storleken på den JSON som skickas i webhook-URL:en.
- Avtal
- Avtalsinformation – detaljerad avtalsinformation baserad på avtalets status vid tidpunkten för den utlösande händelsen.
- Dokumentinformation för avtal – inkluderar all dokumentinformation som genereras som ett resultat av händelsen.
- Information om avtalsdeltagare – inkluderar all deltagarinformation som ett resultat av händelsen.
- Signerat avtalsdokument – tillhandahåller den signerade PDF-filen.
- Gäller händelserna Avtalsarbetsflödet har slutförts och Alla avtal.
- Massutskick
- Information om massutskick – detaljerad information om det Massutskickobjekt som utlöste händelsen.
- Webbformulär
- Widgetinformation – detaljerad information om webbformuläret som utlöste händelsen.
- Information om Widget-dokument – dokumentinformationen som är associerad med webbformuläret.
- Widget-deltagarinformation – information om definierade deltagare i webbformuläret.
Tvåvägs SSL-autentisering
Tvåvägs-SSL, ofta kallad Client-Side SSL eller ömsesidig TLS, är ett SSL-läge där både servern och klienten (webbläsaren) presenterar certifikat för att identifiera sig själva.
Kontoadministratörer kan konfigurera ett klientcertifikat på sidan Säkerhetsinställningar.
Acrobat Sign verifierar SSL-certifikat vid leverans av nyttolaster till webhook-URL. Webhookar som misslyckas med SSL-certifikatverifiering kan inte leverera JSON-nyttolast.
Använd tvåvägs SSL för att autentisera klienten (Acrobat Sign) och lyssningstjänsten för att säkerställa att endast Acrobat Sign kan nå webhook-URL:en.
Om en webhook skapades av ett Partnerprogram kommer denna webhook att använda ett klientcertifikat (om tillgängligt) från partnerprogrammets konto för att identifiera sig själv när den skickar webhook-meddelanden.
Nedan visas de vanligaste frågorna för både verifiering av webbserver och verifiering av klientcertifikat.
Webbserververifiering
När en webhook registreras verifierar Acrobat Sign webhookserverns URL.
Kunder kommer inte att kunna registrera webhooken om anslutningen till webhookens återanrops-URL inte kan slutföras från Acrobat Sign.
Verifiering av klientcertifikat
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 webhooks som fungerar inom gruppen.
Åtkomst till sidan Webhooks finns i den vänstra listen på Admininistrationsmenyn: Konto > Webhooks
Aktivera en webhook
När en webhook skapas första gången, skapas den med en Aktiv status.
På sidan webhooks i Acrobat Sign visas aktiva webhooks som standard.
Så här aktiverar du en inaktiv webhook:
- Klicka på ikonen Alternativ (tre vågräta linjer) till höger om rubrikraden webhooks och välj Visa alla webbhooks
- Klicka en gång på en inaktiv webhook för att markera den
- Detta visar alternativen för aktuell webhook precis under rubrikraden
- Klicka på Aktivera
En aktiv webhook börjar skicka data till mål-URL så snart nästa händelse utlöses.
Inaktivera en webhook
För att inaktivera en webhook behöver du
- Gå till sidan Webhooks
- Klicka på den webhook du vill inaktivera
- Välj Inaktivera från menyalternativen under rubrikraden
- När den är inaktiverad visas satus för webhook som Inaktiv
Visa eller redigera en webhook
Webhooks kan redigeras och sparas när som helst. När en ny konfiguration sparas träder ändringen i kraft omedelbart.
Endast Händelser och Meddelandeparametrar kan redigeras.
Om Namn, Omfång eller URL måste ändras, måste en ny webhook skapas.
Så här redigerar du parametrar för en webhook:
- Gå till sidan Webhooks
- Klicka på den webhook du vill redigera
- Klicka på alternativet Visa/redigera under rubrikraden
- Tillämpa eventuella ändringar och klicka på Spara
Ta bort en webhook
En webhook kan när som helst tas bort.
Om du tar bort en webhook förstörs den i systemet, så det går inte att återställa en borttagen webhook.
Webhooks behöver inte inaktiveras först.
Så här tar du bort en webhook:
- Gå till Webhooks
- Välj den webhook som du vill ta bort genom att klicka på den
- Klicka på alternativet Radera under rubrikraden
- En kontroll visas för att säkerställa att du vill ta bort en webhook. klicka på OK
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
Webhook-meddelanden
Acrobat Sign webhooks levererar meddelanden som gäller för alla deltagare i ett avtal om det finns en webhook som är konfigurerad för den användaren, deras grupp eller deras konto.
Avtalshändelser behandlas på ett sådant sätt att om det finns en webhook konfigurerad för den tillämpliga deltagaren i den händelsen, skickas ett meddelande till aktuell webhook-URL. Med andra ord aktiveras webhooks för händelser i alla tillämpliga avtal, även utanför den grupp eller det konto för vilken aktuell webhook är konfigurerad.
Meddelanden levereras endast för de händelser som deltagaren är involverad i. T.ex. Avsändare av ett avtal får nästan varje meddelande, medan Mottagare endast får meddelanden från början av deras deltagande i avtalet, och endast för de händelser som de är inblandade i.
Webhook-meddelanden följer den aktuella autentiserings- och synlighetsmodellen för själva Acrobat Sign, vilket innebär att användare endast har åtkomst till avtalet när användarens deltagande i ett avtal har påbörjats.
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.