Přehled webhooků služby Acrobat Sign

Naposledy aktualizováno 8. 7. 2026

Přehled

Webhook je uživatelem definovaná žádost protokolu HTTPS, která je aktivována, když se na zdrojovém webu (v tomto případě Adobe Acrobat Sign) vyskytne odebíraná událost.

Ve skutečnosti není webhook nic jiného než služba REST, která přijímá data nebo proud dat.

Webhooky jsou určeny ke komunikaci mezi službamimodelu PUSH (doručování bez vyžádání).

Když je aktivována odebíraná událost, služba Acrobat Sign vytvoří žádost HTTPS POST s tělem JSON a doručí ji na stanovenou adresu URL.

Před konfigurací webhooků se ujistěte, že vaše síť přijme rozsahy adres IP potřebné k fungování.

 

Webhooky nabízejí oproti předchozí metodě zpětného volání řadu výhod, mezi které mimo jiné patří:

  • Správci mohou povolit webhooky, aniž by museli zahrnout podporu služby Acrobat Sign do vypisování adresy URL zpětného volání
  • Webhooky jsou lepší z hlediska „čerstvosti“ dat, efektivity komunikace a zabezpečení. Není vyžadováno dotazování
  • Webhooky umožňují snadno používat různé úrovně rozsahu (účet/skupina/uživatel/zdroj). 
  • Webhooky představují modernější řešení rozhraní API, které umožňuje přímočařeji konfigurovat moderní aplikace
  • Pro každý rozsah (účet/skupina/uživatel/zdroj) lze nakonfigurovat více webhooků, zatímco předchozí zpětná volání musela být jedinečná
  • Webhooky umožňují provést výběr dat, která mají být vrácena, zatímco předchozí zpětná volání jsou řešení typu „všechno nebo nic“
  • Metadata přenášená s webhookem lze konfigurovat (základní nebo podrobná)
  • Webhooky lze podle potřeby snáze vytvářet, upravovat nebo deaktivovat, protože uživatelské rozhraní je zcela pod kontrolou správce.
Poznámka

Tento dokument je primárně zaměřen na uživatelské rozhraní pro webhooky ve webové aplikaci Acrobat Sign (dříve Adobe Sign).

Vývojáři, kteří hledají podrobné informace o rozhraní API, je mohou nalézt zde:

Předpoklady

Aby služba fungovala, musíte povolit rozsahy adres IP pro webhooky prostřednictvím zabezpečení sítě.

Starší služba URL pro zpětné volání v REST v5 využívá stejné rozsahy IP jako služba webhook.

Správci se mohou přihlásit do konzole Adobe Admin Console a přidat uživatele. Po přihlášení přejděte do nabídky správce a přejděte dolů do části Webhooky.

Jak se používá

Správci budou muset nejprve disponovat službou webhooku, která bude připravena přijímat příchozí nabídky ze služby Acrobat Sign. V tomto ohledu existuje mnoho možností, a dokud služba dokáže přijímat požadavky POST a GET, bude webhook úspěšný.

Jakmile je služba zavedena, může správce služby Acrobat Sign vytvořit nový webhook z rozhraní Webhook v nabídce Účet na webu služby Acrobat Sign.

Správci mohou nakonfigurovat webhook pro aktivaci událostí Dohoda, Webový formulář (Widget) nebo Hromadné odeslání (MegaSign). Prostřednictvím rozhraní API lze nakonfigurovat také zdroj šablony knihovny (dokumentu knihovny).

Rozsah webhooku může zahrnovat celý účet nebo jednotlivé skupiny prostřednictvím rozhraní správce. Rozhraní API umožňuje dosáhnout větší míry podrobnosti prostřednictvím výběru rozsahu UŽIVATEL nebo ZDROJ.

Typ dat, která jsou odesílána na adresu URL, je konfigurovatelný a může zahrnovat položky, jako jsou Informace o dohodě, Informace o účastníkovi, Informace o dokumentu atd.

Jakmile je webhook nakonfigurován a uložen, služba Acrobat Sign odešle nový objekt JSON na definovanou adresu URL pokaždé, když dojde k aktivaci odebírané události. Pokud nechcete změnit aktivační kritéria události nebo datovou část JSON, není vyžadována žádná průběžná manipulace s webhookem.

Ověření záměru adresy URL webhooku

Před úspěšnou registrací webhooku služba Acrobat Sign ověří, zda adresa URL webhooku, která je uvedena v žádosti o registraci, zamýšlí přijímat oznámení, nebo nikoli. Za tímto účelem služba Acrobat Sign po obdržení nové žádosti o registraci webhooku nejprve požádá o ověření adresy URL webhooku. Tato žádost o ověření je odeslána na adresu URL webhooku ve formě požadavku HTTPS GET. Tento požadavek má vlastní hlavičku HTTP X-AdobeSign-ClientId. Hodnota v této hlavičce je nastavena na ID klienta (ID aplikace) aplikace API požadující vytvoření/registraci webhooku. K dosažení úspěšné registrace webhooku musí adresa URL webhooku odpovědět na žádost o ověření kódem odpovědi 2XX A navíc MUSÍ odeslat zpět stejnou hodnotu ID klienta jedním z následujících dvou způsobů:

  • Buď v hlavičce odpovědi X-AdobeSign-ClientId. Jedná se o stejnou hlavičku, která byla předána v požadavku, a nyní bude vrácena v odpovědi.
  • Nebo v těle odpovědi JSON pomocí klíče xAdobeSignClientId, jehož hodnota se shoduje s ID klienta odeslaným v požadavku.

Webhook bude úspěšně zaregistrován pouze při úspěšné odpovědi (kódu odpovědi 2XX) a ověření ID klienta buď v hlavičce, nebo v těle odpovědi. Účelem této žádosti o ověření je prokázat, že adresa URL webhooku chce přijímat oznámení na této adrese URL. Pokud byste omylem zadali nesprávnou adresu URL, adresa URL by neodpověděla správně na požadavek ověření záměru a služba Acrobat Sign by na tuto adresu URL nezasílala žádná oznámení. Kromě toho může adresa URL webhooku také potvrdit, že bude přijímat oznámení pouze prostřednictvím webhooků registrovaných konkrétní aplikací. To lze provést ověřením ID klienta aplikace předaného v hlavičce X-AdobeSign-ClientId. Pokud adresa URL webhooku nerozpozná toto ID klienta, NESMÍ odpovědět kódem úspěšné odpovědi a služba Acrobat Sign zajistí, aby tato adresa URL nebyla zaregistrována jako webhook.

Ověření volání adresy URL webhooku se provede v následujících situacích:

  • Registrace webhooku: Pokud toto ověření volání adresy URL webhooku selže, webhook nebude vytvořen.
  • Aktualizace webhooku ze stavu NEAKTIVNÍ na stav AKTIVNÍ: Pokud toto ověření volání adresy URL webhooku selže, stav webhooku nebude změněn na AKTIVNÍ.

Jak reagovat na oznámení webhooku

Služba Acrobat Sign provádí implicitní ověření záměru v každém požadavku na oznámení webhooku odeslaném na adresu URL webhooku. Každý požadavek HTTPS na oznámení webhooku proto obsahuje také vlastní hlavičku HTTP s názvem X-AdobeSign-ClientId. Hodnotou této hlavičky je ID klienta (ID aplikace) aplikace, která webhook vytvořila. Oznámení webhooku bude považováno za úspěšně doručené pouze v případě, že bude vrácena úspěšná odpověď (kód odpovědi 2XX) a bude odesláno ID klienta buď v hlavičce HTTP (X-AdobeSign-ClientId), nebo v těle odpovědi JSON pomocí klíče xAdobeSignClientId, přičemž bude shodné s ID klienta z požadavku, jinak se budeme snažit doručit oznámení na adresu URL webhooku až do vyčerpání přípustného počtu opakování.

Jak bylo uvedeno výše pro hlavičku X-AdobeSign-ClientId, která je obsažena v každém požadavku na oznámení ze služby Sign, hodnota této hlavičky (ID klienta) by měla být v odpovědi zopakována jedním ze dvou způsobů:

1. Hlavička HTTP X-AdobeSign-ClientId a hodnota shodná s tímto ID klienta

Ukázka kódu v jazyku JavaScript pro načtení ID klienta, jeho ověření a následné vrácení v hlavičce odpovědi

// Fetch client id

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

 

//Validate it

if (clientid ==="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

    //Return it in response header

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

    response.status = 200;  // default value

}

Ukázka kódu PHP pro načtení ID klienta, jeho ověření a následné vrácení v hlavičce odpovědi

<?php

// Fetch client id

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Validate it

if($clientid == "BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

    //Return it in response header

   header("X-AdobeSign-ClientId:$clientid");

   header("HTTP/1.1 200 OK"); // default value

}

?>


2. Tělo odpovědi JSON s klíčem xAdobeSignClientId a hodnotou shodnou s ID klienta

Ukázka kódu v jazyku JavaScript pro načtení ID klienta, jeho ověření a následné vrácení v těle odpovědi

// Fetch client id

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

 

 

//Validate it

if (clientid ==="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

    var responseBody = {

                         "xAdobeSignClientId" : clientid // Return Client Id in the body

                       };

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

    response.body = responseBody;

    response.status = 200;

}

Ukázka kódu PHP pro načtení ID klienta, jeho ověření a následné vrácení v těle odpovědi

<?php

// Fetch client id

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Validate it

if($clientid == "BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

{

   //Return it in response body

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

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

   echo json_encode($body);

   header("HTTP/1.1 200 OK"); // default value

}

?>

Ukázka těla odpovědi JSON

{

    "xAdobeSignClientId": "BGBQIIE7H253K6"

}

Předpoklady

Budete potřebovat:

  1. Účet Microsoft s licencí pro vytváření aplikací Azure Functions
  2. Existující aplikaci Azure Function, kterou můžete vytvořit podle pokynů uvedených na adrese https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-azure-function
  3. Základní znalost jazyka JavaScript, abyste dokázali pochopit a napsat kód v libovolném jazyce podle svého výběru

Postup vytvoření aktivační události pro Azure Functions, která slouží jako webhook služby Acrobat Sign

Vytvoření funkce Aktivační událost HTTP v jazyku JavaScript:

1. Přihlaste se prostřednictvím účtu Microsoft https://portal.azure.com/

2. Otevřete aplikaci Azure Function zobrazenou na kartě Aplikace funkcí.

Přechod na kartu Aplikace funkcí v Azure

Tím otevřete seznam aplikací Azure Function:

3. Vyberte aplikaci, ve které chcete vytvořit tuto novou funkci

4. Klikněte na tlačítko Vytvořit (+) a vytvořte novou funkci Azure

Vytvoření funkce Azure

 

5. Vyberte možnost Webhook + API jako scénář a možnost JavaScript jako jazyk

6. Klikněte na tlačítko Vytvořit tuto funkci

Vytvoří se nová funkce, která dokáže zpracovat příchozí požadavek rozhraní API.

Přidání logiky pro registraci webhooku služby Acrobat Sign

Před úspěšnou registrací webhooku služba Acrobat Sign ověří, zda adresa URL webhooku, která je uvedena v žádosti o registraci, skutečně zamýšlí přijímat oznámení, nebo nikoli. Za tímto účelem služba Acrobat Sign při obdržení nového požadavku na registraci webhooku nejprve požádá o ověření adresy URL webhooku. Tato žádost o ověření je odeslána na adresu URL webhooku ve formě požadavku HTTPS GET s vlastní hlavičkou HTTP X-AdobeSign-ClientId. Hodnota v tomto záhlaví je nastavena na ID klienta aplikace, která požaduje vytvoření/registraci webhooku. K dosažení úspěšné registrace webhooku musí adresa URL webhooku odpovědět na požadavek o ověření kódem odpovědi 2XX A navíc musí odeslat zpět stejnou hodnotu ID klienta jedním z následujících dvou způsobů.

K dispozici jsou dvě možnosti, jak můžete pokračovat:


Možnost 1: Předání ID klienta v X-AdobeSign-ClientId jako hlavičce odpovědi

Předejte X-AdobeSign-ClientId v hlavičce odpovědi. Jedná se o stejnou hlavičku, která byla předána v požadavku, a musí být vrácena v odpovědi.

Nahraďte kód souboru Index.js následujícím kódem:

Nahrazení souboru index.js

module.exports = function (context, req) {

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

    // Validate that the incoming ClientID is genuine

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

        context.res = {

            // status: 200, /* Defaults to 200 */ // any 2XX response is acceptable

            body: "Notification Accepted",

            headers : {

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

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Opps!! Illegitimate Call identified"

        };

    }

    context.done();

};

 

Vyzkoušejte chování napodobením požadavku:

1. Klikněte na tlačítko Test v pravém rohu

2. Vytvořte fiktivní požadavek

Testování funkce

Hlavičky odpovědí se sice výše nezobrazují, ale můžete je sledovat prostřednictvím napodobování pomocí aplikace Postman, DHC nebo nebo jiné služby.


Možnost 2: Předání ID klienta v těle odpovědi pomocí klíče xAdobeSignClientId

Předejte ID klienta v těle odpovědi JSON pomocí klíče xAdobeSignClientId, jehož hodnota se shoduje s ID klienta, které bylo zasláno v hlavičce požadavku.

Nahraďte kód souboru Index.js následujícím kódem:

Aktualizace obsahu souboru index.js

module.exports = function (context, req) {

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

    // Validate that the incoming ClientID is genuine

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

        context.res = {

            // status: 200, /* Defaults to 200 */ // any 2XX response is acceptable

            body: {

                'xAdobeSignClientId' : clientId

            },

            headers : {

                'Content-Type' : 'application/json'

            }

        };

    }

    else {

        context.res = {

            status: 400,

            body: "Opps!! Illegitimate Call identified"

        };

    }

    context.done();

};

 

Vyzkoušejte chování napodobením požadavku

1. Klikněte na tlačítko Test v pravém rohu

2. Vytvořte fiktivní požadavek

Testování funkce

Všimněte si také, že stejné chování pro ID klienta je očekáváno, když adresa URL webhooku přijme oznámení POST. 


Připraveno k použití

Po ověření chování je adresa URL webhooku funkční podle standardů služby Acrobat Sign. Dále můžete aktualizovat vlastní logiku podle svých požadavků.

 

Získání adresy URL funkce

  • Klikněte na možnost Získat adresu URL funkce
Získání adresy URL funkce

 

Zkopírujte adresu URL a použijte ji k vytvoření webhooků ve službě Acrobat Sign.

Kopírování adresy URL funkce

Vytvoření funkce AWS Lambda

Chcete-li vytvořit funkci AWS Lambda, přihlaste se do konzoly pro správu AWS a v seznamu služeb vyberte službu AWS Lambda.

  • Klikněte na možnost Vytvořit funkci Lambda pomocí možnosti „Vytvořit zcela od začátku“
  • Na stránce Konfigurovat funkci zadejte název funkce „lambdaWebhooks“ a jako modul runtime vyberte možnost Node.js 4.3
  • Pro položku Role vyberte existující roli nebo vytvořte novou roli ze šablon(y)
    • Pokud jste vybrali možnost Vytvořit novou roli ze šablon(y), zadejte název role (např. role-lambda) a ze seznamu Šablony zásad vyberte možnost Oprávnění jednoduchých mikroslužeb
  • Klikněte na tlačítko Vytvořit funkci
Vytvoření funkce v AWS

  • Na nové stránce funkce AWS Lambda vyberte pro položku Typ zadání kódu možnost Upravit vložený kód a pro položku Obslužná rutina zachovejte nastavení index.handler.
  • Přidejte logiku pro registraci webhooku služby Acrobat Sign

    Před úspěšnou registrací webhooku služba Acrobat Sign ověří, zda adresa URL webhooku, která je uvedena v žádosti o registraci, skutečně zamýšlí přijímat oznámení, nebo nikoli. Za tímto účelem služba Acrobat Sign při obdržení nového požadavku na registraci webhooku nejprve požádá o ověření adresy URL webhooku. Tato žádost o ověření je odeslána na adresu URL webhooku ve formě požadavku HTTPS GET s vlastní hlavičkou HTTP X-AdobeSign-ClientId. Hodnota v tomto záhlaví je nastavena na ID klienta aplikace, která požaduje vytvoření/registraci webhooku. K dosažení úspěšné registrace webhooku musí adresa URL webhooku odpovědět na požadavek o ověření kódem odpovědi 2XX A navíc musí odeslat zpět stejnou hodnotu ID klienta jedním z následujících dvou způsobů. Všimněte si také, že stejné chování pro ID klienta je očekáváno, když adresa URL webhooku přijme oznámení POST.

    Postupujte podle jednoho z těchto dvou případů:

    Případ 1: Předání ID klienta v X-AdobeSign-ClientId jako hlavičce odpovědi

    •  Předejte X-AdobeSign-ClientId v hlavičce odpovědi. Jedná se o stejnou hlavičku, která byla předána v požadavku, a musí být vrácena v odpovědi.

      Fragment kódu
      V souboru index.js nahraďte automaticky generovaný fragment kódu následujícím kódem:

Ukázka kódu JS uzlu pro načtení ID klienta, jeho ověření a následné vrácení v hlavičce odpovědi

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

  // Fetch client id

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

 

  //Validate it

  if (clientid =="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

  {

    var response = {

        statusCode: 200,

        headers: {

            "X-AdobeSign-ClientId": clientid

        }

     };

   callback(null,response);

  }

  else {

   callback("Oops!! illegitimate call");

  }

}

 

Případ 2: Předání ID klienta v těle odpovědi pomocí klíče xAdobeSignClientId

Předejte ID klienta v těle odpovědi JSON pomocí klíče xAdobeSignClientId, jehož hodnota se shoduje s ID klienta, které bylo zasláno v hlavičce požadavku.

 

Fragment kódu

Nahraďte kód souboru Index.js následujícím kódem:

Ukázka kódu JS uzlu pro načtení ID klienta, jeho ověření a následné vrácení v hlavičce odpovědi

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

 // Fetch client id

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

  

 //Validate it

 if (clientid =="BGBQIIE7H253K6") //Replace 'BGBQIIE7H253K6' with the client id of the application using which the webhook is created

 {

   var responseBody = {

        xAdobeSignClientId : clientid

   };

     

    var response = {

        statusCode: 200,

        body: JSON.stringify(responseBody)

    };

 

   callback(null,response);

 }

 else {

   callback("Opps!! illegitimate call");

  }

}

Aktualizace obsahu souboru index.js

  • Uložte funkci. Funkce Lambda je vytvořena a je téměř připravena k použití ve webhooku v reálném čase.

 

Konfigurace brány AWS API

Pokud má být tato funkce Lambda veřejně přístupná prostřednictvím metody HTTP, je nutné nakonfigurovat bránu AWS API pomocí naší funkce (vytvořené výše) jako backend pro rozhraní API.

V konzole pro správu AWS vyberte ze seznamu služeb AWS možnost Brána API a poté klikněte na tlačítko Vytvořit rozhraní API

Konfigurace brány API

  • Na stránce Vytvořit nové rozhraní API vyberte možnost Nové rozhraní API a do pole Název rozhraní API zadejte text webhooky.
  • Klikněte na tlačítko Vytvořit rozhraní API
  • Vyberte rozevírací seznam Akce a zvolte možnost Vytvořit zdroj
  • Zaškrtněte políčko Konfigurovat jako zdroj proxy, do pole Název zdroje zadejte text ověřit a do pole Cesta ke zdroji zadejte text {proxy+}
  • Zrušte zaškrtnutí políčka Aktivovat CORS brány API a klikněte na tlačítko Vytvořit zdroj
  • V poli Typ integrace ponechte vybranou možnost Funkce Lambda Proxy a v rozevíracím seznamu Oblast Lambda vyberte oblast, ve které jste vytvořili funkci Lambda (pravděpodobně se jedná o stejnou oblast, ve které vytváříte bránu API).
  • Do pole Funkce Lambda zadejte text ověřit a klikněte na tlačítko Uložit
  • V automaticky otevřeném okně Přidat oprávnění k funkci Lambda vyberte tlačítko OK

Pokud všechny výše uvedené kroky proběhnou úspěšně, zobrazí se podobná obrazovka, jako je tato:

Nakonfigurovaná metoda

Nasazení rozhraní API

Dalším krokem je nasazení tohoto rozhraní API, aby bylo připraveno k použití.

  • V rozevírací nabídce Akce vyberte možnost Nasadit rozhraní API
  • V poli Fáze nasazení vyberte možnost [Nová fáze] a do pole Název fáze zadejte text prod (nebo jakýkoli jiný text, kterým chcete tuto fázi identifikovat)
  • Klikněte na tlačítko Nasadit

Rozhraní API je nyní připraveno k použití a adresu URL pro vyvolání najdete v modrém poli, jak je zobrazeno níže:

Nasazení rozhraní API

Poznamenejte si tuto adresu URL, protože ji budete muset zadat jako adresu URL webhooku v reálném čase.

Připraveno k použití

Je to hotovo. Použijte výše uvedenou adresu URL doplněnou o řetězec „/{nodeJSfunctionName}“ jako adresu URL webhooku v rozhraní API POST /webhooky.  Po ověření chování je adresa URL webhooku funkční podle
standardů služby Acrobat Sign. Dále můžete aktualizovat nebo přidat vlastní logiku podle svých požadavků.

Postup povolení nebo zakázání

Přístup k funkci Webhooky je ve výchozím nastavení povolen pro účty podnikové úrovně.

Správci na úrovni skupiny mohou vytvářet a ovládat webhooky, které fungují pouze v rámci jejich skupiny.

Přístup ke stránce Webhooky získáte na levé liště nabídky Správce.

Přechod na kartu Webhooky

Omezení rychlosti na základě souběžnosti

Události vytváření a oznámení webhooků (a zpětných volání) jsou omezeny počtem souběžných oznámení, která jsou aktivně doručována zákazníkovi ze systému Acrobat Sign. Tento limit se vztahuje na účet a zahrnuje všechny skupiny v rámci účtu.
Tento typ omezení rychlosti zabraňuje tomu, aby jeden špatně navržený účet spotřebovával neúměrné množství zdrojů serveru, což by mělo negativní dopad na všechny ostatní zákazníky v daném serverovém prostředí.

Počet souběžných událostí na účet byl vypočten tak, aby bylo zajištěno, že účty s dobře ošetřenými webhooky budou dostávat svá oznámení v co nejkratší době a jen zřídka by se měly setkat se situací, kdy se oznámení zpozdí kvůli příliš velkému počtu požadavků. Aktuální prahové hodnoty jsou:

Akce
(událost)

Maximální počet
souběžných
událostí

Popis

Vytvoření webhooku

10

Pro jeden účet je povoleno maximálně 10 souběžných požadavků na vytvoření webhooku.
Požadavky překračující tento limit budou mít za následek kód odpovědi 429 TOO_MANY_REQUESTS.

Oznámení webhooku / zpětného volání

30

Pro jeden účet je povoleno maximálně 30 souběžných oznámení webhooku a zpětného volání.
Oznámení, která tento limit překročí, se budou opakovat podle exponenciálního backoffu, dokud nebudou doručena.

Osvědčené postupy

  • Přihlaste se k odběru konkrétních potřebných událostí, abyste omezili počet požadavků protokolu HTTPS na server – Čím konkrétněji můžete webhooky nastavit, tím menší objem budete muset procházet.
  • Vyvarujte se duplicit – Pokud více aplikací sdílí stejnou adresu URL webhooku a stejný uživatel je namapován na každou z těchto aplikací, bude stejná událost odeslána do webhooku vícekrát (jednou pro každou aplikaci). V některých případech může webhook obdržet duplicitní události. Vaše aplikace webhooku by měla být na takovou situaci připravena a měla by duplicity odstraňovat podle ID události.
  • Na webhooky reagujte vždy rychle – Vaše aplikace má na odpověď na požadavky webhooku k dispozici pouze pět sekund. V případě požadavku na ověření se jedná jen zřídka o problém, protože aplikace nemusí při odpovědi vykonávat žádnou skutečnou práci. V případě požadavků na oznámení však aplikace obvykle provádí nějaké úkony, takže odpověď na požadavek vyžaduje určitý čas. Je doporučeno pracovat v samostatném vlákně nebo asynchronně pomocí fronty, abyste měli jistotu, že stihnete odpovědět do pěti sekund
  • Provádějte správu souběžnosti – Pokud uživatel provede několik změn v rychlém sledu za sebou, aplikace pravděpodobně obdrží zhruba ve stejnou dobu více oznámení pro stejného uživatele. Pokud si nedáte pozor na způsob správy souběžnosti, vaše aplikace může v konečném důsledku zpracovávat stejné změny pro stejného uživatele vícekrát. Chcete-li využívat výhody poskytované webhooky služby Acrobat Sign, je nezbytné porozumět tomu, jak používají informace. Nezapomeňte si položit otázky, jako například:
    • Jaká data chcete vracet v datové části?
    • Kdo bude přistupovat k těmto informacím?
    • Jaká rozhodnutí nebo hlášení budou generována?
  • Doporučení pro přijetí podepsaného dokumentu – Při určování způsobu přijetí podepsaného dokumentu PDF ze služby Acrobat Sign do systému správy dokumentů je nutné zvážit několik faktorů.

Přestože je zcela přijatelné při vytváření webhooku pouze vybrat možnost Podepsaný dokument dohody, můžete zvážit použití rozhraní API služby Acrobat Sign k načtení dokumentů při přijetí aktivační události (jako je stav dohody Dokončeno).

Na co pamatovat...

Omezení velikosti JSON

Velikost datové části JSON je omezena na 10 MB.

Pokud událost vygeneruje větší datovou část, webhook bude aktivován, ale atributy podmíněného parametru, pokud se v požadavku vyskytují, budou odebrány, aby se zmenšila velikost datové části. 

Pokud k tomu dojde, bude v odpovědi vrácen objekt „ConditionalParametersTrimmed“, který klienta upozorní na odebrání informací conditionalParameters.

conditionalParametersTrimmed“ je objekt typu pole obsahující informace o oříznutých klíčích.

Zkrácení bude provedeno v následujícím pořadí:

  • includeSignedDocuments
  • includeParticipantsInfo
  • includeDocumentsInfo
  • includeDetailedInfo

Zkráceny budou nejprve podepsané dokumenty, poté informace o účastníkovi, informace o dokumentu, a nakonec podrobné informace.

K tomu může dojít například při události dokončení dohody, pokud obsahuje také podepsaný dokument (v kódu base 64), nebo u dohody s více poli formuláře

Oznámení webhooku

Webhooky služby Acrobat Sign doručují oznámení odesílateli dohody a všem webhookům nakonfigurovaným ve skupině, ze které byla dohoda odeslána. Webhooky s rozsahem účtu přijímají všechny události.

Odesílatel: Uživatel A | Podepisující: Uživatel B | Příjemce sdílení: Uživatel C

Uživatel A a uživatel B patří k různým účtům

Uživatel A a uživatel C patří k různým účtům

Případ použití

Oznámení?

Komentáře/poznámky

Účet uživatele A má webhook na úrovni ÚČTU (vytvořený uživatelem A nebo správcem účtu).

Ano

Webhook na úrovni ÚČTU dostává oznámení o všech událostech spuštěných v tomto účtu.

Účet uživatele A má webhook na úrovni SKUPINY (vytvořený uživatelem A nebo správcem účtu/skupiny).

Předpoklad: Uživatel A a správce skupiny patří do stejné skupiny.

Ano

Webhook na úrovni SKUPINY dostává oznámení o všech událostech spuštěných v této skupině.

Uživatel A má webhook na úrovni UŽIVATELE.

Ano

Jako odesílateli se uživateli A spustí webhook na úrovni UŽIVATELE

Uživatel A má webhook na úrovni ZDROJE (pro výše odeslanou dohodu).

Ano

 X
     X

Účet uživatele B má webhook na úrovni ÚČTU (vytvořený uživatelem B nebo správcem účtu).

Ne

Webhook na úrovni ÚČTU uživatele B je považován za webhook podepisujícího.

Účet uživatele B má webhook na úrovni SKUPINY (vytvořený uživatelem B nebo správcem účtu/skupiny).

Předpoklad: Uživatel B a správce skupiny patří do stejné skupiny.

Ne

Webhook na úrovni SKUPINY uživatele B je považován za webhook podepisujícího.

Uživatel B má webhook na úrovni UŽIVATELE.

Ne

Webhook na úrovni UŽIVATELE uživatele B je považován za webhook podepisujícího.

 X    X

Účet uživatele C má webhook na úrovni ÚČTU (vytvořený uživatelem C nebo správcem účtu).

Ne

Webhook na úrovni ÚČTU uživatele C je považován za webhook nepatřící původci.

Účet uživatele C má webhook na úrovni SKUPINY (vytvořený uživatelem C nebo správcem účtu/skupiny).

Předpoklad: Uživatel C a správce skupiny patří do stejné skupiny.

Ne

Webhook na úrovni SKUPINY uživatele C je považován za webhook nepatřící původci.

Uživatel C má webhook na úrovni UŽIVATELE.

Ne

Webhook na úrovni UŽIVATELE uživatele C je považován za webhook nepatřící původci.

Odesílatel: Uživatel A | Podepisující: Uživatel B | Příjemce sdílení: Uživatel C

Uživatel A, uživatel B a uživatel C patří ke stejnému účtu

Případ použití

Oznámení?

Poznámky

Účet uživatele A má webhook na úrovni ÚČTU (vytvořený uživatelem A nebo správcem účtu).

Ano

Webhooky na úrovni ÚČTU oznamují události spuštěné účtem.

Účet uživatele A má webhook na úrovni SKUPINY (vytvořený uživatelem A nebo správcem účtu/skupiny).

Předpoklad: Uživatel A a správce skupiny patří do stejné skupiny.

Ano

Webhooky na úrovni SKUPINY oznamují události spuštěné uživateli v jejich skupině.

Uživatel A má webhook na úrovni UŽIVATELE.

Ano

Jako odesílateli se uživateli A spustí webhook na úrovni UŽIVATELE

Uživatel A má webhook na úrovni ZDROJE (pro výše odeslanou dohodu).

Ano

 X
     X

Účet uživatele B má webhook na úrovni ÚČTU (vytvořený uživatelem B nebo správcem účtu).

Ano

Protože uživatel A a uživatel B patří ke stejnému účtu, webhook na úrovni ÚČTU obdrží oznámení o všech událostech spuštěných v tomto účtu.

Účet uživatele B má webhook na úrovni SKUPINY (vytvořený uživatelem B nebo správcem účtu/skupiny).

Předpoklad: Uživatel A, uživatel B a správce skupiny patří do stejné skupiny.

Ano

Protože uživatel A a uživatel B patří do stejné skupiny, webhook na úrovni SKUPINY obdrží oznámení o všech událostech spuštěných v této skupině.

Účet uživatele B má webhook na úrovni SKUPINY (vytvořený uživatelem B nebo správcem účtu/skupiny).

Předpoklad: Uživatel A a uživatel B patří do různých skupin.

Ne

Webhook na úrovni SKUPINY uživatele B je považován za webhook podepisujícího.

Bude spuštěn webhook uživatele A (na úrovni ZDROJE/UŽIVATELE/SKUPINY/ÚČTU).

Uživatel B má webhook na úrovni UŽIVATELE.

Ne

Jako příjemci se uživateli B nespustí webhook na úrovni UŽIVATELE.

 X    X

Účet uživatele C má webhook na úrovni ÚČTU (vytvořený uživatelem C nebo správcem účtu).

Ano

Protože uživatel A a uživatel C patří ke stejnému účtu, webhook na úrovni ÚČTU obdrží oznámení o všech událostech spuštěných v tomto účtu.

Účet uživatele C má webhook na úrovni SKUPINY (vytvořený uživatelem C nebo správcem účtu/skupiny).

Předpoklad: Uživatel A, uživatel C a správce skupiny patří do stejné skupiny.

Ano

Protože uživatel A a uživatel C patří do stejné skupiny, webhook na úrovni SKUPINY obdrží oznámení o všech událostech spuštěných v této skupině.

Účet uživatele C má webhook na úrovni SKUPINY (vytvořený uživatelem C nebo správcem účtu/skupiny).

Předpoklad: Uživatel A a uživatel C patří do různých skupin.

Ne

Webhook na úrovni SKUPINY uživatele C je považován za webhook nepatřící původci.

Bude spuštěn webhook uživatele A (na úrovni ZDROJE/UŽIVATELE/SKUPINY/ÚČTU).

Uživatel C má webhook na úrovni UŽIVATELE.

Ne

Webhook na úrovni UŽIVATELE uživatele C je považován za webhook nepatřící původci.

Opakování, když je naslouchající služba nefunkční

Pokud je cílová adresa URL webhooku z jakéhokoli důvodu nefunkční, služba Acrobat Sign zařadí objekt JSON do fronty a opakuje pokus o odeslání v postupném cyklu po dobu 72 hodin.

Nedoručené události zůstanou ve frontě opětovných pokusů a v následujících 72 hodinách bude vynaloženo maximální úsilí na doručení oznámení v pořadí, v jakém k nim došlo.

Strategie opakování doručení upozornění spočívá ve zdvojnásobování prodlevy mezi jednotlivými pokusy. Začíná se minutovým intervalem, který se postupně zvyšuje na 12 hodin, ve výsledku tedy 15 opakování za 72 hodin.

Pokud přijímač webhooku neodpoví do 72 hodin a v posledních sedmi dnech nedošlo k žádnému úspěšnému doručení oznámení, bude webhook deaktivován. Na tuto adresu URL nebudou zasílána žádná oznámení, dokud nebude webhook znovu aktivován.

Všechna oznámení v době mezi deaktivací webhooku a jeho následnou opětovnou aktivací budou ztracena.