Historial y resolución de problemas
Se registra cada solicitud que llega a un webhook, tanto si se acepta como si se rechaza. El historial es el primer lugar donde hay que buscar cuando algo no ha sucedido.
Lectura de una invocación
Abra «Historial» y haga clic en una entrada. Podrá ver la marca de tiempo, el estado, el origen de la llamada, la duración, la payload, los encabezados de la solicitud (ocultos), la cadena de consulta y, en caso de fallos, el error y cada intento de reintento.
| Estado | Significado |
|---|---|
| Pendiente | Aceptado y en cola, aún no se ha enviado a Shopify Flow |
| Éxito | Shopify Flow aceptó el activador |
| Fallido | La entrega ha fallado de forma definitiva; en la página de detalles se explica el motivo |
La columna «Invoked by» le indica de dónde procede una llamada: User (un sistema externo), Flow (una acción de Shopify Flow que activa el webhook), Test (el botón «Probar») o CURL.
Los rechazos y lo que significa cada uno de ellos
Una solicitud rechazada nunca llega a Shopify Flow. El cuerpo de la respuesta incluye un código de estado code legible por máquina:
| Código | HTTP | ¿Qué salió mal? | Corregir |
|---|---|---|---|
webhook_not_found |
404 | Código corto desconocido | Compruebe la URL; es posible que se haya eliminado el webhook |
webhook_disabled |
400 | El webhook está desactivado | Actívelo en la página de webhooks |
unauthorized |
401 | Falta el token o es incorrecto | Compruebe el token y el nombre del encabezado |
missing_signature |
401 | Modo HMAC, sin encabezado de firma | Envíe el encabezado de firma que espera su preajuste |
invalid_signature |
401 | La firma no coincidía | Confirme el secreto de firma y que el cuerpo del mensaje no haya sufrido modificaciones durante la transmisión |
auth_not_configured |
401 | Se ha configurado el modo «Auth», pero no se ha guardado ningún token | Guarde un token en el webhook |
invalid_json |
400 | El cuerpo no es un JSON válido | Envíe un JSON válido o establezca el tipo de contenido («Content-Type») que realmente tiene el cuerpo del mensaje (también se leen los datos de formulario y el XML). |
invalid_body |
400 | No se ha podido leer un formulario o el cuerpo XML, o bien el cuerpo es el texto literal null |
Envíe un objeto JSON o un cuerpo que coincida con su tipo de contenido (Content-Type) |
mapping_field_missing |
400 | Falta un campo asignado en la payload | Envíe el campo o elimine su asignación |
unexpected_fields |
400 | El cuerpo contiene campos que no están asignados | Asigne una relación, elimínelas o active la opción «Permitir cuerpo de solicitud personalizado» |
ip_not_allowed |
403 | La dirección del solicitante no figura en la lista de direcciones IP permitidas del webhook | Consulte Listas de direcciones IP permitidas |
invalid_proxy_signature |
401 | Se ha accedido a la dirección del proxy de la aplicación directamente, en lugar de a través del dominio de su tienda | Utilice la URL del webhook tal y como aparece en la aplicación; consulte CORS, la URL del proxy de la aplicación y las llamadas del navegador |
payload_too_large |
413 | Shopify Flow payload superior a 50 KB | Envíe menos datos o desactive los botones de solicitud de datos |
quota_exceeded |
400 | Se ha alcanzado el límite del plan | Consulte Planes y uso |
Inspector de solicitudes en tiempo real
Mientras tenga un webhook abierto en el editor, el inspector muestra las solicitudes que llegan en tiempo real, incluidas las rechazadas, junto con el motivo. Esta es, con diferencia, la forma más rápida de depurar un remitente: envíe una solicitud y observe cómo se procesa.
Aquí también aparecen los duplicados eliminados, identificados como tales; consulte Protección contra entregas duplicadas.
Repetición
Cualquier invocación anterior se puede reproducir desde su página de detalles. La reproducción reenvía la misma payload a través del mismo webhook.
Hay dos cosas para las que resulta muy útil:
- Creación de un flujo de trabajo en Shopify Flow. Registre eventos en el activador de webhook y, a continuación, reproduzca un evento real Realice la llamada para que Shopify Flow aprenda los nombres reales de sus campos.
- Recuperación tras una interrupción del flujo de trabajo. Corrija el flujo de trabajo y, a continuación, vuelva a ejecutar los eventos que se habían ejecutado. aunque estuviera mal.
Las repeticiones aparecen marcadas como tales en el historial y no se contabilizan en su plan.
Situaciones habituales
Se reciben llamadas, pero el flujo de trabajo no se ejecuta. Casi siempre se debe a la condición del ID del webhook. Un flujo de trabajo con activador de webhook recibe eventos de todos los webhooks de los que dispone, por lo que necesita una condición que coincida con el ID específico del webhook; consulte Cree su primer webhook.
El flujo de trabajo se ejecuta dos veces. O bien hay dos flujos de trabajo que utilizan el activador «Webhook» sin condiciones específicas, o bien su remitente está realizando un nuevo intento. El historial le indica cuál de las dos opciones es la correcta: dos entradas significan que se han recibido dos solicitudes. Active la opción Protección contra entregas duplicadas.
No aparece nada en el historial. La solicitud nunca nos llegó. Compruebe la URL y el código corto, y asegúrese de que el remitente no tenga problemas con TLS o DNS por su parte.
El estado permanece en «Pendiente». Se vuelve a intentar la entrega con un mecanismo de retroceso; un fallo permanente cambia el estado a «Fallido» con el motivo correspondiente. Si permanece en «Pendiente» durante un tiempo inusualmente prolongado, compruebe status.codecreationlabs.cloud.