# Qué es un webhook y para qué sirve en una tienda online

> Qué es un webhook, cómo avisan Shopify y BigCommerce de un cambio en el catálogo y por qué un aviso no sustituye a una sincronización periódica.

URL: https://clione.ai/es/glosario/webhook/
Lang: es

Cuando una app te promete que «se entera al momento» de lo que cambias en tu tienda, casi siempre habla de webhooks. Un webhook no es una API a la que preguntas, ni un trozo de código que se instala en el tema: **es un aviso que la plataforma envía a otra aplicación cuando pasa algo**, sea un pedido nuevo o un precio cambiado. Te importa porque de esos avisos depende que tu feed, tu [PIM](/es/glosario/pim/) o tu herramienta de marketing tengan el mismo precio que tu ficha, y porque los avisos, a veces, no llegan.

## Cómo funciona

La aplicación que quiere enterarse se suscribe a un tipo de evento y da una dirección. Cuando el evento ocurre, la plataforma le envía los datos. Shopify lo explica con los pedidos: en lugar de consultar la API una y otra vez para ver si hay pedidos nuevos, la app se suscribe al tema `orders/create` y **Shopify le envía cada pedido cuando se crea**. Sus webhooks entregan datos casi en tiempo real, sirven para mantenerse sincronizado con la tienda o para lanzar otra acción, y pueden ir a una URL, a Google Pub/Sub o a Amazon EventBridge.[^shopify-webhooks]

En BigCommerce, una suscripción se crea con una petición `POST` a `/v3/hooks`.[^bc-webhooks] Para el catálogo hay eventos de producto creado, actualizado y borrado, de cambios de inventario y de [metafields](/es/glosario/metafields/) del producto o de sus variantes. El evento `store/product/updated` salta cuando cambian, entre otros, el precio, las dimensiones, la disponibilidad, la descripción, el nombre, el [SKU](/es/glosario/sku/), la visibilidad o los datos de envío.[^bc-webhook-events]

Lo que llega en el aviso cambia mucho de una plataforma a otra. BigCommerce manda **avisos ligeros a propósito**: el de un cambio de estado de un pedido trae solo su identificador, y para ver el pedido hay que pedírselo a la API.[^bc-webhooks] El de un producto actualizado trae su identificador y la lista de propiedades que cambiaron.[^bc-webhook-events]

Tres detalles operativos deciden si un webhook funciona en la práctica:

- **La firma.** Cada entrega de Shopify lleva la cabecera `X-Shopify-Hmac-Sha256`, que sirve para comprobar que el aviso viene de Shopify, y `X-Shopify-Webhook-Id`, para reconocer las entregas repetidas.[^shopify-webhooks]
- **La respuesta.** Tu servidor tiene que contestar **en menos de cinco segundos** con un código de la serie 200 para que Shopify dé la entrega por buena. Si no, reintenta hasta ocho veces en cuatro horas, y si los fallos siguen, elimina la suscripción.[^shopify-webhooks-trouble] BigCommerce también espera un 200; reintenta con intervalos cada vez más largos y, tras el último fallo, desactiva el webhook y avisa por correo a la app suscrita.[^bc-webhooks]
- **El orden.** Shopify no garantiza el orden de los avisos, ni dentro de un mismo tema ni entre temas distintos.[^shopify-webhooks]

## Evento frente a sincronización periódica

La frase que más importa de la documentación de Shopify es una advertencia: **un webhook no siempre llega**, y una app no debería depender solo de recibirlos. Su recomendación es añadir tareas de conciliación que consulten la tienda cada cierto tiempo, filtrando por la fecha de actualización para pedir solo lo que cambió.[^shopify-webhooks] Así que la pregunta no es webhook o sincronización periódica, sino cómo se reparten el trabajo:

|                     | Webhook                                        | Sincronización periódica                           |
| ------------------- | ---------------------------------------------- | -------------------------------------------------- |
| Cuándo te enteras   | Poco después del cambio                        | En la siguiente pasada                             |
| Qué recibes         | Un aviso, a veces solo el identificador        | El estado del dato en ese momento                  |
| Qué se puede perder | Avisos no entregados, repetidos o desordenados | Lo que cambió y volvió a cambiar entre dos pasadas |
| Qué cuesta          | Un servidor que responda siempre a tiempo      | Consultas a la API, aunque no haya cambios         |

Con los dos, el aviso da la velocidad y la pasada periódica corrige lo que el aviso perdió. Sin la pasada, cada aviso perdido es una diferencia que nadie ve, y esas diferencias se acumulan hasta convertirse en [deriva de datos](/es/glosario/deriva-de-datos/).

## En una tienda

Este es el aviso de ejemplo que publica BigCommerce para un producto actualizado:[^bc-webhook-events]

```json
{
  "scope": "store/product/updated",
  "store_id": "1025646",
  "data": {
    "type": "product",
    "id": 205,
    "properties": ["warranty", "is_featured", "custom_fields"],
    "context": { "channel_id": 2, "locale": "fr" }
  },
  "hash": "a833a57fadd56a32dc752fb6ca0841dc9602a495",
  "created_at": 1561479233,
  "producer": "stores/{store_hash}"
}
```

No trae la garantía nueva, ni los campos personalizados nuevos: trae el producto 205 y **los nombres de lo que cambió**. La app que lo recibe tiene que pedir el producto a la [API de catálogo](/es/glosario/api-de-catalogo/) para saber los valores.[^bc-webhooks]

Ahora un **ejemplo ficticio** de lo que pasa cuando falla. Una tienda de trípodes cambia el precio de un modelo en su PIM, que lo escribe en BigCommerce. La app que genera el feed para un comparador está suscrita a `store/product/updated`, pero su servidor está caído esa tarde. BigCommerce reintenta durante horas y, tras el último fallo, desactiva la suscripción y manda un correo a la dirección de la app.[^bc-webhooks] Si nadie lee ese correo y la app no tiene una pasada periódica, el feed sigue con el precio viejo, y también todos los cambios que vengan después, porque ya no llega ningún aviso.


**Tener webhooks no significa tener una copia del catálogo siempre al día.** Shopify dice que la entrega de un webhook no siempre se produce y que una app no debería depender solo de los webhooks, y recomienda una conciliación periódica.[^shopify-webhooks] La otra confusión es pensar que el aviso trae el dato: en BigCommerce trae el identificador y, como mucho, qué propiedades cambiaron.[^bc-webhooks][^bc-webhook-events] Una app que guarda el aviso como si fuera el producto guarda poco más que un número.


## Cómo comprobarlo

1. **Pide a cada app conectada a tu tienda la lista de eventos a los que está suscrita** y qué hace con cada uno. Si no usa webhooks, pregunta cada cuánto consulta la tienda.
2. **Pregunta si la app tiene una pasada periódica de conciliación**, y cada cuánto corre. Es lo que Shopify recomienda para no depender solo de los avisos.[^shopify-webhooks]
3. **Si la app es tuya, comprueba que verifica la firma** de cada aviso con la cabecera `X-Shopify-Hmac-Sha256` y que descarta los repetidos por `X-Shopify-Webhook-Id`.[^shopify-webhooks]
4. **Mide cuánto tarda tu servidor en contestar**: por encima de cinco segundos, Shopify da la entrega por fallida.[^shopify-webhooks-trouble]
5. **En BigCommerce, vigila el buzón de la app**: el correo de desactivación es el único aviso de que los avisos dejaron de llegar.[^bc-webhooks]

## Concepto cercano: API de catálogo

La [API de catálogo](/es/glosario/api-de-catalogo/) y el webhook son las dos direcciones de la misma conversación. Con la API, tu aplicación pregunta y la plataforma contesta; con el webhook, la plataforma avisa sin que nadie pregunte. Shopify presenta el webhook justo como la alternativa a consultar la API una y otra vez.[^shopify-webhooks] En BigCommerce trabajan juntos por diseño: **el aviso dice qué producto cambió y la API dice cómo quedó**.[^bc-webhooks] Si lo que te preocupa es quién escribió último un campo, eso es [sobrescritura de campos](/es/glosario/sobrescritura-de-campos/), y si quieres poder volver atrás, [versionado de contenido](/es/glosario/versionado-de-contenido/).

Para seguir, la [ruta de lectura de publicación por plataforma](/es/aprender/publicacion-por-plataforma/) ordena el resto de términos.