사용 안내서 취소

webhook 구성

개요

Webhook은 소스 사이트(이 경우 Adobe Acrobat Sign)에서 구독 이벤트가 발생할 때 트리거되는 사용자 지정된 HTTPS 요청입니다.

사실상 Webhook은 데이터 또는 데이터 스트림을 수락하는 REST 서비스에 불과합니다.

Webhook은 푸시 모델에서 서비스 간 통신을 위한 것입니다.

구독 이벤트가 트리거되면 Acrobat Sign은 JSON 본문을 사용하여 HTTPS POST를 구성하고 지정된 URL로 전달합니다.

 

Webhook은 이전 콜백 방법에 비해 여러 가지 이점을 제공하며, 그중 일부는 다음과 같습니다.

  • 관리자는 콜백 URL을 나열하기 위해 Acrobat Sign 지원을 사용할 필요 없이 Webhook을 활성화할 수 있습니다.
  • Webhook은 데이터 “참신성”, 통신의 효율성, 보안 측면에서 더 유용합니다. 폴링은 필요하지 않습니다.
  • Webhook을 사용하면 다양한 수준의 범위(계정/그룹/사용자/리소스)를 쉽게 지원할 수 있습니다, 
  • Webhook은 최신 API 솔루션으로, 최신 애플리케이션을 더 간단하게 구성할 수 있습니다.
  • 각 범위(계정/그룹/사용자/리소스)에 대해 여러 Webhook을 구성할 수 있습니다. 여기서 콜백은 고유해야 합니다.
  • Webhook을 사용하면 반환할 데이터를 선택할 수 있습니다. 여기서 콜백은 "전부 아니면 전무" 솔루션입니다.
  • Webhook과 함께 제공되는 메타데이터를 구성할 수 있습니다(기본 또는 상세).
  • UI가 전적으로 관리자의 제어 범위 내에 있으므로 Webhook을 필요에 따라 훨씬 쉽게 생성, 편집 또는 비활성화할 수 있습니다.
참고:

이 문서에서는 주로 Acrobat Sign 웹 애플리케이션(이전 Adobe Sign)의 Webhook UI를 중점적으로 다룹니다.

API 세부 정보를 찾는 개발자는 여기에서 추가 정보를 찾을 수 있습니다.

사용되는 방식

관리자는 먼저 Acrobat Sign의 인바운드 푸시를 수락할 준비가 된 Webhook 서비스를 보유해야 합니다. 관련된 많은 옵션이 있으며, 서비스가 POST 및 GET 요청을 수락할 수 있는 한 Webhook은 성공적으로 실행됩니다.

서비스가 준비되면 Acrobat Sign 관리자는 Acrobat Sign 사이트의 계정 메뉴에 있는 Webhook 인터페이스에서 새 Webhook을 생성할 수 있습니다.

관리자는 계약, 웹 양식(위젯) 또는 대량 전송(MegaSign) 이벤트를 트리거하도록 Webhook을 구성할 수 있습니다. 라이브러리 템플릿(라이브러리 문서) 리소스는 API를 통해 구성할 수도 있습니다.

Webhook의 범위는 관리자 인터페이스를 통해 전체 계정 또는 개별 그룹을 포함할 수 있습니다. API를 사용하면 사용자 또는 리소스 범위를 선택하여 더 세분화할 수 있습니다.

URL로 푸시되는 데이터 유형은 구성 가능하며 계약 정보, 참가자 정보, 문서 정보 등과 같은 항목을 포함할 수 있습니다.

Webhook이 구성되고 저장되면 Acrobat Sign은 구독 이벤트가 트리거될 때마다 새로운 JSON 개체를 정의된 URL로 푸시합니다. 이벤트 트리거 조건이나 JSON 페이로드를 변경하려는 경우가 아니라면 Webhook을 계속 조작할 필요가 없습니다.

Webhook URL의 의도 확인

Webhook을 성공적으로 등록하기 전에 Acrobat Sign은 등록 요청에서 제공된 Webhook URL이 알림을 수신할 것인지 여부를 확인합니다. 이를 위해 Acrobat Sign은 새 Webhook 등록 요청을 받으면 먼저 Webhook URL에 대한 확인 요청을 합니다. 이 확인 요청은 Webhook URL로 전송된 HTTPS GET 요청입니다. 이 요청에는 사용자 지정 HTTP 헤더 X-AdobeSign-ClientId가 있습니다. 이 헤더의 값은 Webhook 생성/등록을 요청하는 API 애플리케이션의 클라이언트 ID(애플리케이션 ID)로 설정됩니다. Webhook을 성공적으로 등록하려면 Webhook URL은 이 확인 요청에 2XX 응답 코드로 응답해야 하며 다음 두 가지 방법 중 하나로 동일한 클라이언트 ID 값을 다시 전송해야 합니다.

  • 응답 헤더 X-AdobeSign-ClientId에서 이는 요청에서 전달되는 동일한 헤더로 응답에서 다시 반복됩니다.
  • 또는 xAdobeSignClientId 키가 포함된 JSON 응답 본문에서 해당 값은 요청에서 전송된 것과 동일한 클라이언트 ID입니다.

Webhook은 성공 응답(2XX 응답 코드) 및 헤더 또는 응답 본문의 클라이언트 ID 유효성 검사에만 성공적으로 등록됩니다. 이 확인 요청의 목적은 Webhook URL이 해당 URL에서 알림을 수신하기를 원한다는 것을 보여주기 위한 것입니다. 실수로 잘못된 URL을 입력한 경우 URL이 의도 요청 확인에 올바르게 응답하지 않으며 Acrobat Sign이 해당 URL에 알림을 전송하지 않습니다. 또한 Webhook URL은 특정 애플리케이션에서 등록한 Webhook을 통해서만 알림을 수신하는지 확인할 수도 있습니다. 이 작업은 X-AdobeSign-ClientId 헤더에 전달된 애플리케이션의 클라이언트 ID를 유효성 검사하여 수행할 수 있습니다. Webhook URL이 해당 클라이언트 ID를 인식하지 못하면 성공 응답 코드로 응답하지 않아야 하며, Acrobat Sign은 URL이 Webhook으로 등록되지 않도록 처리합니다.

Webhook URL 호출의 확인은 다음 시나리오에서 수행됩니다.

  • Webhook 등록: 이 Webhook URL 호출 확인에 실패하면 Webhook이 생성되지 않습니다.
  • Webhook 업데이트: INACTIVE - ACTIVE: 이 Webhook URL 호출 확인에 실패하면 Webhook 상태가 ACTIVE로 변경되지 않습니다.

Webhook 알림에 응답하는 방법

Acrobat Sign은 Webhook URL로 전송되는 각 Webhook 알림 요청에서 의도를 암시적으로 확인합니다. 따라서 모든 Webhook 알림 HTTPS 요청에는 X-AdobeSign-ClientId라는 사용자 지정 HTTP 헤더도 포함됩니다. 이 헤더의 값은 Webhook을 생성한 애플리케이션의 클라이언트 ID(애플리케이션 ID)입니다. 성공 응답(2XX 응답 코드)이 반환되고 클라이언트 ID가 HTTP 헤더(X-AdobeSign-ClientId)로 전송되거나 키가 xAdobeSignClientId이고 값이 동일한 클라이언트 ID인 JSON 응답 본문을 통해 전송되는 경우에만 Webhook 알림이 성공적으로 전달된 것으로 간주합니다. 그렇지 않으면 재시도 횟수가 모두 소진될 때까지 Webhook URL로 알림 전달을 다시 시도합니다.

구성 옵션

Webhook을 구성하려면 5개 요소를 정의해야 합니다.

  • 이름 - 관리자가 쉽게 이해할 수 있는 직관적인 이름이 권장됩니다.
  • 범위 - Webhook의 도달 범위입니다. 인터페이스에서 계정 및 그룹을 사용할 수 있습니다.
    • API에서는 계정, 그룹, 사용자 및 리소스 범위를 지원합니다.
    • Webhook당 하나의 범위만 정의할 수 있습니다.
  • URL - Adobe Sign이 JSON 페이로드를 푸시한 대상 URL입니다.
  • 이벤트 - Adobe Sign이 JSON을 빌드하고 URL로 푸시하도록 하는 트리거입니다.
    • 각 이벤트는 트리거 이벤트와 관련된 다른 페이로드를 빌드합니다.
    • 하나의 Webhook에 여러 이벤트가 포함될 수 있습니다.
  • 알림 매개변수 - 알림 매개변수이벤트 JSON 페이로드의 섹션을 식별하므로 이 Webhook에 중요한 이벤트 섹션만 선택할 수 있으며, 따라서 URL로 전송하는 불필요한 데이터가 감소됩니다.

Webhook이 완벽히 정의된 후 저장을 클릭하면 새 Webhook이 반응하여 즉시 이벤트를 트리거합니다.

참고:

위에 설명된 확인 프로토콜에 따라 Webhook 확인 및 Webhook 알림 요청에 응답하도록 Webhook URL을 구성하세요. Acrobat Sign 웹 애플리케이션에서 생성된 Webhook으로 전송되는 클라이언트 ID(애플리케이션 ID)는 UB7E5BXCXY입니다.

Webhook 구성



범위

  • 계정: 계정에서 발생하는 모든 구독 이벤트는 푸시를 트리거합니다.
    • 계정 관리자는 계정 및 해당 계정 내의 모든 그룹에 대해 정의된 모든 Webhook을 볼 권한이 있습니다.
  • 그룹: 그룹에서 발생하는 모든 구독 이벤트는 푸시를 트리거합니다. 참고: 그룹 범위 Webhook은 하나의 해당 그룹에 대해서만 존재합니다.
    • 그룹 관리자는 해당 그룹 전용 Webhook만 볼 수 있습니다. 계정 수준 Webhook 또는 다른 그룹에 바인딩된 Webhook은 볼 수 없습니다.
    • 다중 그룹의 사용자가 활성화된 계정에는 범위를 적용해야 하는 그룹을 설정하는 옵션이 표시됩니다.
  • 사용자 계정: 사용자 계정에 대한 모든 구독 이벤트는 푸시를 트리거합니다. 사용자 수준 Webhook은 API를 통해서만 만들 수 있습니다.
  • 리소스 수준 Webhook: 특정 리소스에 대해 생성됩니다. 이 리소스와 관련된 이벤트는 Webhook URL로 푸시됩니다. 리소스 수준 Webhook은 API를 통해서만 만들 수 있습니다.

URL

Webhook URL은 이벤트가 발생할 때 트리거되는 수신 HTTPS POST 알림 메시지를 수신 대기하는 서버입니다.

Webhook에서 이벤트를 구독하려면 이 URL이 필요합니다.

  • 클라이언트에는 Acrobat Sign이 POST할 수 있는 HTTPS URL이 포함되어야 합니다. 이 URL은 공용 인터넷에서 사용할 수 있어야 합니다.  
    • 예를 들어 127.0.0.1 및 localhost URI는 작동하지 않습니다.
    • URL 엔드포인트는 포트 443 또는 8443에서 수신 대기해야 합니다(콜백 URL을 정의할 때 고객이 결정).
  • Webhook에서 수신 이벤트 알림에 대한 POST 요청과 확인 요청에 대한 GET 요청을 지원하는지 확인합니다.
  • URL은 방화벽으로 차단해서는 안 됩니다.


이벤트

다음은 Webhook URL로 푸시를 트리거할 수 있는 이벤트로서, 개체별로 그룹화되고 UI에 있는 순서대로 나열됩니다.

왼쪽 값은 Acrobat Sign UI에 표시되는 값입니다. 오른쪽 값은 API에서 Webhook 이름입니다.

Webhook 및 해당 페이로드에 대한 자세한 내용은 Acrobat Sign 개발자 안내서를 참조하세요.

계약:

UI 요소 Webhook 이름
계약 모든 이벤트 AGREEMENT_ALL
계약이 생성됨 AGREEMENT_CREATED
계약서 전송됨 AGREEMENT_ACTION_REQUESTED
계약 참가자가 완료함 AGREEMENT_ACTION_COMPLETED
계약 워크플로우가 완료됨 AGREEMENT_WORKFLOW_COMPLETED
계약이 만료됨 AGREEMENT_EXPIRED
계약이 삭제됨 AGREEMENT_DOCUMENTS_DELETED
계약이 취소됨 AGREEMENT_RECALLED
계약이 거부됨 AGREEMENT_REJECTED
계약이 공유됨 AGREEMENT_SHARED
계약이 위임됨 AGREEMENT_ACTION_DELEGATED
계약 참가자가 교체됨 AGREEMENT_ACTION_REPLACED_SIGNER
계약이 수정됨 AGREEMENT_MODIFIED
계약 수정이 승인됨 AGREEMENT_USER_ACK_AGREEMENT_MODIFIED
계약 이메일을 봄 AGREEMENT_EMAIL_VIEWED
계약 이메일이 반송됨 AGREEMENT_EMAIL_BOUNCED
계약 작성 실패 AGREEMENT_AUTO_CANCELLED_CONVERSION_PROBLEM
계약이 동기화된 사후 오프라인 이벤트 AGREEMENT_OFFLINE_SYNC
발신자가 계약을 업로드함 AGREEMENT_UPLOADED_BY_SENDER
계약이 보관됨 AGREEMENT_VAULTED
계약 참가자 소셜 신원이 인증됨 AGREEMENT_WEB_IDENTITY_AUTHENTICATED
계약 참가자 KBA가 인증됨 AGREEMENT_KBA_AUTHENTICATED
계약 알림 전송됨 AGREEMENT_REMINDER_SENT
서명자가 계약 서명자 이름을 변경함 AGREEMENT_SIGNER_NAME_CHANGED_BY_SIGNER
   
계약 Webhook는 API를 통해서만 사용 가능
NA AGREEMENT_EXPIRATION_UPDATED
NA
AGREEMENT_READY_TO_NOTARIZE
NA
AGREEMENT_READY_TO_VAULT

 

대량 전송:

UI 요소 Webhook 이름
모든 이벤트 대량 전송 MEGASIGN_ALL
대량 전송 생성됨
MEGASIGN_CREATED
대량 전송 공유됨
MEGASIGN_SHARED
대량 전송 회수됨
MEGASIGN_RECALLED

 

웹 양식:

UI 요소 Webhook 이름
웹 양식 모든 이벤트 WIDGET_ALL
웹 양식이 생성됨
WIDGET_CREATED
웹 양식이 활성화됨
WIDGET_ENABLED
웹 양식이 비활성화됨
WIDGET_DISABLED
웹 양식이 수정됨
WIDGET_MODIFIED
웹 양식이 공유됨
WIDGET_SHARED
웹 양식 생성 실패
WIDGET_AUTO_CANCELLED_CONVERSION_PROBLEM

 

라이브러리 템플릿(API만 해당):

UI 요소 Webhook 이름
NA LIBRARY_DOCUMENT_ALL
NA LIBRARY_DOCUMENT_CREATED
NA LIBRARY_DOCUMENT_AUTO_CANCELLED_CONVERSION_PROBLEM
NA LIBRARY_DOCUMENT_MODIFIED

 

알림 매개변수

알림 매개변수를 사용하면 JSON 페이로드를 이벤트의 특정 요소에만 맞게 사용자 지정할 수 있습니다.

예를 들어, 계약 참가자 교체 이벤트에서 문서 정보는 생략하고 Webhook URL로 전송되는 JSON의 전체 크기를 줄이고 계약 정보참가자 정보만 원할 수 있습니다.

 

  • 계약
    • 계약 정보 - 트리거 이벤트 발생 시의 계약 상태를 기반으로 하는 자세한 계약 정보입니다.
    • 계약 문서 정보 - 이벤트의 결과로 생성된 모든 문서 정보를 포함합니다.
    • 계약 참가자 정보 - 이벤트의 결과로 모든 참가자 정보를 포함합니다.
    • 서명된 계약 문서 - 서명된 PDF를 제공합니다. 
      • 계약 워크플로우 완료모두 계약 이벤트에 적용됩니다.
  • 대량 전송
    • 대량 전송 정보 - 이벤트를 트리거한 대량 전송 개체에 대한 자세한 정보입니다.
  • 웹 양식
    • 위젯 정보 - 이벤트를 트리거한 웹 양식에 대한 자세한 정보입니다.
    • 위젯 문서 정보 - 웹 양식과 연결된 문서 정보입니다.
    • 위젯 참가자 정보 - 웹 양식에 정의된 참가자에 대한 정보입니다.

양방향 SSL 인증

클라이언트측 SSL 또는 상호 TLS라고도 하는 양방향 SSL은 서버 및 클라이언트(웹 브라우저)가 모두 자신을 식별하기 위한 인증서를 제공하는 SSL 모드입니다.

계정 관리자는 보안 설정 페이지에서 클라이언트측 인증서를 구성할 수 있습니다.

Acrobat Sign은 페이로드를 Webhook URL로 전달할 때 SSL 인증서를 확인합니다. SSL 인증서 확인에 실패한 Webhook은 JSON 페이로드를 성공적으로 전달하지 않습니다. 

양방향 SSL을 사용하여 클라이언트(Acrobat Sign) 및 수신 대기 서비스를 인증하면 Acrobat Sign만 Webhook URL에 연결할 수 있습니다. 

파트너 애플리케이션에 의해 생성된 Webhook은 Webhook 알림을 전송할 때 파트너 애플리케이션 계정의 클라이언트 인증서(사용 가능한 경우)를 사용하여 자체 식별합니다.

다음은 웹 서버 확인 프로세스와 클라이언트 인증 확인에 대한 가장 일반적인 질문입니다.

웹 서버 확인

Webhook을 등록하는 동안 Acrobat Sign은 Webhook 서버 URL을 확인합니다.

Acrobat Sign에서 Webhook 콜백 URL에 대한 연결을 완료할 수 없는 경우 고객은 Webhook를 등록할 수 없습니다.

클라이언트 인증서 확인

활성화하거나 비활성화하는 방법

Webhooks 기능에 대한 액세스는 엔터프라이즈 플랜 계정에서 기본적으로 활성화되어 있습니다.

그룹 수준 관리자는 해당 그룹 내에서만 작동하는 Webhook을 만들거나 제어할 수 있습니다.

Webhooks 페이지에 대한 액세스는 관리 메뉴의 왼쪽 레일인 계정 > Webhooks에서 찾을 수 있습니다.

Webhook 활성화

Webhook을 처음 만들면 Active 상태로 생성됩니다.

Acrobat Sign의 Webhooks 페이지에는 기본적으로 Active Webhook이 표시됩니다.

Inactive Webhook을 활성화하는 방법은 다음과 같습니다.

  • Webhook 헤더 행의 오른쪽에서 옵션 아이콘(세 개의 가로 줄)을 클릭하고 모든 Webhook 표시를 선택합니다.

 

  • Inactive Webhook을 한 번 클릭하여 선택합니다.
    • 그러면 헤더 행 바로 아래에 Webhook에 대한 옵션이 표시됩니다.
  • 활성화를 클릭합니다.

Active Webhook은 다음 이벤트가 트리거되는 즉시 대상 URL로 데이터 전송을 시작합니다.

Webhook 비활성화

Webhook을 비활성화하는 방법은 다음과 같습니다.

  • Webhooks 페이지로 이동합니다.
  • 비활성화할 Webhook을 한 번 클릭합니다.
  • 헤더 행 아래의 메뉴 항목에서 비활성화를 선택합니다.
    • 비활성화하면 Webhook에 Inactive 상태가 표시됩니다.

Webhook 보기 또는 편집

Webhook은 언제든지 편집 및 저장할 수 있으며 새 구성을 저장하면 변경 사항이 즉시 적용됩니다.

이벤트알림 매개변수만 편집할 수 있습니다.

이름, 범위 또는 URL을 변경해야 하는 경우 새 Webhook을 만들어야 합니다.

Webhook 매개변수를 편집하는 방법은 다음과 같습니다.

  • Webhooks 페이지로 이동합니다.
  • 편집할 Webhook을 한 번 클릭합니다.
  • 헤더 행 아래의 보기/편집 옵션을 선택합니다.

 

  • 필요한 변경 사항을 적용하고 저장을 클릭합니다.

Webhook 삭제

Webhook은 언제든지 삭제할 수 있습니다.

Webhook을 삭제하면 시스템에서 삭제되므로 삭제된 Webhook을 복구할 수 없습니다.

Webhook을 먼저 비활성화하지 않아도 됩니다.

Webhook을 삭제하는 방법은 다음과 같습니다.

  • Webhooks로 이동합니다.
  • 삭제할 Webhook을 한 번 클릭하여 선택합니다.
  • 헤더 행 아래의 삭제 옵션을 선택합니다.
  • Webhook을 삭제할 것인지 확인하는 질문이 표시됩니다. 확인을 클릭합니다.

우수 사례

  • 필요한 특정 이벤트를 구독하여 서버에 대한 HTTPS 요청 수 제한 - Webhook을 구체화할수록 살펴볼 볼륨은 줄어듭니다.
  • 중복 방지 - 동일한 Webhook URL을 공유하는 여러 앱이 있고 동일한 사용자가 각 앱에 매핑된 경우 동일한 이벤트가 여러 번 Webhook로 전송됩니다(앱당 한 번). 경우에 따라 Webhook에서 중복 이벤트를 받을 수 있습니다. Webhook 애플리케이션은 이를 허용해야 하며 이벤트 ID에 의해 중복 제거되어야 합니다.
  • 항상 신속하게 Webhook에 응답 - 앱이 Webhook 요청에 응답할 수 있는 시간은 단 5초입니다. 확인 요청의 경우, 앱에서 응답하기 위해 실제 작업을 수행할 필요가 없으므로 거의 문제가 되지 않습니다. 그러나 알림 요청의 경우, 일반적으로 앱에서 요청에 응답하는 데 시간이 걸리는 작업을 수행합니다. 5초 이내에 응답할 수 있도록 별도의 스레드에서 작업하거나 대기열을 비동기적으로 사용하는 것이 좋습니다.
  • 동시성 관리 - 사용자가 여러 사항을 연속적으로 빠르게 변경하면 앱에서 거의 동시에 동일한 사용자에 대한 여러 알림을 수신할 가능성이 높습니다. 동시성을 관리하는 방법에 대해 주의하지 않으면 앱에서 동일한 사용자에 대한 동일한 변경 내용을 두 번 이상 처리할 수 있습니다. Acrobat Sign Webhook을 활용하려면 정보 사용에 대한 명확한 이해가 필요합니다. 다음과 같이 질문하세요. 
    • 페이로드에서 어떤 데이터를 반환하시겠습니까? 
    • 누가 이 정보에 액세스하게 되나요? 
    • 어떤 결정 또는 보고가 생성되나요?
  • 서명된 문서 수신을 위한 권장 사항 - 문서 관리 시스템에서 Acrobat Sign의 서명된 PDF를 수신하는 방법을 결정할 때 고려할 몇 가지 요소가 있습니다.

Webhook을 만드는 동안 서명된 계약 문서 옵션을 선택하는 것이 완벽하게 허용되지만, 트리거 이벤트(예: 계약 상태 완료)가 수신되면 Acrobat Sign API를 사용하여 문서를 검색하는 것을 고려할 수 있습니다.

주의 사항...

JSON 크기 제한

JSON 페이로드 크기는 10MB로 제한됩니다.

이벤트에서 더 큰 페이로드를 생성하는 경우 Webhook이 트리거되지만 요청에 조건부 매개 변수 속성이 있는 경우 이를 제거하여 페이로드의 크기를 줄입니다. 

이런 일이 발생하면 응답에 "ConditionalParametersTrimmed"가 반환되어, 클라이언트에게 conditionalParameters 정보가 제거되었음을 알립니다.

conditionalParametersTrimmed”는 트리밍된 키에 대한 정보가 포함된 배열 개체입니다.

잘라내기는 다음 순서로 수행됩니다.

  • includeSignedDocuments
  • includeParticipantsInfo
  • includeDocumentsInfo
  • includeDetailedInfo

서명된 문서가 먼저 잘린 다음 참가자 정보, 문서 정보, 마지막으로 세부 정보가 잘립니다.

예를 들어 서명된 문서(base 64 인코딩)가 포함되어 있는 계약 완료 이벤트에서 또는 여러 양식 필드가 있는 계약에 대해 이러한 문제가 발생할 수 있습니다.

Webhook 알림

Acrobat Sign Webhook은 해당 사용자, 그룹 또는 계정에 대해 구성된 Webhook이 있는 경우, 계약의 모든 참가자에게 적용할 수 있는 알림을 제공합니다.

계약 이벤트는 해당 이벤트의 해당 참가자에 대해 구성된 Webhook이 있는 경우 알림이 해당 Webhook URL로 전송되는 방식으로 처리됩니다. 즉, Webhook이 구성된 그룹 또는 계정 외부의 계약을 포함하여 모든 적용 가능한 계약의 이벤트에 대해 Webhook이 트리거됩니다.

알림은 참가자가 관련된 이벤트에 대해서만 전달됩니다. 예를 들어 계약의 발신자는 거의 모든 알림을 받는 반면, 수신자는 계약에 관여하기 시작할 때부터 직접 관여한 이벤트에 대해서만 알림을 받습니다.

Webhook 알림은 Acrobat Sign 자체의 현재 인증 및 가시성 모델을 따릅니다. 즉, 사용자의 계약 참여가 시작된 경우에만 사용자가 계약에 대한 액세스 권한을 갖게 됩니다.

수신 대기 서비스가 다운되었을 때 다시 시도

Webhook 대상 URL이 다운된 경우 Acrobat Sign은 JSON을 대기열에 추가하고 72시간 동안 점진적 주기로 푸시를 다시 시도합니다.

전달되지 않은 이벤트는 다시 시도 대기열에 유지되며 다음 72시간 동안 발생한 순서대로 알림을 전달하기 위해 계속 시도합니다.

알림 전달을 다시 시도하는 전략은 시도 간 시간을 두 배로 늘리는 것입니다. 1분 간격에서 시작하여 매 12시간 동안 증가하여 72시간 동안 총 15번을 다시 시도합니다.

Webhook 수신자가 72시간 이내에 응답하지 못하고 지난 7일 동안 성공적인 알림 배달이 없는 경우 Webhook은 비활성화됩니다. Webhook이 다시 활성화될 때까지 이 URL에 알림이 전송되지 않습니다.

Webhook이 비활성화되는 시점과 나중에 다시 활성화되는 시점 사이의 모든 알림은 손실됩니다.

쉽고 빠르게 지원 받기

신규 사용자이신가요?