Produktions-API

Barrierefreiheitsprüfungen aus dem eigenen Workflow starten

Verwenden Sie einen berechtigten Organisationsschlüssel, um Seiten- oder Website-Scans zu starten und stabile strukturierte Ergebnisse zu lesen.

API-Schlüssel erstellen Interaktive API-Referenz

Schnellstart

Die Developer API verwendet eingeschränkte Schlüssel, nicht die Browser-Anmeldung.

Melden Sie sich bei wcagc an und erstellen Sie unter Einstellungen → Developer API einen Schlüssel.
Kopieren Sie den vollständigen Schlüssel bei der einmaligen Anzeige und speichern Sie ihn im Secret Manager.
Vergeben Sie nur benötigte Berechtigungen. Wählen Sie in Swagger Authorize und fügen Sie den Schlüssel ohne das Wort Bearer ein.
Senden Sie den Schlüssel an https://api.wcagc.com im Header Authorization: Bearer.

curl https://api.wcagc.com/api/v1/sites \
  -H "Accept: application/json" \
  -H "Authorization: Bearer $WCAGC_API_KEY"

Authentifizierung

Schlüssel beginnen mit wcagc_ und werden nur einmal vollständig angezeigt. Speichern Sie sie geheim, vergeben Sie nur nötige Rechte und widerrufen Sie offengelegte Schlüssel sofort.

/api/auth/login fehlt bewusst in der öffentlichen Spezifikation: Dieser Pfad erzeugt eine Cookie-Sitzung für die Web-App und ist nicht die Authentifizierung für Skripte.

Anfragelimit

Standardmäßig sind 120 Anfragen pro Minute und Schlüssel möglich. Eine 429-Antwort enthält Retry-After.

Berechtigungen

Die meisten REST-Pfade benötigen die Planfunktion Developer API. CI verwendet die separate Berechtigung ci:check und ein eigenes Planlimit; KI-Assistenten und Browser-Erweiterung haben eigene Dokumentation.

sites:read: Registrierte Websites der Organisation auflisten.
scans:write: Seiten- und vollständige Website-Scans starten.
scans:read: Status, Zähler, Fortschritt und Befunde lesen.
ci:check: Begrenzte CI-Prüfungen mehrerer URLs innerhalb des Organisationslimits starten und lesen.

Den passenden API-Auftrag wählen

Die Referenz ist nach stabilen Aufgaben statt nach internen Web-App-Pfaden gegliedert. Jede Ressource ist auf die Organisation des Schlüssels begrenzt.

Websites abrufen

Registrierte Website-IDs vor einem vollständigen Lauf, einem Trend oder der Auswahl einer gespeicherten Journey abrufen. Benötigt sites:read.

GET /api/v1/sites

Eine Seite prüfen

Eine Seite einer registrierten Website einreihen, den Scan abfragen und anschließend stabile Befunde lesen. Benötigt scans:write und scans:read.

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

Registrierte Website crawlen

Einen vollständigen Lauf einreihen und Fortschritt, Befunde sowie deterministische Ursachen-Gruppen lesen. Benötigt scans:write und 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

Journeys ausführen und Korrekturen prüfen

Serverseitig gespeicherte Schritte und Zugangsdaten verwenden; API-Anfragen enthalten niemals Anmeldedaten. Trends und gezielte Nachprüfungen verwenden die normalen Lese- und Schreibrechte.

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

CI absichern

Bis zum Planlimit URLs einer verifizierten Website prüfen, das Ergebnis lesen und baselinebezogene Befunde abrufen. Benötigt ci:check.

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

Erstellen, abfragen, dann Befunde lesen

Scans, Läufe, CI-Prüfungen, Journeys und Korrekturprüfungen werden asynchron erstellt. Ein erfolgreicher POST liefert 202 Accepted, eine Ressourcen-ID und einen Location-Header.

Fragen Sie die Location-Ressource mit begrenztem Backoff bis zu einem Endstatus ab. Lesen Sie Befunde erst nach Abschluss; QUEUED oder RUNNING ist noch kein Ergebnis.

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"

Stabile Fehlercodes behandeln

Fehler verwenden application/problem+json. Verzweigen Sie nach code, bewahren Sie traceId für den Support auf und behandeln Sie detail als veränderlichen Klartext-Kontext.

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"
}

Interaktive und maschinenlesbare Referenz

Swagger listet alle unterstützten Operationen der Developer API v1, benötigte Berechtigungen, Anfrageschemas, Antwortstatus und Beispiele. Das OpenAPI-3.1-JSON lässt sich in API-Clients und Codegeneratoren importieren.

Swagger UI öffnen OpenAPI JSON herunterladen

Signierte ausgehende Webhooks

Abonnieren Sie einen HTTPS-Endpunkt für Scan-Abschlüsse, Regressionen und Statusänderungen. Jede JSON-Zustellung enthält eine HMAC-SHA256-Signatur, eine stabile Zustell-ID und automatische Wiederholungen.

Webhooks konfigurieren

Prüfen Sie X-Wcagc-Signature über timestamp + '.' + den unveränderten Request-Body. Lehnen Sie alte Zeitstempel ab, um Replay-Risiken zu reduzieren.

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