Accessibility checker API: WCAG checks from your own tools

The Pandus API gives you the same automated accessibility checks as the cabinet, from your own tools: a deployment script, an agency dashboard, a ticket system. It checks WCAG 2.2 level A and AA with the axe-core engine in a real browser, across the pages of a site, and returns results with plain-language explanations in seven report languages.

Everything on this page comes from our published OpenAPI specification. Results are an automated check, not a full audit, and not legal advice.

Every endpoint with its parameters, response examples, errors and code samples in curl, JavaScript, PHP and Python is described in the API documentation.

What the API does

The base URL is https://pandus.online/api/v1. The report and the PDF take an optional lang parameter: en, uk, de, pl, cs, ro or ru. Without it, the site's report language is used.

The JSON report contains the problem groups with their rule cards, examples, affected pages, totals by severity, a before/after comparison with the previous check and the trend. A check has the status queued, running, completed or failed, and the report endpoints answer 409 until it is completed.

Authentication and limits

Create a token in the cabinet under API and webhooks and send it as a bearer token:

curl -H "Authorization: Bearer $PANDUS_TOKEN" \
     https://pandus.online/api/v1/sites

• A token belongs to the team, not to a person, so it keeps working when someone leaves.
• Abilities: read covers every GET request, write covers adding and deleting sites and starting checks. A read-only token is enough for a dashboard.
• Rate limit: 60 requests a minute per token. Above that you get HTTP 429 with a Retry-After header.
• Plan limits apply as in the cabinet: number of sites, pages per check, history, and how often a check may be started by hand. A request over a limit returns HTTP 422 with a message.
• The API is included in the Pro and Agency plans — see pricing.

Add a site and start a check

curl -X POST https://pandus.online/api/v1/sites \
     -H "Authorization: Bearer $PANDUS_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"url": "shop.example", "report_locale": "de", "platform": "shopify", "tags": ["client-a"]}'

url and report_locale are required. platform (shopify, woocommerce, prestashop, shoptet or other) lets the report show fixing instructions for that platform; tags help agencies sort sites by client. The response is 201 with the new site, and its first check is queued.

To check again later, for example after a release:

curl -X POST https://pandus.online/api/v1/sites/$SITE_ID/scans \
     -H "Authorization: Bearer $PANDUS_TOKEN"

The answer is 202 with the queued check. Then either poll GET /scans/{scan} or, better, wait for a webhook.

Webhooks

Two events are sent: scan.completed and issues.new. Each is a JSON POST of the form {id, type, created_at, data: {scan, site, new_issues}} with these headers:

• Pandus-Event — the event type;
• Pandus-Delivery — the delivery id;
• Pandus-Signature: t=<unix>,v1=<hex> — v1 is an HMAC-SHA256 of "<t>.<raw body>" with your endpoint's secret.

Answer with a 2xx status within 10 seconds. Failed deliveries are retried for about a day; in the cabinet you can send a test event and retry a delivery by hand. A minimal check in Node.js:

import crypto from 'node:crypto';

function verify(rawBody, header, secret) {
    const parts = Object.fromEntries(
        header.split(',').map((p) => p.split('=')),
    );
    const expected = crypto
        .createHmac('sha256', secret)
        .update(`${parts.t}.${rawBody}`)
        .digest('hex');
    const given = Buffer.from(parts.v1 ?? '');
    return (
        given.length === expected.length &&
        crypto.timingSafeEqual(Buffer.from(expected), given)
    );
}

Use the raw request body, not a re-serialised JSON object, and reject old timestamps to stop replays.

Using the API in CI

The API checks the public site, so it fits after a deployment to production or to a publicly reachable preview:

1. Your pipeline deploys.
2. A job calls POST /sites/{site}/scans.
3. Your endpoint receives scan.completed or issues.new, reads GET /scans/{scan}/report and opens a ticket or posts to a chat.

Do not make a merge wait for a full-site check; a whole site can take a while. For fast feedback on every pull request, run axe-core inside your own tests — see accessibility testing with Playwright — and let Pandus watch the production site every week and after releases.

Localhost, staging and pages behind a login

Our scanner opens only public addresses. It blocks private and local networks, including localhost, before and after every redirect — a security measure, not a gap we plan to remove. For anything that is not public:

• The browser extension for Chrome, Edge and Firefox checks the page as your browser shows it: a local development server, a password-protected staging site, the cart, the checkout, the customer account. A check can be saved to the site in Pandus.
• Your own Playwright tests with @axe-core/playwright reach whatever your CI can reach.
• Before an account, try the free WCAG checker on any public page.

What the API does not do

It does not run a manual audit, it does not "fix" a site with a script, and it does not decide whether a law applies to you. It returns automated findings with the WCAG and EN 301 549 references from our rule library and a report that a shop owner or an agency's client can read. For a WordPress site there is also the WordPress plugin, which uses a separate, site-bound token.

Frequently asked questions

Does Pandus have an accessibility checker API?

Yes. The REST API v1 lets you list and add sites, start checks, read their status, get the report as JSON or PDF and download screenshots. Webhooks tell you when a check is finished and when new issues appear.

Which plans include the API?

The Pro plan and the Agency plans. On Free and with the express report the API is not included; tokens of a team that moves to such a plan stop working until the plan includes the API again.

Can the API check localhost or a staging server?

No. Our scanner only opens public addresses and blocks private and local networks for security. For localhost, staging and pages behind a login use the browser extension, or run axe-core in your own Playwright tests.

How are webhooks secured?

Every delivery carries a Pandus-Signature header with a timestamp and an HMAC-SHA256 of the timestamp and the raw body, made with the secret of your endpoint. Compare it before you trust the payload.

Is an API result a WCAG audit?

No. The API returns the results of an automated check, not a full audit, and not legal advice. Many WCAG criteria still need a manual review.