Autenticación

Cualquier persona que conozca la URL de un webhook puede enviarle una solicitud, por lo que la autenticación es lo que impide que un desconocido active sus flujos de trabajo de Shopify Flow. Configúrela para cada webhook, en la sección «Seguridad» del webhook correspondiente.

Los tres métodos

Método	Cómo se identifica la persona que llama	Úselo cuando
Ninguno	Nada	Solo para pruebas; nunca en entorno de producción
Token estático	Un secreto fijo en el encabezado de una solicitud	Casi todas las integraciones (n8n, Make, Zapier, su propio código)
HMAC SHA-256	Una firma calculada a partir de la solicitud y un secreto compartido	El remitente firma sus webhooks (Stripe, GitHub, Slack, …)

Token estático

Pulse el botón «Generar» del webhook para obtener un token aleatorio seguro, o pegue el suyo propio. El solicitante lo envía en un encabezado:

El editor de webhooks: el nombre y la autenticación a la izquierda; la ficha «Endpoint», con el estado, la URL del webhook y el ID del webhook, a la derecha; y, encima, «Vista previa en directo», «Probar» y «Uso». — Un token estático: elija cómo lo envía el remitente, genere o pegue el token y copie la URL del webhook de la ficha «Endpoint».

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -d '{"orderId":"1001"}'

Cambiar el nombre del encabezado

Algunos sistemas solo pueden enviar un encabezado que ya utilicen. Configure el nombre del encabezado «Auth» en la sección «Configuración avanzada» y leeremos el token de ese encabezado en lugar de X-Api-Key:

bash

  -H "X-Custom-Auth: your-token"

Los nombres de los encabezados no distinguen entre mayúsculas y minúsculas. Se rechazan los nombres reservados: Host, Authorization, Cookie, X-Forwarded-*, X-Webhook-*, CF-* y similares. Estos son establecidos o reescritos por los servidores proxy y las CDN, por lo que un token leído de uno de ellos podría ser controlado por un atacante.

Por dónde circula el token

No todos los remitentes pueden añadir un encabezado arbitrario. ¿Cómo transmite el remitente el token? En la pestaña «Webhook» se ofrecen cuatro opciones:

Elección	El remitente envía	Úselo cuando
En un encabezado personalizado	`X-Api-Key: <token>` o el nombre de la cabecera que elija	La configuración predeterminada, y lo que hacen la mayoría de las integraciones
Como token al portador	`Authorization: Bearer <token>`	La herramienta cuenta con un campo «Bearer» o «Token de API»
Con su nombre de usuario y contraseña	HTTP Basic, con un nombre de usuario de su elección y el token como contraseña	La herramienta solo ofrece autenticación básica
En la URL	`?token=<token>` o el nombre del parámetro que elija	El remitente solo puede acceder a una URL sin formato y no puede configurar encabezados

Authorization Se mantiene a propósito un nombre de encabezado personalizado reservado: «Bearer» y «Basic» son los métodos compatibles para utilizarlo, y ambos se gestionan automáticamente. Una solicitud 401 con cualquiera de estos dos métodos también incluye el encabezado WWW-Authenticate, ya que varios clientes HTTP solo envían credenciales tras recibir una solicitud de autenticación.

La opción de la URL es la menos segura de las cuatro - las URL aparecen en los registros, en las fuentes de referencia y en el historial del navegador - , por lo que debe utilizarla únicamente cuando el remitente no le deje otra opción. La aplicación muestra la URL completa con el token incluido y oculta ese parámetro en todos los lugares donde almacena la solicitud.

HMAC SHA-256

El remitente calcula una firma de la solicitud utilizando un secreto compartido; nosotros la volvemos a calcular y la comparamos. Una solicitud filtrada no puede reproducirse con contenido alterado, ya que el cuerpo ya no coincide con la firma.

Configuraciones predeterminadas del proveedor

Seleccione su proveedor de firmas en la sección «Proveedor de firmas» y realizaremos la verificación siguiendo el esquema exacto de dicho proveedor: nombre del encabezado, codificación, qué se firma y cuál es el periodo de validez de la firma. Pegue el secreto de firma desde su panel de control y ya está.

Hay 22 proveedores integrados, cada uno con su propia guía de configuración: Calendly, Customer.io, GitHub, Lemon Squeezy, Linear, Mollie, Paddle, Paystack, Razorpay, Sanity, Sendcloud, Sentry, Shopify, Slack, Square, Webhooks estándar (OpenAI, Supabase), Stripe, Svix (Clerk, Resend), Typeform, Vercel, WooCommerce y Zendesk. Si el suyo no figura en la lista, describa cómo se autentica mediante un esquema personalizado.

Consulte Verificación de webhooks firmados para ver la lista completa, la opción personalizada y la herramienta integrada de comprobación de firmas.

Un webhook con autenticación HMAC y Stripe como proveedor de firmas, en el que se muestra el campo «secreto de firma», qué es lo que se comprueba y los pasos para conectar Stripe — Un remitente firmado, en este caso Stripe: seleccione el proveedor, pegue su secreto de firma y el editor le mostrará qué opciones están marcadas y cómo conectarlo.

HMAC genérico

Al no existir ningún esquema predefinido ni personalizado, utilizamos el nuestro propio: el solicitante envía un X-Signature, que es el HMAC-SHA256 de los valores del encabezado X-Webhook-* utilizando el secreto de firma.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Data: value1value2" \
  -H "X-Signature: <hmac-sha256 of the X-Webhook-* values>" \
  -d '{"data":"payload"}'

Cómo se manifiesta un rechazo

Si la autenticación falla, se devuelve un código de error 401 con un cuerpo JSON en el que se indica el motivo; consulte Historial y resolución de problemas para ver la lista completa de códigos. Las llamadas rechazadas siguen apareciendo en el «Live Request Inspector» mientras edita el webhook, por lo que podrá ver exactamente por qué se ha rechazado una.

Rotación de la clave sin tiempo de inactividad

Cambiar un secreto de una sola vez implica que todas las solicitudes firmadas con el antiguo fallarán hasta que el remitente se haya adaptado. La rotación del secreto en el webhook evita esto: mantiene un segundo secreto válido que se acepta junto con el principal, tanto para el token estático como para todos los esquemas de firma.

Introduzca la nueva contraseña en el campo «Segunda contraseña válida» y guarde los cambios. Ahora se aceptan ambas.
Cambie el remitente por el nuevo secreto.
Pulse «Promocionar», lo que lo traslada al campo principal y borra el contenido del segundo, y guarde los cambios.

No se rechaza ninguna solicitud en ningún momento. El segundo secreto se almacena exactamente igual que el principal y la API nunca lo devuelve, sino que únicamente indica si está configurado.

Mantener el secreto a salvo

Ni nuestra API REST ni nuestro servidor MCP devuelven nunca el token, sea cual sea el nivel de acceso; ellos Indique únicamente si está activado. Consulte API para desarrolladores y MCP.
Se cifra cuando está en reposo.
Al girarlo, el cambio se aplica de inmediato, por lo que le recomendamos que utilice Shopify Flow para aplicar la segunda secuencia secreta indicada anteriormente en lugar de sobrescribiendo el campo principal.
El historial de invocaciones almacenado oculta el encabezado de autenticación, las credenciales «Basic» y el token de la URL, Por lo tanto, una captura de pantalla del historial no revela su secreto.

Limitar aún más la búsqueda

La autenticación demuestra que quien realiza la llamada conoce el secreto. La autenticación de origen (Listas de direcciones IP permitidas) restringe la procedencia de una llamada y puede combinarse con cualquiera de los modos mencionados anteriormente.