Código JavaScript de muestra para obtener el ID de cliente, validarlo y devolverlo en el encabezado de respuesta
Última actualización el
08-07-2026
Información general
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í:
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.
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
|
|
|---|
|
// 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 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.
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:
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:
- 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.
|
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"); } } |
- 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 |
Máximos |
Descripción |
|
Creación de webhooks |
10 |
Se permite un máximo de 10 solicitudes de creación de webhook simultáneas por cuenta. |
|
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. |
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
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.
Optimizar tu trabajo con Acrobat Sign
Gestiona y firma documentos online de forma rápida y sencilla.
