Un webhook es una solicitud HTTPS definida por el usuario que se activa cuando se produce un evento determinado en el sitio de origen (Adobe Acrobat Sign, en este caso).

Por lo tanto, un webhook es simplemente un servicio REST que acepta datos o un flujo de datos.

Los webhooks están pensados para la comunicación de servicio a servicio en un modelo PUSH.

Cuando se activa un evento suscrito, Acrobat Sign crea un POST HTTPS con un cuerpo JSON y lo envía a la dirección URL especificada.

Antes de configurar los webhooks, asegúrese de que la red acepta los intervalos de IP necesarios para la funcionalidad.

Los webhooks ofrecen varias ventajas sobre el método de devolución de llamada anterior, algunas de las cuales son las siguientes:

Los administradores pueden habilitar sus propios webhooks sin tener que involucrar al soporte técnico de Acrobat Sign para que muestre la URL de devolución de llamada
Los webhooks son mejores en términos del estado de actualización de los datos, de la eficiencia de la comunicación y de la seguridad. No se requiere votación
Los webhooks permiten diferentes niveles de ámbito (cuenta/grupo/usuario/recurso) fácilmente.
Los webhooks son una solución de API más moderna que permite una configuración más sencilla para las aplicaciones modernas
Se pueden configurar varios webhooks por ámbito (cuenta/grupo/usuario/recurso), donde las devoluciones de llamada debían ser únicas.
Los webhooks permiten la selección de los datos que se van a devolver, donde las devoluciones de llamada son una solución de “todo o nada”
Los metadatos transportados con un webhook se pueden configurar (Básico o Detallado)
Los webhooks son mucho más fáciles de crear, editar o deshabilitar según sea necesario, ya que la interfaz de usuario está totalmente bajo el control del administrador.

Nota:

Este documento se centra principalmente en la interfaz de usuario de webhooks en la aplicación web de Acrobat Sign (anteriormente Adobe Sign).

Los desarrolladores que buscan detalles de la API pueden encontrar más información aquí:

Detalles de REST v6

Requisitos previos

Usted debe permitir los intervalos de IP para los webhooks a través de la seguridad de la red para que el servicio funcione.

El servicio URL de devolución de llamada heredado de REST versión 5 utiliza los mismos intervalos de IP que el servicio webhook.

Los administradores pueden iniciar sesión en Adobe Admin Console para añadir usuarios. Una vez que haya iniciado sesión, vaya al menú del administrador y desplácese hacia abajo hasta los webhooks.

Inicia sesión en Admin Console

Cómo se usa

Los administradores primero tendrán que tener un servicio webhook, listo para aceptar la inserción entrante desde Acrobat Sign. Hay muchas opciones en este sentido, y mientras el servicio pueda aceptar solicitudes de POST y GET, el webhook tendrá éxito.

Una vez implementado el servicio, un administrador de Acrobat Sign puede crear un nuevo webhook a partir de la interfaz de Webhook en el menú Cuenta del sitio de Acrobat Sign.

Los administradores pueden configurar el webhook para que se active para los eventos del acuerdo, formulario web (Widget) o envío en bloque (MegaSign). El recurso Plantilla de biblioteca (Documento de biblioteca) también se puede configurar mediante la API.

El ámbito del webhook puede incluir toda la cuenta o grupos individuales a través de la interfaz de administración. La API permite una mayor granularidad a través de la selección de los ámbitos USUARIO o RECURSO.

El tipo de datos que se insertan en la URL es configurable y puede incluir elementos como la información del acuerdo, del participante, del documento, etc.

Una vez configurado y guardado el webhook, Acrobat Sign insertará un nuevo objeto JSON en la dirección URL definida cada vez que se active el evento de suscripción. No se requiere ninguna manipulación continua del webhook a menos que desee cambiar los criterios del activador de eventos o la carga de JSON.

Verificación de la intención de la URL del webhook

Antes de registrar un webhook correctamente, Acrobat Sign verifica que la URL del webhook proporcionada en la solicitud de registro tenga realmente la intención de recibir notificaciones o no. Para ello, cuando Acrobat Sign recibe una nueva solicitud de registro de webhook, primero realiza una solicitud de verificación a la URL del webhook. Esta solicitud de verificación es una petición GET HTTPS enviada a la URL de webhook. Esta solicitud tiene un encabezado HTTP personalizado X-AdobeSign-ClientId. El valor de este encabezado se establece en el ID de cliente (ID de aplicación) de la aplicación de API que solicita crear o registrar el webhook. Para registrar correctamente un webhook, la URL del webhook responde a esta solicitud de verificación con un código de respuesta 2XX Y, además, PUEDE devolver el mismo valor de ID de cliente de una de las dos maneras siguientes:

Ya sea en un encabezado de respuesta X-AdobeSign-ClientId. En el mismo encabezado que se transfiere en la solicitud y se reproduce en la respuesta.
En el cuerpo de la respuesta JSON con la clave xAdobeSignClientId y su valor es el mismo ID de cliente que se envía en la solicitud.

El webhook se registrará correctamente solo en una respuesta correcta (código de respuesta 2XX) y validación del ID de cliente en el encabezado o el cuerpo de la respuesta. El propósito de esta solicitud de verificación es demostrar que la URL del webhook realmente desea recibir notificaciones en esa URL. Si escribe la dirección URL incorrecta por accidente, esta no responderá correctamente a la solicitud de verificación de la intención, y Acrobat Sign no enviará ninguna notificación a dicha dirección URL. Además, la URL del webhook también puede validar que recibiría notificaciones solo a través de los webhooks registrados por una aplicación específica. Esto se puede hacer validando el ID de cliente de la aplicación pasada en el encabezado X-AdobeSign-ClientId. Si la URL del webhook no reconoce ese ID de cliente, NO DEBE responder con el código de respuesta correcta, y Acrobat Sign se encarga que no se registre la URL como webhook.

La verificación de la llamada URL del webhook se realizará en los siguientes escenarios:

Registro del webhook: si esta verificación de la llamada URL del webhook falla, el webhook no se crea.
Actualización del webhook: INACTIVO a ACTIVO: si esta verificación de la llamada URL del webhook falla, el estado del webhook no se cambiará a ACTIVO.

Cómo responder a una notificación de webhook

Acrobat Sign realiza una verificación implícita de la intención en cada solicitud de notificación del webhook que se envía a la URL del webhook. Por lo tanto, cada solicitud HTTPS de notificación de webhook también contiene el encabezado HTTP personalizado denominado X-AdobeSign-ClientId. El valor de este encabezado es el ID de cliente (ID de aplicación) de la aplicación que creó el webhook. Consideraremos que la notificación del webhook se ha enviado correctamente si, y solo si, se devuelve una respuesta de éxito (código de respuesta 2XX) y se envía el ID de cliente en el encabezado HTTP (X-AdobeSign-ClientId) o en el cuerpo de la respuesta de JSON con una clave como xAdobeSignClientId y un valor como el mismo ID de cliente. De lo contrario, se intentará volver a entregar la notificación a la URL del webhook hasta que se agoten los reintentos.

Como se ha mencionado anteriormente, el encabezado “X-AdobeSign-ClientId” se incluye en todas las solicitudes de notificación de Sign y el valor de este encabezado (ID de cliente) se debe repetir como respuesta de dos formas:

1. Encabezado HTTP X-AdobeSign-ClientId y valor como este ID de cliente

Código JavaScript de muestra para obtener el ID de cliente, validarlo y devolverlo en el encabezado de respuesta
// Recuperar ID de cliente var clientid = request.headers['X-ADOBESIGN-CLIENTID']; //Validarlo if (clientid ==="BGBQIIE7H253K6") //Reemplace “BGBQIIE7H253K6” por el ID de cliente de la aplicación que utiliza para crear el webhook { //Devuélvalo en el encabezado de respuesta response.headers['X-AdobeSign-ClientId'] = clientid; response.status = 200; // valor predeterminado }

Código JavaScript de muestra para obtener el ID de cliente, validarlo y devolverlo en el encabezado de respuesta

// Recuperar ID de cliente

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

//Validarlo

if (clientid ==="BGBQIIE7H253K6") //Reemplace “BGBQIIE7H253K6” por el ID de cliente de la aplicación que utiliza para crear el webhook

{

//Devuélvalo en el encabezado de respuesta

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

response.status = 200; // valor predeterminado

}

Código PHP de muestra para obtener el ID de cliente, validarlo y devolverlo en el encabezado de respuesta
<?php // Recuperar ID de cliente $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Validarlo if($clientid == "BGBQIIE7H253K6") //Reemplace 'BGBQIIE7H253K6' por el ID de cliente de la aplicación que usa el webhook para su creación { //Devuélvalo en el encabezado de respuesta header("X-AdobeSign-ClientId:$clientid"); header("HTTP/1.1 200 OK"); // valor predeterminado } ?>

2. Cuerpo de la respuesta de JSON con la clave xAdobeSignClientId y el valor como el mismo ID de cliente

Código JavaScript de muestra para obtener el ID de cliente, validarlo y devolverlo en el cuerpo de la respuesta
// Recuperar ID de cliente var clientid = request.headers['X-ADOBESIGN-CLIENTID']; //Validarlo if (clientid ==="BGBQIIE7H253K6") //Reemplace “BGBQIIE7H253K6” por el ID de cliente de la aplicación que utiliza para crear el webhook { var responseBody = { "xAdobeSignClientId" : clientid // Devuelva el ID de cliente en el cuerpo }; response.headers['Content-Type'] = 'application/json'; response.body = responseBody; response.status = 200; }

Código JavaScript de muestra para obtener el ID de cliente, validarlo y devolverlo en el cuerpo de la respuesta

// Recuperar ID de cliente

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

//Validarlo

if (clientid ==="BGBQIIE7H253K6") //Reemplace “BGBQIIE7H253K6” por el ID de cliente de la aplicación que utiliza para crear el webhook

{

var responseBody = {

"xAdobeSignClientId" : clientid // Devuelva el ID de cliente en el cuerpo

};

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

response.body = responseBody;

response.status = 200;

}

Código PHP de ejemplo para obtener el ID de cliente, validarlo y devolverlo en el cuerpo de la respuesta
<?php // Recuperar ID de cliente $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //Validarlo if($clientid == "BGBQIIE7H253K6") //Reemplace 'BGBQIIE7H253K6' por el ID de cliente de la aplicación que usa el webhook para su creación { //Devolverlo en el cuerpo de la respuesta header("Content-Type: application/json"); $body = array('xAdobeSignClientId' => $clientid); echo json_encode($body); header("HTTP/1.1 200 OK"); // valor predeterminado } ?>

Código PHP de ejemplo para obtener el ID de cliente, validarlo y devolverlo en el cuerpo de la respuesta

<?php

// Recuperar ID de cliente

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//Validarlo

if($clientid == "BGBQIIE7H253K6") //Reemplace 'BGBQIIE7H253K6' por el ID de cliente de la aplicación que usa el webhook para su creación

{

//Devolverlo en el cuerpo de la respuesta

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

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

echo json_encode($body);

header("HTTP/1.1 200 OK"); // valor predeterminado

}

Cuerpo JSON de muestra de la respuesta
{ "xAdobeSignClientId": "BGBQIIE7H253K6" }

Requisitos previos

Necesitará lo siguiente:

Una cuenta de Microsoft con licencia para crear aplicaciones de funciones de Azure
Una aplicación de funciones de Azure existente, puede crear una usando https://docs.microsoft.com/es-es/azure/azure-functions/functions-create-first-azure-function
Conocimiento básico de Javascript, para que pueda comprender y escribir el código en cualquier idioma de su elección

Pasos para crear un activador de funciones de Azure que funcione como webhook de Acrobat Sign

Para crear una función de activación de HTTP de Javascript:

1. Inicie sesión a través de su cuenta de Microsoft https://portal.azure.com/

2. Abra la aplicación de funciones de Azure que se muestra en la pestaña Aplicaciones de funciones.

Vaya a Aplicaciones de funciones en Azure

Se abrirá la lista de aplicaciones de funciones de Azure:

3. Elija la aplicación en la que desea crear esta nueva función

4. Haga clic en el botón Crear (+) para crear una nueva función de Azure

5. Seleccione Webhook + API como escenario y Javascript como idioma

6. Haga clic en Crear esta función

Se crea una nueva función que tiene la capacidad de gestionar una solicitud de API entrante.

Añadir lógica para registrar el webhook de Acrobat Sign

Antes de registrar un webhook correctamente, Acrobat Sign verifica que la dirección URL de webhook proporcionada en la solicitud de registro tenga realmente la intención de recibir notificaciones o no. Para ello, cuando Acrobat Sign recibe una nueva solicitud de registro de webhook, primero realiza una solicitud de verificación a la dirección URL de webhook. Esta solicitud de verificación es una petición GET HTTPS enviada a la dirección URL de webhook con un encabezado HTTP personalizado X-AdobeSign-ClientId. El valor de este encabezado se establece en el ID de cliente de la aplicación que solicita crear o registrar el webhook. Para registrar correctamente un webhook, la URL de webhook responde a esta solicitud de verificación con un código de respuesta 2XX Y, además, puede devolver el mismo valor de ID de cliente de una de las dos maneras siguientes.

Hay dos opciones que puede seguir:

Opción 1: Transfiera el ID de cliente a X-AdobeSign-ClientId como encabezado de respuesta

Transfiera X-AdobeSign-ClientId en el encabezado de la respuesta. Es el mismo encabezado, que se transfiere en la solicitud y debe reproducirse en la respuesta.

Reemplace el archivo Index.js con lo siguiente:

module.exports = function (context, req) {

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

// Validar que el ClientID entrante sea genuino

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

context.res = {

// status: 200, /* El valor predeterminado es 200 */ // Cualquier respuesta 2XX es aceptable

body: "Notificación aceptada",

headers : {

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

}

};

}

else {

context.res = {

status: 400,

body: "¡Vaya! Llamada ilegítima identificada"

};

}

context.done();

};

Pruebe el comportamiento simulando la solicitud:

1. Haga clic en el botón de Prueba en la esquina derecha

2. Simular la solicitud ficticia

Aunque los encabezados de respuesta no se muestran arriba, pero se puede observar a través de la simulación por postman/DHC o cualquier otro servicio.

Opción 2: Transfiera el ID de cliente en el cuerpo de la respuesta con la clave xAdobeSignClientId

En el cuerpo de la respuesta de JSON con la clave de xAdobeSignClientId y su valor es el mismo ID de cliente que se envía en la solicitud.

Reemplace el archivo Index.js con lo siguiente:

Actualizar el contenido del archivo index.js

module.exports = function (context, req) {

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

// Validar que el ClientID entrante sea genuino

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

context.res = {

// status: 200, /* El valor predeterminado es 200 */ // Cualquier respuesta 2XX es aceptable

body: {

'xAdobeSignClientId' : clientId

headers : {

'Tipo de contenido' : 'application/json'

}

};

}

else {

context.res = {

status: 400,

body: "¡Vaya! Llamada ilegítima identificada"

};

}

context.done();

};

Pruebe el comportamiento simulando la solicitud

1. Haga clic en el botón de Prueba en la esquina derecha

2. Simular la solicitud ficticia

Tenga en cuenta también que se espera el mismo comportamiento para clientID cuando la URL de webhook recibe notificaciones del POST.

Listo para usar

Una vez que haya verificado el comportamiento, la URL del webhook funciona según los estándares de Acrobat Sign. Puede actualizar aún más la lógica personalizada según sus requisitos.

Obtener la URL de función

Haga clic en Obtener la URL de función

Copie la URL y utilícela para crear webhooks en Acrobat Sign.

Creación de la función AWS Lambda

Para crear una función AWS Lambda, inicie sesión en su AWS Management Console y seleccione el servicio AWS Lambda en la lista de servicios.

Haga clic en Crear una función lambda usando la opción Autor desde cero
En la página Configurar función introduzca el nombre de función lambdaWebhooks y seleccione Node.js 4.3 como motor de ejecución
Para la Función elija una función existente o cree una nueva función a partir de plantillas
- Si ha elegido Crear nuevo rol a partir de plantillas introduzca un nombre de función (p. ej. role-lambda) y seleccione Permisos simples de Microservicios de la lista de Plantillas de políticas
Haga clic en el botón Crear función

En la nueva página de la función lambda de AWS, seleccione Editar código en línea como Tipo de entrada de código, mantenga index.handler como Controlador.
Añadir lógica para registrar el webhook de Acrobat Sign
Antes de registrar un webhook correctamente, Acrobat Sign verifica que la dirección URL de webhook proporcionada en la solicitud de registro tenga realmente la intención de recibir notificaciones o no. Para ello, cuando Acrobat Sign recibe una nueva solicitud de registro de webhook, primero realiza una solicitud de verificación a la dirección URL de webhook. Esta solicitud de verificación es una petición GET HTTPS enviada a la dirección URL de webhook con un encabezado HTTP personalizado X-AdobeSign-ClientId. El valor de este encabezado se establece en el ID de cliente de la aplicación que solicita crear o registrar el webhook. Para registrar correctamente un webhook, la URL de webhook responde a esta solicitud de verificación con un código de respuesta 2XX Y, además, puede devolver el mismo valor de ID de cliente de una de las dos maneras siguientes. Tenga en cuenta también que se espera el mismo comportamiento para clientID cuando la URL de webhook recibe notificaciones del POST.

Siga uno de los dos casos:

Caso 1: Transfiera el ID de cliente a X-AdobeSign-ClientId como encabezado de respuesta
- Transfiera X-AdobeSign-ClientId en el encabezado de la respuesta. Es el mismo encabezado, que se transfiere en la solicitud y debe reproducirse en la respuesta.
  
  Fragmento de código
  En el archivo index.js, reemplace el fragmento de código generado automáticamente por el código siguiente:

El código JS de nodo de ejemplo para obtener el ID de cliente, validarlo y, a continuación, devolverlo en el encabezado de respuesta
exports.handler = function index(event, context, callback) { // Recuperar ID de cliente var clientid = event.headers['X-AdobeSign-ClientId']; //Validarlo if (clientid =="BGBQIIE7H253K6") //Reemplace 'BGBQIIE7H253K6' por el ID de cliente de la aplicación que utiliza para crear el webhook { var response = { statusCode: 200, headers: { "X-AdobeSign-ClientId": clientid } }; callback(null,response); } else { callback("¡Vaya! llamada ilegítima"); } }

El código JS de nodo de ejemplo para obtener el ID de cliente, validarlo y, a continuación, devolverlo en el encabezado de respuesta

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

// Recuperar ID de cliente

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

//Validarlo

if (clientid =="BGBQIIE7H253K6") //Reemplace 'BGBQIIE7H253K6' por el ID de cliente de la aplicación que utiliza para crear el webhook

{

var response = {

statusCode: 200,

headers: {

"X-AdobeSign-ClientId": clientid

}

};

callback(null,response);

}

else {

callback("¡Vaya! llamada ilegítima");

}

Caso 2: Transferir el ID de cliente en el cuerpo de la respuesta con la clave xAdobeSignClientId

En el cuerpo de la respuesta de JSON con la clave de xAdobeSignClientId y su valor es el mismo ID de cliente que se envía en la solicitud.

Fragmento de código

Reemplace el archivo Index.js con lo siguiente:

El código JS de nodo de ejemplo para obtener el ID de cliente, validarlo y, a continuación, devolverlo en el encabezado de respuesta
exports.handler = function index(event, context, callback) { // Recuperar ID de cliente var clientid = event.headers['X-AdobeSign-ClientId']; //Validarlo if (clientid =="BGBQIIE7H253K6") //Reemplace 'BGBQIIE7H253K6' por el ID de cliente de la aplicación que utiliza para crear el webhook { var responseBody = { xAdobeSignClientId : clientid }; var response = { statusCode: 200, body: JSON.stringify(responseBody) }; callback(null,response); } else { callback("¡Vaya! llamada ilegítima"); } }

El código JS de nodo de ejemplo para obtener el ID de cliente, validarlo y, a continuación, devolverlo en el encabezado de respuesta

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

// Recuperar ID de cliente

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

//Validarlo

if (clientid =="BGBQIIE7H253K6") //Reemplace 'BGBQIIE7H253K6' por el ID de cliente de la aplicación que utiliza para crear el webhook

{

var responseBody = {

xAdobeSignClientId : clientid

};

var response = {

statusCode: 200,

body: JSON.stringify(responseBody)

};

callback(null,response);

}

else {

callback("¡Vaya! llamada ilegítima");

}

Guarde la función. Se crea la función lambda y estamos casi listos para usarla en un webhook en tiempo real.

Configuración de AWS API Gateway

Para que esta lambda sea accesible públicamente a través de un método HTTP, necesitamos configurar AWS API Gateway usando nuestra función (creada anteriormente) como back-end para la API.

En AWS Management Console, seleccione la API Gateway en los servicios de AWS y haga clic en el botón Crear API

En la página Crear nueva API seleccione Nueva API e introduzca webhooks como el Nombre de API.
Haga clic en el botón Crear API
Seleccione la lista desplegable Acciones y seleccione la opción Crear recurso
Compruebe la opción Configurar como recurso proxy y escriba validar como el Nombre del recurso y {proxy+} en la Ruta de recurso
Deje la opción Activar API Gateway CORS y haga clic en el botón Crear recurso
Guarde el Proxy de función lambda seleccionado como Tipo de integración y seleccione el área geográfica donde ha creado su función lambda en la lista desplegable Región de lambda (probablemente sea la misma región donde está creando la puerta de enlace de API).
Entre validar como la Función lambda y haga clic en el botón Guardar
En la ventana emergente Agregar permiso a la función lambda seleccione OK

Si todos los pasos anteriores se ejecutan correctamente, verá algo como esto:

Implementación de API

El siguiente paso es implementar esta API para que esté lista para usarse.

En el desplegable Acciones seleccione Implementar API
Seleccionar [Nueva fase] en la Fase de implementación e introduzca prod (o algo que desee para identificar esta etapa) en el Nombre de fase
Haga clic en el botón Implementar.

La API ya está lista para usarse y puede encontrar la URL de invocación en el cuadro azul, como se muestra a continuación:

Tome nota de esta URL, ya que tendrá que introducirla como su URL de webhook en tiempo real.

Listo para usar

Ya está hecho. Utilice esta URL anterior con "/{nodeJSfunctionName}"POST /webhooks. Una vez que haya verificado el comportamiento, la URL del webhook funciona según los
estándares de Acrobat Sign. Puede actualizar o añadir la lógica personalizada según sus necesidades.

Cómo activar o desactivar

El acceso a la función Webhooks está habilitado de forma predeterminada para las cuentas de nivel empresarial.

Los administradores del grupo pueden crear o controlar los Webhooks que solo funcionan dentro de su grupo.

El acceso a la página Webhooks se encuentra en el carril izquierdo del menú Administración.

Limitación de velocidad basada en accesos simultáneos

Los eventos de creación y notificación de Webhook (y devolución de llamada) están limitados en el número de notificaciones simultáneas que se envían activamente al cliente desde el sistema Acrobat Sign. Este límite se aplica a la cuenta, para incluir todos los grupos dentro de la cuenta.
Este tipo de limitación de tarifas impide que una cuenta mal diseñada consuma una cantidad desproporcionada de recursos del servidor, lo que repercute negativamente en todos los demás clientes de ese entorno de servidores.

El número de eventos simultáneos por cuenta se ha calculado para garantizar que las cuentas con webhooks de buen comportamiento reciban sus notificaciones en el menor tiempo posible y rara vez se encuentren en una situación en la que las notificaciones se retrasen debido a demasiadas solicitudes. Los umbrales actuales son:

Acción (Evento)	Máximos eventos simultáneos	Descripción
Creación de webhooks	10	Se permite un máximo de 10 solicitudes de creación de webhook simultáneas por cuenta. Las solicitudes que superen este límite generarán un código de respuesta 429 TOO_MANY_REQUESTS.
Notificación de webhook/devolución de llamada	30	Se permite un máximo de 30 notificaciones simultáneas de webhook y de devolución de llamada por cuenta. Las notificaciones que superen este límite se volverán a intentar según un retroceso exponencial hasta que se entreguen.

Prácticas recomendadas

Suscribirse a eventos específicos necesarios para limitar el número de solicitudes HTTPS al servidor: cuanto más específica pueda hacer sus webhooks, menos volumen tendrá que seleccionar.
Ser resistente a duplicados: si tiene más de una aplicación que comparte la misma URL de webhook y el mismo usuario asignado a cada aplicación, se enviará el mismo evento a su webhook varias veces (una vez por aplicación). En algunos casos, su webhook puede recibir eventos duplicados. La aplicación webhook debe tolerar esto y deduplicarse por ID de evento.
Responda siempre a los webhooks rápidamente: la aplicación solo tiene cinco segundos para responder a las solicitudes de webhook. En el caso de la solicitud de verificación, esto no suele ser un problema, ya que la aplicación no necesita realizar ningún trabajo real para responder. Sin embargo, para las solicitudes de notificación, la aplicación suele hacer algo que lleva tiempo en respuesta a la solicitud. Se recomienda trabajar en un hilo independiente o utilizar una cola de forma asincrónica para garantizar que pueda responder en cinco segundos.
Administrar simultaneidad: cuando un usuario realiza una serie de cambios en sucesión rápida, es probable que su aplicación reciba varias notificaciones para el mismo usuario aproximadamente al mismo tiempo. Si no tiene cuidado con la administración de la concurrencia, la aplicación puede terminar procesando los mismos cambios para el mismo usuario más de una vez. Para poder utilizar los webhooks de Acrobat Sign, es necesario entender claramente el uso de la información. Asegúrese de hacer preguntas como:
- ¿Qué datos desea devolver en la carga útil?
- ¿Quién accederá a esta información?
- ¿Qué decisiones o creación de informes se generarán?
Recomendaciones para la recepción de documentos firmados: existen varios factores que se deben tener en cuenta a la hora de determinar cómo recibir un PDF firmado de Acrobat Sign en el sistema de gestión de documentos.

Si bien es perfectamente aceptable seleccionar el Documento firmado del acuerdo al crear un webhook, puede que le interese utilizar la API de Acrobat Sign para recuperar los documentos cuando se reciba un evento de activación (como el estado Completado del acuerdo).

Cuestiones importantes

Limitación de tamaño de JSON

El tamaño de la carga útil de JSON está limitado a 10 MB.

Si un evento genera una carga más grande, se activará un webhook, pero se eliminarán los atributos de parámetro condicional, si están en la solicitud, para reducir el tamaño de la carga.

"ConditionalParametersTrimmed " se devolverá en la respuesta cuando esto ocurra para informar al cliente de que la información conditionalParameters se ha eliminado.

conditionalParametersTrimmed es un objeto de matriz que contiene la información sobre las claves que se han recortado.

El truncamiento se realizará en el orden siguiente:

includeSignedDocuments
includeParticipantsInfo
includeDocumentsInfo
includeDetailedInfo

Los documentos firmados se truncarán primero, seguidos de la información del participante, la información del documento y, por último, la información detallada.

Esto puede ocurrir, por ejemplo, en un evento de finalización de acuerdo si incluye también un documento firmado (codificado en base 64) o en un acuerdo con varios campos de formulario

Notificaciones de webhook

Los webhooks de Acrobat Sign envían notificaciones al remitente del acuerdo y a cualquier webhook configurado dentro del grupo desde el que se envió el acuerdo. Los webhooks de las cuentas reciben todos los eventos.

Remitente: Usuario A | Firmante: Usuario B | Usuario con el que se comparte: Usuario C

El usuario A y el usuario B están en cuentas diferentes

El usuario A y el usuario C están en cuentas diferentes

Caso de uso	Notificación?	Comentarios o notas
La cuenta del usuario A tiene webhook de nivel CUENTA (creado por el usuario A o el administrador de la cuenta).	Sí	Un webhook de nivel CUENTA recibe una notificación de todos los eventos activados en esa cuenta.
La cuenta del usuario A tiene webhook de nivel GRUPO (creado por el usuario A o el administrador de la cuenta/grupo). Suposición: El usuario A y el administrador de grupo están en el mismo grupo.	Sí	Un webhook de nivel GRUPO recibe una notificación de todos los eventos activados en ese grupo.
El usuario A tiene webhook de nivel USUARIO.	Sí	Como remitente, se activa el webhook de nivel USUARIO del usuario A
El usuario A tiene webhook de nivel RECURSO (para el acuerdo enviado anteriormente).	Sí

La cuenta del usuario B tiene webhook de nivel CUENTA (creado por el usuario B o el administrador de la cuenta).	No	El Webhook de nivel CUENTA del usuario B se considera un webhook del firmante.
La cuenta del usuario B tiene webhook de nivel GRUPO (creado por el usuario B o el administrador de la cuenta o grupo). Suposición: El usuario B y el administrador de grupo están en el mismo grupo.	No	El webhook de nivel GRUPO del usuario B se considera un webhook del firmante.
El usuario B tiene webhook de nivel USUARIO.	No	El webhook de nivel USUARIO del usuario B se considera un webhook del firmante.

La cuenta del usuario C tiene webhook de nivel CUENTA (creado por el usuario C o el administrador de la cuenta).	No	EL webhook de nivel CUENTA del usuario C se considera un webhook que no es el originador.
La cuenta del usuario C tiene webhook de nivel GRUPO (creado por el usuario C o el administrador de la cuenta/grupo). Suposición: El usuario C y el administrador de grupo están en el mismo grupo.	No	El webhook de nivel GRUPO del usuario C se considera un webhook que no es originador.
El usuario C tiene webhook de nivel USUARIO.	No	El webhook de nivel USUARIO del usuario C se considera un webhook que no es originador.

Remitente: Usuario A | Firmante: Usuario B | Usuario con el que se comparte: Usuario C

El usuario A, el usuario B y el usuario C están en la misma cuenta

Caso de uso	Notificación?	Notas
La cuenta del usuario A tiene webhook de nivel CUENTA (creado por el usuario A o el administrador de la cuenta).	Sí	Los webhooks de nivel CUENTA notifican los eventos activados por la cuenta.
La cuenta del usuario A tiene webhook de nivel GRUPO (creado por el usuario A o el administrador de la cuenta/grupo). Suposición: El usuario A y el administrador de grupo pertenecen al mismo grupo.	Sí	Los webhooks de nivel GRUPO notifican los eventos activados por los usuarios de su grupo.
El usuario A tiene webhook de nivel USUARIO.	Sí	Como remitente, se activa el webhook de nivel Usuario del usuario A
El usuario A tiene webhook de nivel RECURSO (para el acuerdo enviado anterior).	Sí

La cuenta del usuario B tiene webhook de nivel CUENTA (creado por el usuario B o el administrador de la cuenta).	Sí	Dado que el Usuario A y el Usuario B se encuentran en la misma cuenta, el webhook de nivel CUENTA recibe una notificación de todos los eventos activados en esa cuenta.
La cuenta del usuario B tiene webhook de nivel GRUPO (creado por el usuario B o el administrador de la cuenta o grupo). Suposición: El usuario A, el usuario B y el administrador de grupo pertenecen al mismo grupo.	Sí	Dado que el Usuario A y el Usuario B se encuentran en el mismo grupo, el webhook de nivel GRUPO recibe una notificación de todos los eventos activados en ese grupo.
La cuenta del usuario B tiene webhook de nivel GRUPO (creado por el usuario B o el administrador de la cuenta o grupo). Suposición: El usuario A y el usuario B están en grupos diferentes.	No	El webhook de nivel GRUPO del usuario B se considera un webhook del firmante. El Webhook del usuario A (RECURSO/USUARIO/GRUPO/CUENTA) se activará.
El usuario B tiene webhook de nivel USUARIO.	No	Como destinatario, no se activará el webhook de nivel USUARIO del usuario B.

La cuenta del usuario C tiene webhook de nivel CUENTA (creado por el usuario C o el administrador de la cuenta).	Sí	Dado que el Usuario A y el Usuario C se encuentran en la misma cuenta, el webhook de nivel CUENTA recibe una notificación de todos los eventos activados en esa cuenta.
La cuenta del usuario C tiene webhook de nivel GRUPO (creado por el usuario C o el administrador de la cuenta/grupo). Suposición: El usuario A, el usuario C y el administrador de grupo pertenecen al mismo grupo.	Sí	Dado que el Usuario A y el Usuario C se encuentran en el mismo grupo, el webhook de nivel GRUPO recibe una notificación de todos los eventos activados en ese grupo.
La cuenta del usuario C tiene webhook de nivel GRUPO (creado por el usuario C o el administrador de la cuenta/grupo). Suposición: El usuario A y el usuario C están en grupos diferentes.	No	El webhook de nivel GRUPO del usuario C se considera un webhook que no es originador. El Webhook del usuario A (RECURSO/USUARIO/GRUPO/CUENTA) se activará.
El usuario C tiene webhook de nivel USUARIO.	No	El webhook de nivel USUARIO del usuario C se considera un webhook que no es originador.

Reintentar cuando el servicio de escucha esté inactivo

Si la dirección URL de destino de webhook está desactivada por cualquier motivo, Acrobat Sign pone el JSON en cola y vuelve a intentar la inclusión en un ciclo progresivo durante 72 horas.

Los eventos no entregados se conservan en una cola de reintentos y durante las siguientes 72 horas se intenta enviar las notificaciones en el orden en que se produjeron.

La estrategia para reintentar la entrega de notificaciones consiste en duplicar el tiempo entre intentos, comenzando con un intervalo de 1 minuto que aumenta a cada 12 horas, lo que se traduce en 15 reintentos en un lapso de 72 horas.

Si el receptor webhook no responde en un plazo de 72 horas y no se han realizado entregas de notificación correctas en los últimos siete días, el webhook se desactivará. No se enviarán notificaciones a esta dirección URL hasta que se active de nuevo el webhook.

Se perderán todas las notificaciones entre el momento en que se desactive el webhook y se active de nuevo posteriormente.

Adobe

Obtén ayuda de forma más rápida y sencilla

¿Nuevo usuario?

Adobe MAX
La conferencia de creatividad

Del 14 al 16 de octubre en Miami Beach y en línea

Regístrate ahora

Adobe MAX

La conferencia de creatividad

Del 14 al 16 de octubre en Miami Beach y en línea

Regístrate ahora

Adobe MAX
La conferencia de creatividad

Del 14 al 16 de octubre en Miami Beach y en línea

Regístrate ahora

Adobe MAX

La conferencia de creatividad

Del 14 al 16 de octubre en Miami Beach y en línea

Regístrate ahora

Información general de Acrobat Sign Webhook