Recette et dépannage

Recette et dépannageLa recette de véritéSept vérifications, dans l'ordre. Chacune ne prend que quelques secondes, et chacune ferme une cause de panne — c'est ce qui évite de chercher au mauvais endroit.1. La clé répond

bash

curl https://api.inovertix.com/api/inoshop/ingest/ping \
  -H "Authorization: Bearer INOSHP_ING_votre_cle"

Vous devez lire le nom de votre boutique. Si vous lisez celui d'une autre, la clé n'est pas la bonne.2. Votre statut est reconnuDans la réponse du ping, accepted_statuses liste ce que nous savons traduire. Le mot que votre application écrit doit y figurer. Sinon, dites-le nous : c'est un réglage de la boutique, pas une modification de votre code.3. Une vente de test arriveFaites une vraie souscription à un tarif minimal. Elle doit apparaître dans le cockpit INOSHOP avec son type, son plan et sa périodicité — pas seulement avec son montant. Si le type manque, c'est order.kind qui n'est pas envoyé.4. L'achat arrive chez Meta, en « Serveur »Ouvrez l'Events Manager de votre pixel, onglet Événements de test, avec le code de test que nous avons renseigné. Vous devez y voir un Purchase dont la source est Serveur — et non Navigateur.Regardez ensuite la qualité de correspondance (EMQ). En dessous de 5, il manque des signaux : vérifiez que tracking part bien avec la vente, et que l'IP et le user-agent sont ceux du client, pas ceux de votre serveur (l'erreur la plus fréquente, et la plus silencieuse).5. Le rejeu ne crée pas de doublonRenvoyez exactement le même appel. Vous devez lire "result": "duplicate", et rien de nouveau ne doit apparaître ni dans le cockpit ni dans l'Events Manager.6. L'attribution est làSi votre site est mesuré par INOTRACK et que vous avez transmis session_uid, la vente doit porter sa source d'acquisition dans le cockpit. Sinon, c'est que le cookie de session n'a pas été lu au checkout.7. Retirez le code de testTant qu'un code de test est renseigné, aucun événement de la boutique n'alimente vos statistiques ni vos audiences Meta. C'est l'étape qu'on oublie, et elle coûte des semaines de mesure.Surveillez ensuite l'ingestion pendant 48 heures avant de considérer la mise en service terminée.Le tableau des refusCodes HTTP

Code	`code`	Cause réelle, et ce qu'on fait
`401`	`missing_api_key`	La clé n'est pas dans l'en-tête. Elle n'est jamais lue dans l'URL : `Authorization: Bearer INOSHP_ING_…`.
`401`	`invalid_api_key`	Clé inconnue, ou révoquée. Si le message nomme un autre module (INOTRACK, INODESK…), c'est une clé d'un autre produit collée par erreur.
`403`	`shop_inactive`	La boutique est désactivée dans le cockpit. Les ventes déjà reçues restent consultables ; les nouvelles sont refusées. Contactez-nous.
`422`	`empty_payload`	Ni `external_ref` au premier niveau, ni tableau `events`.
`422`	`too_many_events`	Plus de 100 événements dans un lot. Découpez.
`422`	`invalid_payload`	Le catalogue attend `products: []`, non vide, 200 entrées au maximum.
`429`	`rate_limit_exceeded`	Trop d'appels sur la minute. Réessayez : l'ingestion est idempotente, un rejeu ne crée rien.

Verdicts par élément (dans un 200)

`result` / `reason`	Ce qui s'est passé
`duplicate`	Déjà reçu. Ce n'est pas une erreur — c'est exactement ce que l'idempotence doit produire. Aucune action.
`error` / `invalid_external_ref`	`external_ref` absent, vide, ou de plus de 100 caractères.
`error` / `unknown_event`	`event` doit valoir `created`, `updated` ou `status_changed`.
`error` / `unknown_status`	Le statut n'est pas traduisible. Le plus fréquent en mise en service. Le message cite le statut reçu : envoyez-le nous, nous l'ajoutons au mapping de la boutique.
`error` / `invalid_occurred_at`	Date illisible, dans le futur, ou trop ancienne. Le futur est presque toujours une erreur de fuseau : envoyez du ISO 8601 avec son décalage (`2026-09-01T10:15:00+00:00`).
`error` / `source_not_push`	La clé désigne une boutique qu'INOSHOP interroge (WooCommerce). Ce n'est pas la bonne boutique.
`error` / `write_failed`	Incident de notre côté. Rejouez : c'est sans risque.

Les symptômes, et leur cause« Tout répond accepted, mais je ne vois rien dans l'Events Manager »Trois causes, dans l'ordre de fréquence :

Le statut n'est pas « confirmé ». Une vente pending est enregistrée mais n'est pas une vente : rien ne part. Vérifiez mapped_status dans le journal d'ingestion.

Un code de test est actif et vous regardez l'onglet des événements réels — ou l'inverse.

Le pixel ou le jeton Meta de la boutique n'est pas renseigné. Dans ce cas la vente est bien enregistrée, mais aucun envoi n'est tenté : nous le voyons dans le cockpit.

« Mon renouvellement n'apparaît pas »La référence est la même que le mois précédent : nous répondons duplicate, comme prévu. Une échéance = une external_ref (sub_1042_2026-09, sub_1042_2026-10).« L'EMQ est très bas »Le tracking est vide, ou rempli au moment de l'appel serveur. Ses valeurs doivent être lues dans le navigateur au checkout puis stockées : au moment où votre serveur nous appelle, l'IP est celle de votre serveur et le user-agent celui de votre client HTTP. Voyez la section correspondante du guide Laravel.« J'ai remboursé, mais Meta compte toujours la vente »C'est attendu. Le statut change dans le cockpit ; aucun événement correctif n'est envoyé à Meta, parce que Meta n'offre pas de mécanisme officiel de déduction d'un achat déjà transmis. En inventer un fausserait vos statistiques plus sûrement qu'il ne les corrigerait.« J'ai perdu ma clé »Elle ne se retrouve pas — nous n'en stockons que l'empreinte. Elle se régénère, et l'ancienne se révoque. Les ventes déjà reçues ne bougent pas.