Skip to main content
Les app builders IA font ce que tu demandes et devinent le reste. Un prompt vague te donnera un joli écran qui ne recevra jamais de commande. Les prompts de nos recettes suivent une seule structure pour que les devinettes soient faites avant que tu ne colles. Utilise la même structure pour tes propres idées.

La structure

Chaque prompt a cinq parties, dans cet ordre :
  1. Le résultat, en un paragraphe, tel que tu le décrirais à un nouveau manager. Qui l’utilise, où il tourne, ce qu’il ne doit jamais faire.
  2. Le bloc de contexte storekit ci-dessous — copié intégralement. Il indique au builder exactement comment storekit va parler à l’application, pour qu’il n’invente pas un payload ni ne saute la vérification des signatures.
  3. Ce qu’il faut construire, sous forme de liste numérotée. Indique le chemin de l’endpoint, chaque écran, chaque règle. Si tu vérifierais quelque chose lors du test, cela doit figurer dans cette liste.
  4. Définition du terminé, sous forme de cases à cocher. Le builder les utilisera pour tester son propre travail.
  5. Ce qu’il faut te rendre : l’URL publique du webhook, la liste des variables d’environnement que tu dois définir, et comment tester.
Garde tout dans un seul message. Les messages suivants servent à corriger ce que le premier a raté, pas à ajouter les exigences que tu as oubliées.

Le bloc de contexte

Colle ceci dans chaque prompt, sans modification, juste après ton paragraphe de résultat. C’est le même bloc utilisé dans toutes les recettes.
Si ton outil utilise un événement autre que order.created.v2, copie l’exemple de payload de cet événement depuis la référence des événements et ajoute-le également sous « Example payload ».

Règles à répéter

Les builders les oublient sauf si le prompt est explicite, alors chaque recette les détaille. Copie les lignes dont tu as besoin dans la partie 3 de ton prompt.
  • Vérifier la signature Svix de chaque requête en utilisant la bibliothèque officielle svix. Ne pas écrire ta propre vérification. Renvoyer 400 en cas d’échec.
  • Renvoyer 200 dès que l’événement est stocké, puis le traiter. Ne jamais faire attendre storekit sur une imprimante, un SMS ou une API tierce.
  • Ignorer tout svix-id déjà vu.
  • Conserver l’historique des événements dans une vraie base de données, pas en mémoire, pour que rien ne soit perdu au redémarrage ou au redéploiement de l’application.
  • Ne pas envoyer les noms, numéros de téléphone ou adresses des clients à un service tiers sauf si le prompt le dit.
  • Formater les montants en divisant par 100 et en utilisant la devise du magasin.
  • Afficher les heures dans le fuseau horaire local du magasin, pas celui du serveur.
  • Mettre le secret du webhook et toutes les clés API dans des variables d’environnement. Jamais dans le code.

Choisir un builder

Nous ne recommandons pas un builder plutôt qu’un autre pour tout, mais les recettes le précisent là où ça compte :
  • Les outils qui reçoivent des webhooks ont besoin d’une URL publique stable qui reste en ligne et, en général, d’une base de données. Replit te donne les trois au même endroit, c’est pourquoi les recettes qui reçoivent des événements sont écrites avec Replit en tête. Bolt et Lovable peuvent aussi le faire si tu y attaches un backend (Supabase est l’association habituelle) ; quand tu leur donnes le prompt, ajoute « déploie le backend pour qu’il ait une URL publique, et dis-moi laquelle c’est ».
  • Les outils uniquement d’affichage qui lisent depuis une base de données remplie par un autre de tes outils conviennent bien à Lovable et v0.
  • Les tâches planifiées (un résumé quotidien à 23h30, un digest hebdomadaire) ont besoin d’un endroit où faire tourner un planificateur. Demande directement au builder : « ceci doit s’exécuter tous les jours à 23h30 Europe/London ; dis-moi comment tu l’as planifié et comment je peux confirmer que ça s’est exécuté ».
Quel que soit ton choix, consulte la documentation du builder pour savoir comment il stocke les secrets et affiche l’URL déployée — les noms changent plus souvent que cette page.

Connecter l’application terminée

Une fois que le builder te donne une URL, connecte-la :
1

Open the webhooks portal

In the dashboard sidebar, go to Settings → Webhooks. If your plan includes webhooks and they are not yet enabled, click Enable Webhooks. If the page shows Upgrade to enable webhooks, contact support to discuss adding webhooks to your plan.
2

Add your app as an endpoint

In the embedded portal, add a new endpoint, paste the webhook URL your app builder gave you, and tick only the event types the recipe needs.
3

Copy the signing secret into your app

Open the endpoint you just created and copy its signing secret. In your app builder, save it as the environment variable STOREKIT_WEBHOOK_SECRET (builders call this “secrets” or “environment variables”). Redeploy if the builder asks you to.
4

Send a test event

Use the portal’s test option on the endpoint to send a sample event. The delivery log shows the response code from your app. A 2xx means your app accepted it; anything else, read the response body in the log — it is usually a missing secret.

Tester sans attendre une vraie commande

  • L’option de test de livraison dans le portail webhooks utilise un exemple générique, pas ton menu. Elle prouve la connexion et la vérification de signature ; elle ne prouve pas ta mise en page.
  • Pour un vrai payload, passe une petite commande sur ta propre boutique avec un moyen de paiement de test ou un code de réduction à 100 %, puis rembourse-la. Fais-le pendant que le journal de l’application est ouvert.
  • Casse volontairement quelque chose une fois : change STOREKIT_WEBHOOK_SECRET avec une mauvaise valeur et confirme que l’application renvoie 400 et que le portail affiche la livraison en échec. Remets ensuite la bonne valeur.

Quand le builder se trompe

Colle l’erreur, pas une description. La plupart des correctifs sont l’un des suivants :
  • « Il dit 400 dans le journal de livraison storekit. » Le secret dans l’application ne correspond pas à celui de l’endpoint, ou l’application parse le corps avant de le vérifier. Dis au builder : « vérifie le corps brut de la requête, exactement tel que reçu, avant de parser le JSON ».
  • « Il a imprimé deux fois / envoyé deux SMS. » L’application ne vérifie pas svix-id, ou fait le travail avant de renvoyer 200 et dépasse le délai. Rappelle-lui les deux règles.
  • « Ça marchait, puis a arrêté après un jour. » L’application s’est mise en veille ou l’historique était en mémoire. Demande un déploiement toujours actif et une base de données.
  • « Les prix sont 100 fois trop grands. » Les unités mineures — rappelle-lui de diviser par 100.