API de production

Lancez des contrôles d’accessibilité depuis votre flux

Utilisez une clé d’organisation à droits limités pour lancer des scans de page ou de site et lire des résultats structurés stables.

Démarrage rapide

La Developer API utilise des clés à droits limités, pas la connexion du navigateur.

  1. Connectez-vous à wcagc et créez une clé dans Paramètres → Developer API.
  2. Copiez la clé complète lors de son unique affichage et stockez-la dans votre gestionnaire de secrets.
  3. N’accordez que les droits nécessaires. Dans Swagger, choisissez Authorize et collez la clé sans ajouter le mot Bearer.
  4. Envoyez la clé à https://api.wcagc.com dans l’en-tête Authorization: Bearer.
curl https://api.wcagc.com/api/v1/sites \
  -H "Accept: application/json" \
  -H "Authorization: Bearer $WCAGC_API_KEY"

Authentification

Les clés commencent par wcagc_ et ne sont affichées en entier qu’une fois. Stockez-les comme secrets, limitez leurs droits et révoquez immédiatement toute clé exposée.

/api/auth/login est volontairement absent de la spécification publique : ce chemin crée une session par cookie pour l’application web et n’authentifie pas les scripts.

Limite de requêtes

Chaque clé autorise 120 requêtes par minute par défaut. Une réponse 429 inclut Retry-After.

Autorisations

La plupart des routes REST nécessitent la fonctionnalité de plan Developer API. La CI utilise l’autorisation ci:check et son propre quota ; les assistants IA et l’extension de navigateur ont leur documentation dédiée.

sites:read
Lister les sites enregistrés de l’organisation.
scans:write
Lancer des scans de page et de site complet.
scans:read
Lire l’état, les compteurs, la progression et les constats.
ci:check
Lancer et lire des contrôles CI limités à plusieurs URL selon le quota de l’organisation.

Choisissez la tâche API adaptée

La référence est organisée autour de tâches stables plutôt que des routes internes de l’application web. Chaque ressource est limitée à l’organisation propriétaire de la clé.

Lister les sites

Récupérez les identifiants des sites enregistrés avant un scan complet, la lecture d’une tendance ou le choix d’un parcours. Nécessite sites:read.

GET /api/v1/sites

Contrôler une page

Mettez en file une page d’un site enregistré, interrogez le scan, puis lisez ses constats stables. Nécessite scans:write et scans:read.

POST /api/v1/scans GET /api/v1/scans/{id} GET /api/v1/scans/{id}/violations

Explorer un site enregistré

Mettez en file un scan complet, puis lisez la progression, les constats et les groupes de causes déterministes. Nécessite scans:write et scans:read.

POST /api/v1/scan-runs GET /api/v1/scan-runs/{id} GET /api/v1/scan-runs/{id}/violations GET /api/v1/scan-runs/{id}/root-causes

Exécuter des parcours et vérifier des corrections

Utilisez les étapes et identifiants stockés côté serveur ; les requêtes API ne transportent jamais de secrets de connexion. Les tendances et revérifications utilisent les droits habituels.

GET /api/v1/sites/{id}/journeys POST /api/v1/journeys/{id}/runs GET /api/v1/sites/{id}/trend POST /api/v1/remediation-items/{id}/verifications

Contrôler la CI

Contrôlez jusqu’à la limite du plan des URL d’un même site vérifié, lisez le verdict et les constats liés à la baseline. Nécessite ci:check.

POST /api/v1/ci/checks GET /api/v1/ci/checks/{id} GET /api/v1/ci/checks/{id}/violations

Créer, interroger, puis lire les constats

La création des scans, explorations, contrôles CI, parcours et revérifications est asynchrone. Un POST réussi renvoie 202 Accepted, un identifiant et un en-tête Location.

Interrogez la ressource Location avec un délai borné jusqu’à un état final. Ne lisez les constats qu’après la fin ; QUEUED ou RUNNING n’est pas encore un résultat.

curl -X POST https://api.wcagc.com/api/v1/scans \
  -H "Authorization: Bearer $WCAGC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com/checkout"}'
curl https://api.wcagc.com/api/v1/scans/{id} \
  -H "Authorization: Bearer $WCAGC_API_KEY"

curl https://api.wcagc.com/api/v1/scans/{id}/violations \
  -H "Authorization: Bearer $WCAGC_API_KEY"

Traitez les codes d’erreur stables

Les erreurs utilisent application/problem+json. Branchez la logique sur code, conservez traceId pour le support et considérez detail comme un contexte lisible susceptible d’évoluer.

  • 401 API_KEY_INVALID
  • 403 API_KEY_SCOPE_MISSING / FEATURE_NOT_IN_PLAN
  • 404 *_NOT_FOUND
  • 409 *_ALREADY_RUNNING
  • 422 VALIDATION_FAILED / INVALID_URL
  • 429 RATE_LIMITED + Retry-After
{
  "type": "https://wcagc.com/problems/api-key-scope-missing",
  "title": "API key scope missing",
  "status": 403,
  "detail": "The API key does not grant the required scope.",
  "instance": "/api/v1/sites",
  "code": "API_KEY_SCOPE_MISSING",
  "traceId": "019c…",
  "timestamp": "2026-08-19T20:57:19Z"
}

Référence interactive et lisible par machine

Swagger répertorie chaque opération prise en charge par la Developer API v1, l’autorisation requise, les schémas, les statuts et les exemples. Le JSON OpenAPI 3.1 peut être importé dans des clients API et générateurs de code.

Webhooks sortants signés

Abonnez un point de terminaison HTTPS aux fins de scan, régressions et changements de remédiation. Chaque livraison JSON comprend une signature HMAC-SHA256, un identifiant stable et des tentatives automatiques.

Configurer les webhooks

Vérifiez X-Wcagc-Signature sur timestamp + '.' + le corps brut inchangé. Refusez les horodatages anciens pour limiter les rejeux.

X-Wcagc-Event: scan_run.completed
X-Wcagc-Delivery: 019f…
X-Wcagc-Timestamp: 178406…
X-Wcagc-Signature: v1=<hmac-sha256>