Authentification & tokens API

Rankion authentifie les appels API exclusivement via des tokens Bearer Laravel Sanctum. Pas d'auth par cookie, pas de Basic Auth, pas de clé API sans token. Chaque token est lié à un seul utilisateur dans une seule équipe.

Créer un token

Les tokens sont émis depuis l'interface web — Rankion n'affiche le token en clair qu'une seule fois, ensuite seul le hash est stocké en base.

1. Connecte-toi sur rankion.ai.
2. Ouvre Settings → API Tokens (lien direct : /settings/api-tokens).
3. Clique sur « Créer un nouveau token », donne-lui un nom parlant (par ex. local-dev, n8n-prod, claude-code) et éventuellement une date d'expiration.
4. Copie le token immédiatement dans ton gestionnaire de mots de passe ou dans le .env de ton application. Une fois le dialogue fermé, il n'est plus visible.

RANKION_API_TOKEN=ranKion_pat_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Utiliser le token

Chaque requête a besoin de deux headers :

Authorization: Bearer <ton-token>
Accept: application/json

Pour POST/PUT/PATCH, ajoute en plus Content-Type: application/json.

Exemple curl

TOKEN="$RANKION_API_TOKEN"
BASE="https://rankion.ai/api/v1"

# GET — lister les projets
curl -H "Authorization: Bearer $TOKEN" \
     -H "Accept: application/json" \
     "$BASE/projects"

# POST — nouveau projet
curl -X POST "$BASE/projects" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Accept: application/json" \
     -H "Content-Type: application/json" \
     -d '{"name":"My Site","domain":"example.com"}'

Exemple de réponse

{
  "data": {
    "id": 42,
    "name": "My Site",
    "domain": "example.com",
    "team_id": 7,
    "created_at": "2026-05-01T08:30:00Z"
  }
}

Scoping par équipe

Chaque token Sanctum est team-scoped. Concrètement :

• Le token « connaît » l'équipe de l'utilisateur au moment de la création.
• Tous les endpoints filtrent les ressources par team_id. Si tu tentes de lire ou modifier une ressource d'une autre équipe, l'API répond 403 Forbidden (pas de fuite de données dans le body — l'existence n'est pas révélée).
• Sur l'endpoint Image Gallery et quelques autres, le cross-team renvoie même 404 pour ne pas laisser fuiter l'existence d'un ID étranger.
• Si l'utilisateur appartient à plusieurs équipes et change d'équipe, les nouveaux tokens portent sur l'équipe courante. Les tokens existants conservent leur scope d'équipe d'origine.

Faire tourner / révoquer un token

Les tokens n'ont pas de « refresh » intégré. La rotation se fait en deux étapes :

1. Créer un nouveau token sur /settings/api-tokens.
2. Basculer le client/job sur le nouveau token.
3. Révoquer l'ancien token via le bouton « Supprimer » de la même page — dès le clic, toutes les requêtes avec l'ancien token reçoivent immédiatement 401 Unauthenticated.

En cas de fuite suspectée : révoque immédiatement, puis ré-émets. L'opération est destructive mais sûre — les jobs async en cours (par ex. une génération d'article) ne sont pas affectés, car ils tournent côté serveur.

Bonnes pratiques

• Jamais de commit dans le frontend. Les tokens sont des credentials purement serveur. Dans le code navigateur, ils sont exposés — fais transiter les appels API publics par ton propre proxy backend.
• Un token par intégration. Sépare n8n-prod, vercel-cron, claude-code-local. Si l'un fuite, tu ne révoques que celui-ci sans perturber les autres.
• Variables d'environnement plutôt que hardcoding. process.env.RANKION_API_TOKEN / getenv('RANKION_API_TOKEN') — jamais en string dans le repo.
• Définis une expiration pour les tokens temporaires (par ex. dev local, migrations ponctuelles).
• Pas de tokens dans les logs. Masque le header Authorization lors du logging des requêtes.
• HTTPS uniquement. Rankion n'accepte pas les appels HTTP — sans TLS, le token serait immédiatement compromis.

Codes d'erreur de la couche auth

Continuer avec Crédits & rate-limits.