Authentification

Tokens Bearer

Toutes les requetes API doivent inclure un token Bearer dans le header Authorization :

Authorization: Bearer sk_live_abc123...

Les tokens sont crees depuis Dashboard > Parametres > Acces API par les proprietaires ou administrateurs du workspace quand le plan actif inclut l’API.

Scopes

Chaque token est cree avec un ou plusieurs scopes qui controlent l’acces :

Scope	Endpoints	Notes
metrics:read	/v1/me, /v1/sites, /v1/metrics/*, /v1/usage/* et endpoints lecture autorises par le plan	Les familles d’endpoints restent bornees par le plan actif
usage:read	/v1/usage/*	Donnees d’usage uniquement

Un token avec metrics:read peut toujours acceder aux endpoints d’usage — pas besoin d’un scope usage:read separe. Les rapports, les objectifs et les endpoints tenant dependent toujours du plan actif.

GET /v1/me expose maintenant l’objet produit runtime autoritaire dans product. GET /v1/sites expose l’objet produit courant au niveau site dans product_configuration, y compris collection_profile, collection_profile_effective_at et les capabilities effectives de ce site. Cet horodatage reste prospectif : changer de profil n’enrichit pas les événements plus anciens.

Les lectures analytics profile-aware exposent aussi un objet availability dans leur payload de succes. Les familles de routes Extended-only retournent toujours 409 avec des details structures quand le site ou la periode selectionnes ne sont pas compatibles avec l’enveloppe de donnees requise. Les familles de routes mixtes restent en 200 : lisez d’abord availability.readModel pour identifier le socle strict-safe, puis availability.sections pour signaler les slices enrichies encore verrouillees.

Voir aussi : Strict, Extended et rapports mixtes.

Familles de routes bornees par le plan

Famille de routes	Accès Starter	Notes
/v1/me	Oui	Toujours disponible si le plan inclut l’API.
/v1/sites	Oui	Lecture de la liste des sites du workspace.
/v1/usage/*	Oui	Lecture de la consommation sans unités facturées.
/v1/metrics/*	Oui	Timeseries et breakdown standards.
/v1/reports/*	Non	Disponible uniquement quand la politique API active autorise ces routes.
/v1/goals*	Non	Disponible uniquement quand la politique API active autorise ces routes.
/v1/tenants	Non	Disponible uniquement quand l'API tenant est activée sur le plan actif.

Allowlist de sites

Les tokens peuvent etre restreints a des sites specifiques. Quand une allowlist est configuree, le token ne peut interroger que les donnees de ces sites.

Si aucune allowlist n’est definie, le token peut acceder a tous les sites de le workspace.

Allowlist de tenants

Les tokens peuvent aussi etre restreints a des boutiques specifiques via allowedTenantIds quand le plan actif autorise l’API tenant.

Quand une allowlist tenant est configuree, passez tenant_id dans vos appels analytics et utilisez GET /v1/tenants pour recuperer les boutiques accessibles pour un site_id. Les allowlists tenant sont verifiees sur le tenant_id stable, pas sur le slug de routage.

Voir aussi : Analytics multi-tenant et le Guide multi-tenant.

Securite des tokens

• Les secrets sont affiches une seule fois a la creation — stockez-les en securite
• Les tokens sont hashes cote serveur et ne peuvent pas etre recuperes
• La revocation prend effet immediatement sur toutes les requetes suivantes
• Chaque requete est validee en DynamoDB — il n’y a pas de cache de token

Headers de requete

Header	Requis	Description
Authorization	Oui	Bearer sk_live_...
X-Request-Id	Recommande	ID de requete genere par le client pour le debug et le support

Rate limiting

Les requetes sont limitees par token dans des fenetres glissantes de 60 secondes. Les limites varient selon le plan (voir Limites et tarification).

En cas de depassement, l’API retourne 429 avec ces headers :

Header	Description
X-RateLimit-Limit	Max de requetes dans la fenetre courante
X-RateLimit-Remaining	Requetes restantes (0 quand limite)
X-RateLimit-Reset	Timestamp Unix de reinitialisation de la fenetre