AccessWiser developer docs
Run automated accessibility scans against the sites you have added to your account, from your own tooling. Post a URL, get a scan id back, then poll for the result or receive a signed webhook when it finishes. In an AI coding tool, the AccessWiser MCP Server starts the scan and reads the findings back in your editor.
https://app.accesswiser.com/api/v1
What automated scanning can and cannot tell you
Read this before you wire the API into anything that reports a status. Automated testing detects only a portion of possible accessibility barriers — industry studies put it at roughly a third to a half. It cannot judge whether alt text is meaningful, whether reading order makes sense, or whether a form is genuinely usable with a screen reader. Those need manual testing and testing with assistive technology.
A scan therefore cannot establish compliance and this API never claims to. There is no compliance field, no compliance status and no compliance score in any response. healthScoreis an internal progress indicator, nothing more. A green pipeline means your automated checks passed — it does not mean your site conforms to WCAG 2.2 AA or complies with the ADA, Section 508 or the EAA, and it is not legal advice.
Every scan-bearing response carries this string in its disclaimer field. If you surface our numbers in a dashboard, a PR comment or a report, surface this alongside them:
Automated testing detects only a portion of possible accessibility barriers and cannot replace manual testing with assistive technology. healthScore is an internal progress indicator, not a legal determination, certification or guarantee, and running this scan does not by itself make a site conform to the ADA, WCAG 2.2 AA, Section 508 or the EAA.
For the fuller picture, see what AccessWiser does and doesn't do.
Documentation
- QuickstartAdd your site, create a secret scan key and make your first scan request.
- Scan API referenceHow to authenticate, the endpoints, their request and response fields, and the headers they return.
- AccessWiser MCP ServerScan a deployed page on a site added to your account from your AI coding tool, and read the findings there.
- WebhooksThe signed call we make when a scan finishes, how to verify it, and how retries work.
- ErrorsThe error shape and every error code, with its HTTP status and when it is returned.
- Limits and allowancesRate limits, concurrency, scan classes, and the monthly allowances and credits that pay for scans.
What the Scan API is for
The Scan API runs the same accessibility scanner the dashboard runs, triggered from your own code instead of a button. It is built for the places a person is not sitting there clicking: a CI job on every deploy, a nightly check of your key templates, or your own internal tooling. The Scan API and the AccessWiser MCP Server are included on the Basic, Pro and Business plans; on Free and Starter you scan from the dashboard.
It is a server-to-server API with a secret key. A scan spends your account's allowance or credits — real money — so the key must never appear in page source, client-side JavaScript or a mobile app. Browsers are deliberately locked out: no response grants a cross-origin reader, and a preflight is answered with 405.
The shape is asynchronous, because rendering and analysing a page takes longer than a request should wait:
POST /scansanswers202 Acceptedwith a scan id, and the work runs in the background.GET /scans/{id}is the authoritative source of the result. Poll it untilterminalistrue.- A signed webhook is available so you don't have to poll. It is a convenience, not the system of record — a receiver that misses every delivery loses nothing but latency.
One rule sits above all of it: a scan runs only against a site you have added to your account — the site your plan covers and where your widget is installed. A URL on any other host is refused with 403 site_not_addedbefore a request is made to it, and the refusal is recorded against your account. Adding the site in the dashboard is the whole check: there is no separate step in which you prove ownership to us, and we do not fetch the page to confirm the widget is on it. So a site being on your account is not proof that you are authorised to test it — that half is still yours to hold. Every scan is written to your account's audit log with its target URL and the key that made it, and scanning sites you are not authorised to test is a breach of the Acceptable Use Policy that can get an account suspended.
Acceptable use
Use of this API is bound by the Acceptable Use Policy and the Terms and Conditions. The short version, because it shapes how the API behaves:
- Scan only sites you have added to your account. Any other host is refused with
403 site_not_addedand the attempt is recorded. Having a site on your account is not proof that you are authorised to test it, so holding that authorisation is still your responsibility; every scan is logged against your account with its target URL, and unauthorised scanning can get an account suspended. - Do not use scan output to assemble accessibility demand letters, shortlist defendants, or otherwise prospect for litigation against sites you do not own.
- Do not detect our scanner in order to serve it a page different from the one your real visitors get. Scan history is dated and retained, and that pattern reads as concealment.
- Do not work around rate limits or quotas. Talk to us instead.
Questions, or something the docs don't cover? contact@accesswiser.com.
The Scan API helps you find and fix WCAG 2.2 AA issues and keep a dated record of the work. Automated testing detects only a portion of possible accessibility barriers and cannot replace manual testing with assistive technology, so a scan result — including healthScore — is not a determination of conformance or compliance with the ADA, WCAG 2.2 AA, Section 508, the EAA or any other law, and nothing on this page is legal advice.