API

Vos workflows, appelables par HTTP.

Passez un workflow en mode App : il devient une route HTTP. Votre backend, n8n ou Make le lance avec une clé, fixe un plafond de crédits et récupère les images ou les vidéos produites.

  • Sans abonnement pour un compte personnel
  • Même prix que dans l’application
  • 60 requêtes par minute et par clé
Exemple : lancer une app
curl -X POST "$BASE/v1/apps/proj_3d90b7:wf_8f2c1a4e/runs" \
  -H "Authorization: Bearer $BEEMM_KEY" \
  -H "Idempotency-Key: commande-4821" \
  -H "Content-Type: application/json" \
  -d '{"inputs":{"prompt":"sac en cuir camel, fond studio"},"maxCredits":20}'

Réponse 202

{ "id": "api7c1e…", "object": "run", "status": "queued", "pollAfterSeconds": 3 }

De l’éditeur à la production en trois gestes

  1. 01Activez le mode AppDans l’éditeur du workflow. Posez le rôle Entrée sur les nœuds qui deviennent des paramètres (texte, nombre, import…), et Sortie sur ceux dont vous voulez le résultat. Aucune publication à faire.
  2. 02Créez une cléRéglages → Développeurs → Clés API. Droit Lecture ou Exécution, une clé par intégration, et une enveloppe mensuelle si la clé est confiée à un tiers.
  3. 03Lancez, puis lisez le résultatPOST /runs rend l’identifiant du run. GET /runs/{runId} rend l’état, puis les URL des images et des vidéos produites.

Pensée pour ne jamais facturer deux fois

Une intégration qui boucle ou qui relance après une coupure réseau ne doit pas vider un portefeuille. Ces garde-fous sont obligatoires, pas optionnels.

Un plafond par run

maxCredits est exigé à chaque lancement. Le run s’arrête avant le débit qui le dépasserait ; ce qui n’est pas exécuté n’est pas facturé.

Un retry sans double facture

Même Idempotency-Key et même corps : vous récupérez le run existant, rien n’est relancé ni refacturé.

Une enveloppe mensuelle par clé

Une clé confiée à n8n ou à un prestataire ne dépasse jamais le budget que vous lui avez fixé. Le plafond se change sans remplacer la clé.

Un contrat qui se vérifie

Chaque fiche d’app et chaque run portent un contractHash. Il change seulement quand les paramètres attendus changent, jamais quand vous déplacez un nœud ou changez de modèle.

Six routes, c’est tout

Authentification par en-tête Bearer, erreurs typées par un code stable.

  • GET/v1/modelsModèles exécutables
  • GET/v1/balanceVotre solde et l’enveloppe de la clé
  • GET/v1/appsVos workflows en mode App
  • GET/v1/apps/{appId}Paramètres et sorties d’une app
  • POST/v1/apps/{appId}/runsLancement d’un run (dépense des crédits)
  • GET/v1/runs/{runId}État et résultat d’un run

Questions fréquentes

Faut-il un abonnement pour utiliser l’API Beemm Vision ?
Non, pas pour un compte personnel : créer une clé et lancer une app demandent seulement des crédits. Les organisations gardent leur abonnement. Une clé sans crédits peut encore lire vos apps et vos résultats, mais ne lance plus de run.
Peut-on générer une image en une seule requête ?
Pas directement : l’API lance des workflows. Placez le modèle dans un workflow, même d’un seul nœud, passez-le en mode App, puis lancez-le. Vous choisissez ainsi le modèle, les réglages et les sorties une fois pour toutes.
Combien coûte un run lancé par l’API ?
Le même prix en crédits que dans l’application, débité nœud par nœud. Vous fixez le maximum à chaque appel avec maxCredits : le run s’arrête avant de le dépasser.
Quelle différence avec le connecteur MCP ?
Le connecteur MCP sert à piloter Beemm Vision depuis un assistant comme Claude ou ChatGPT, en conversation. L’API sert à un programme : un backend, un scénario n8n ou Make, qui lance vos workflows sans intervention.

Branchez votre premier workflow

Créez une clé dans les Réglages, copiez l’identifiant d’app affiché dans l’éditeur, lancez. Pour un volume important ou une organisation, l’équipe vous répond.

À lire ensuite