Passer en production
Une partie déclarée commence en observation. Ses événements sont validés, reçoivent un verdict
shadowed et restent au journal ; aucun stock ne bouge, aucune vente n'est comptée, aucun client
n'est créé.
Vérifier
Kult Lab lance les vérifications d'une partie de trois façons :
- le commerçant clique Vérifier sur la page Connexion du module API ;
- votre script de déploiement appelle
POST /api/v1/channel/verify(six fois par heure au plus) ; - le support lance
app:channel:verify.
Toutes les vérifications obligatoires réussies, la partie passe à verified.
Activer
Activer revient au commerçant. Ce geste démarre ce que démarre une première connexion :
| Partie | À l'activation |
|---|---|
| Catalogue | Kult Lab parcourt tout le catalogue par catalog.export |
| Stock | rien ne bouge : le commerçant lie les produits, règle les conflits, puis arme l'envoi du stock |
| Ventes | la date de départ est posée à maintenant ; les commandes plus anciennes passent par Importer si orders.history est vérifiée |
| Clients | rien ne démarre seul : le commerçant lance l'import et choisit qui il importe |
| Fidélité | l'adoption des soldes, avec ses conflits, puis l'envoi des points |
Les événements reçus en observation ne sont jamais rejoués : c'est le parcours lancé à l'activation qui rattrape le passé.
Après l'activation
- Désactiver remet une partie en observation. Ce qui a été appris reste : liaisons, copies, journal.
- Chaque nuit, Kult Lab relance les vérifications par sonde des parties actives. Un échec reste actif et affiche une alerte au commerçant, avec la version de votre application.
- Écrire chez vous demande encore que le commerçant arme l'envoi correspondant (stock, clients, points) : une partie active lit, un envoi armé écrit.
Arrêter
Quand le commerçant déconnecte l'application, Kult Lab envoie disconnect puis rend la main sur ce
qu'il avait suspendu chez vous. La clé est révoquée avec la connexion : vos appels suivants
reçoivent un 401 invalid_key.