Wiring AccessLedger into your own tools

Start here

Pick the one that fits

GitHub Action

Scans a page or a whole verified site on every push or pull request, comments the result on the pull request, and fails the build when issues at or above a severity you choose appear. Configuration is about eight lines of YAML.

Use this if your question is "did this change break accessibility". It is the answer for most people and it needs no code.

JSON API

Start scans, poll them, list your sites and read the open issues on any of them. Ordinary HTTP and JSON with a bearer token, no client library required.

Use this if you are building something of your own: a dashboard, a report for a client, a pipeline that is not GitHub Actions, or anything that needs the issue history rather than a single scan.

Tokens

Getting a token

Both routes use the same token. Create one at Account, then API tokens. The full token is shown once, when it is created, and never again. If you lose it, revoke it and make another.

Tokens carry scopes. A read token can list sites and read results but cannot start anything. Give a token the narrowest scope that does its job, and use a separate token per system so revoking one does not break the others.

A token is a password. Put it in a repository secret or a secret manager, never in a committed file. Anyone holding it can spend your scan quota and read every finding on your account.

When something breaks

Was it us

Both the API and the Action distinguish a failure of our service from a finding about your site, and you should treat them differently. An accessibility finding should fail your build. Our scanner falling over should page us, not you.

The status page reports what is actually working, measured at the moment you load it. /status.json returns the same thing for anything that polls.