Authentification
Cette page couvre l'authentification pour l'API REST et les SDKs, où l'identifiant est une clé API. Vibedasher a deux niveaux d'accès ici : l'API authentifiée (une clé API) et une petite surface publique, sans authentification.
Vous n'avez pas besoin de clé. Installez vibedasher-mcp (0.6.0 ou ultérieure) et
exécutez vibedasher login — connexion par navigateur, session dans le trousseau de votre
OS. Voir Construire avec votre agent. Les clés API
sont pour les SDKs, pour votre propre backend, et pour les machines headless/CI où aucun
navigateur ne peut s'ouvrir.
Clé API (X-Api-Key)
L'API authentifiée — jeux de données, SQL, visualisations, connexions, et plus — est
accessible avec une clé API envoyée dans l'en-tête X-Api-Key. C'est ainsi que les
deux SDKs s'authentifient, et comment le serveur MCP
s'authentifie sur une machine headless ou de CI (via VIBEDASHER_API_KEY, qui prend le pas
sur toute session de connexion stockée quand elle est définie).
Obtenir une clé
Générez une clé dans l'application sous Paramètres → Clés API sur
cloud.vibedasher.com. La création de clé est
délibérément réservée aux admins et à la session de navigateur :
POST /v1/api-keys requiert un admin de compte connecté via l'application et rejette
purement l'authentification par clé API, elle ne fait donc pas partie de la surface du SDK
et vous ne la trouverez pas dans la référence. Une clé ne peut pas générer une autre clé,
et un membre non-admin ne peut pas s'auto-provisionner une clé — c'est le principe.
Traitez une clé comme un mot de passe : elle porte l'accès de votre compte. Stockez-la dans une variable d'environnement ou un coffre-fort de secrets, jamais dans le contrôle de version.
L'envoyer
curl https://api.vibedasher.com/api/v1/datasets \
-H "X-Api-Key: $VIBEDASHER_API_KEY"
Les SDKs officiels câblent cet en-tête pour vous — vous n'avez qu'à passer la clé lors de la construction du client :
import { Vibedasher } from '@vibedasher/client';
const client = new Vibedasher({
apiKey: process.env.VIBEDASHER_API_KEY!,
});
const page = await client.datasets.list({ limit: 50 });
from vibedasher import Vibedasher
client = Vibedasher(api_key="<your-api-key>")
client.datasets.list()
Un seul hôte, routé par votre identifiant
https://api.vibedasher.com/api est l'URL de base par défaut, et c'est la seule adresse que
vous avez besoin de connaître. L'edge placé devant lit votre identifiant — le préfixe de
votre X-Api-Key, ou la région inscrite dans un jeton de session navigateur — et transmet
la requête à la région qui héberge les données de votre compte. Votre code n'a jamais à dire
où elle se trouve. (region est optionnel à partir de @vibedasher/client 4.1.5 et
vibedasher 4.3.19.)
Chaque région répond aussi sur son propre nom d'hôte,
https://api.{region}.vibedasher.com/api. Ces adresses sont pleinement prises en charge, et
c'est par elles qu'on épingle délibérément un client à une seule région : passez
region à l'un des deux SDKs, ou fixez l'URL de base à la main. Un tableau de bord éjecté
fait exactement cela — il retient l'hôte régional contre lequel il a été construit, de sorte
que le bundle que vous livrez continue d'interroger le même endroit.
Une requête qui ne porte aucun identifiant — les endpoints publics ci-dessous, et chaque
préflight CORS — est servie par la région par défaut, eu-central-1.
Endpoints publics — sans authentification
Les endpoints sous /v1/public/* ne requièrent aucune authentification. Ils ne servent
que du contenu explicitement publié et marqué public :
curl https://api.vibedasher.com/api/v1/public/viz/slug/<slug>
Les brouillons et les tableaux de bord privés renvoient 404 — il n'y a aucun moyen de lire des
données non publiées via la surface publique.
Comme ces appels ne portent aucun identifiant, l'edge n'a rien sur quoi router : ils atteignent donc la région par défaut. Si les données de votre compte vivent ailleurs, adressez la voie publique au nom d'hôte de votre propre région.
Ce qui n'est jamais exposé
L'infrastructure pure et la plomberie d'administration sont exclues entièrement de l'API — la gestion admin du cache/des jobs/des workers, les visionneurs de debug-IA et d'observabilité, les analyses cross-comptes, le transport WebSocket, et l'invocation directe de fonctions. Ces éléments font tourner l'application en interne et ne font pas partie de la surface documentée.
Besoin de quelque chose que l'API ne couvre pas encore ? Contactez-nous via la page de contact.