Présentation de l'API
Documentation complète de l'API Cliqer, couvrant les endpoints REST et la communication en temps réel via WebSocket.
URL de base
https://cliqer.io/apiTous les endpoints de l'API sont relatifs à l'URL de base du serveur Cliqer auquel vous vous connectez.
$BASE_URL par l'URL de votre instance Cliqer (par ex. https://cliqer.io). Pour les exemples WebSocket, remplacez $WS_URL par wss://cliqer.io. Les exemples TypeScript utilisent des chemins relatifs et fonctionnent sans modification.Authentification
Cliqer authentifie les requêtes à l'aide d'un cookie de session httpOnly (session_token), émis par POST /api/auth/login. Les navigateurs l'envoient automatiquement ; les outils serveur à serveur le conservent dans un stockage de cookies. Les équipes Studio 8K et Enterprise peuvent également générer des clés API pour les requêtes REST serveur à serveur, envoyées sous la forme Authorization: Bearer cliqer_<key> (la gestion des clés nécessite le forfait Studio 8K ou Enterprise). Le WebSocket n'accepte pas les clés API : connectez-le avec un jeton de session.
# The session cookie is set by /api/auth/login and sent on every subsequent request
Cookie: session_token=YOUR_SESSION_TOKEN
# Or authenticate a server-to-server REST request with a team API key
Authorization: Bearer cliqer_<key>
Quelques endpoints ne nécessitent aucune session, comme POST /api/licenses/validate, qui est public.
Sections de l'API
Cycle de vie d'une requête
Réponses d'erreur
Tous les endpoints renvoient des réponses d'erreur standard :
| Statut | Description |
|---|---|
400 | Bad Request : paramètres manquants ou non valides |
401 | Unauthorized : aucun cookie de session valide |
403 | Forbidden : autorisations insuffisantes ou origine non autorisée |
404 | Not Found : ressource introuvable |
409 | Conflict : par ex. limite de postes atteinte lors de l'activation d'une licence |
429 | Too Many Requests : limite de débit dépassée (voir Retry-After) |
500 | Internal Server Error (erreur interne du serveur) |
Format des réponses d'erreur :
{
"statusCode": 400,
"statusMessage": "Description of the error"
}
Limitation du débit
La plupart des endpoints sont soumis à une limitation du débit par adresse IP client, avec une fenêtre fixe de 60 secondes répartie sur trois niveaux. Lorsqu'une requête dépasse la limite, le serveur répond 429 Too Many Requests avec un en-tête Retry-After: 60. Il n'y a aucun blocage progressif/exponentiel, et aucun en-tête X-RateLimit-Remaining n'est renvoyé.
| En-tête | Description |
|---|---|
Retry-After | Nombre de secondes avant la réinitialisation de la fenêtre (60, envoyé uniquement avec un 429) |
Niveaux de limitation du débit
| Niveau | Requêtes / 60 s | S'applique à |
|---|---|---|
| Strict | 5 | POST /api/licenses/validate et les endpoints de connexion (POST /api/auth/login, inscription, réinitialisation du mot de passe, étapes de clé d'accès et de 2FA) |
| Standard | 30 | GET /api/licenses/status, POST /api/licenses/deactivate, GET /api/auth/me, POST /api/auth/logout |
| Souple | 60 | Endpoints de lecture à fort volume |
Deux endpoints appliquent une seconde limite de niveau Strict, basée sur l'identifiant plutôt que sur l'adresse IP, afin qu'une même cible ne puisse pas être bombardée depuis de nombreuses adresses : POST /api/licenses/validate se base sur la license_key, et POST /api/auth/login sur l'adresse e-mail.
429 pour le reste de la fenêtre de 60 secondes. Les limites de débit sont appliquées par le serveur lui-même, avant que l'endpoint n'effectue son traitement.