Passer au contenu principal
La commande lobbystack travaille avec LobbyStack par l’API. lobbystack onboard lit un fichier qui décrit une entreprise et rend l’entreprise conforme à ce fichier. Elle crée l’entreprise, ajoute ses connaissances, configure la réceptionniste et les services, choisit un forfait, réserve un numéro de téléphone et envoie au propriétaire un lien pour prendre le relais. Quand vous modifiez le fichier et la relancez, elle ne change que ce qui diffère.

Installer la commande

La commande fait partie du dépôt LobbyStack. Il vous faut Node.js 26 et pnpm 10.
Le résultat tient en un seul fichier, packages/cli/dist/bin.js, qui s’exécute avec Node.js seul. Copiez-le où vous voulez, ou créez un alias :

Se connecter

lobbystack login vérifie une clé et l’enregistre, avec l’adresse du tableau de bord, dans un profil :
--key-stdin garde la clé hors de l’historique de votre shell. Sur un déploiement auto-hébergé, utilisez votre APP_BASE_URL. lobbystack whoami affiche la clé utilisée et son entreprise. La clé que vous utilisez détermine ce que onboard peut faire :
  • Une clé API de Réglages > Clés API configure sa propre entreprise, à condition que l’entreprise porte déjà le nom du manifeste ou que le manifeste donne son ID. Donnez-lui business:read, business:write, knowledge:read et knowledge:write, plus billing:manage pour un forfait, phone_numbers:manage pour un numéro et team:manage pour remettre l’entreprise, ce que seule une clé créée par un propriétaire peut faire. Consultez Authentification.
  • Une clé de plateforme crée de nouvelles entreprises. C’est l’exploitant du déploiement qui les crée ; consultez Clés de plateforme. La clé d’un exploitant, qui atteint toutes les entreprises, peut aussi donner à une entreprise un forfait et un numéro. Celle d’un partenaire ne le peut pas : le propriétaire paie les deux, et une fois qu’il a réclamé l’entreprise, la clé du partenaire ne l’atteint plus. Laissez plan et phone_number hors du manifeste d’un partenaire : le propriétaire les choisit dans le tableau de bord. La clé d’un partenaire laisse aussi au propriétaire la lecture complète d’un site.
Dans un script ou une CI, définissez LOBBYSTACK_URL et LOBBYSTACK_API_KEY au lieu de vous connecter.

Décrire l’entreprise

Décrivez l’entreprise dans un fichier YAML ou JSON, comme acme.yaml. Toutes les sections sauf business sont facultatives :
acme.yaml
Mettez les heures et les numéros de téléphone entre guillemets. Dans la forme { ... } de YAML, une virgule commence le champ suivant : écrivez donc un texte qui contient une virgule sous la forme indentée, comme la FAQ ci-dessus.
La commande ne supprime jamais ce que le fichier omet. Pour retirer un service, une règle ou une connaissance, utilisez le tableau de bord ou les autres commandes lobbystack.

Prévisualiser les changements

--plan affiche ce qu’une exécution changerait, sans rien changer :
Une erreur dans le fichier, ou un document absent ou hors du dossier du manifeste, arrête la commande avant qu’elle ne change quoi que ce soit. Le message indique où se trouve l’erreur, comme services[0].duration_minutes.

Lancer la commande

Chaque ligne dit ce qu’une étape a fait :
Un paiement et un numéro de téléphone coûtent de l’argent, donc la commande demande confirmation avant de lancer l’un ou l’autre. Passez --yes pour sauter les questions, ce dont un script a besoin : sans terminal où poser la question, la commande s’arrête. Pour configurer une entreprise qui existe déjà, mettez son ID dans business.id. --business <id> fonctionne aussi quand l’entreprise porte déjà le nom du manifeste. La commande ignore LOBBYSTACK_BUSINESS et l’entreprise enregistrée dans un profil, pour qu’un nouveau manifeste n’atterrisse jamais sur l’une d’elles par erreur. Le lien de réclamation part une fois tout le reste terminé, ou avant le paiement quand la clé d’un exploitant configure un forfait que le propriétaire paie. Quand le propriétaire l’accepte, la clé d’un partenaire et la clé API qui l’a envoyé n’atteignent plus l’entreprise, et une nouvelle exécution le signale. La clé d’un exploitant l’atteint toujours.

Quand l’exécution attend quelqu’un

Certaines étapes demandent une personne. La commande fait tout le reste, affiche ce qu’elle attend et se termine avec le code 4 :
  • Un paiement. La commande affiche le lien de paiement : envoyez-le à la personne qui paie. Tant que le forfait n’est pas payé, l’entreprise garde son forfait actuel. Le numéro de téléphone, les documents pour lesquels le forfait gratuit n’a pas de place et la lecture complète d’un site attendent le forfait payant. Une page de paiement de plus d’une heure a peut-être expiré : une exécution dans un terminal, sans --yes, propose d’en créer une nouvelle.
  • La réclamation du propriétaire. Avec la clé d’un exploitant, c’est le propriétaire de l’entreprise qui paie son forfait, donc le lien de réclamation part avant le paiement. La page de paiement est créée à la première exécution après que le propriétaire a accepté le lien.
Relancez la même commande une fois que la personne a terminé. Un paiement peut acheter un forfait pour une entreprise gratuite, ou passer de Starter à Pro. Les autres changements de forfait, comme passer de Pro à Starter ou changer d’intervalle de facturation, se font dans le portail de facturation : la commande les signale et continue.

La relancer

Relancez la commande chaque fois que le fichier change, ou après un échec. Chaque étape compare d’abord l’entreprise au fichier et ne change que ce qui diffère : une entreprise déjà conforme ne reçoit aucun changement. La commande garde les ID qu’elle crée dans un fichier d’état à côté du manifeste, comme acme.state.json. Conservez ce fichier avec le manifeste :
  • Après un échec, l’exécution suivante reprend là où la précédente s’est arrêtée. Elle renvoie les mêmes requêtes, donc elle récupère l’entreprise, le numéro ou la page de paiement déjà créés au lieu d’en créer d’autres.
  • Les fichiers sont envoyés une seule fois. Quand le contenu, le titre ou les étiquettes d’un fichier changent, l’exécution suivante envoie la nouvelle version et supprime l’ancienne. Un fichier déplacé dans le dossier garde son envoi.
  • Un document ou un site qui n’a pas pu être lu est relu une fois à l’exécution suivante. S’il échoue de la même façon, la commande le signale, et lobbystack knowledge retry <id> le relit une fois le problème réglé.
  • Un fichier d’état créé pour un tableau de bord est refusé sur un autre. Passez --state <path> pour en garder un par tableau de bord.
Sans fichier d’état, une clé de plateforme ne crée pas d’entreprise si vous en avez déjà intégré une du même nom. Mettez l’ID de cette entreprise dans business.id pour la configurer, ou donnez un autre nom à la nouvelle. Une fois l’entreprise réclamée par son propriétaire, GET /businesses ne la liste plus, même pour la clé d’un exploitant : conservez donc le fichier d’état, ou copiez dans business.id l’ID qu’affiche la première exécution.

Codes de sortie

--json affiche plutôt l’ID de l’entreprise, le fichier d’état, chaque changement et ce que l’exécution attend, en JSON.

Autres commandes

lobbystack a une commande pour chaque point de terminaison de l’API, regroupées comme l’API : lobbystack services list, lobbystack knowledge upload, lobbystack numbers search, etc. lobbystack --help liste les groupes, et --help après n’importe quelle commande liste ses options.