For integrators

Everything the interface does, something else can do too.

The audit engine is the product; the console is one client of it. There is a REST API, an MCP server, SARIF output, signed webhooks and an embeddable scanner, and they all speak to the same surface with the same token.

Read the API reference See pricing

REST

An API that can start the work.

Post a URL, get a queued audit back immediately, and be told when it finishes rather than polling for it. The full measured payload is the same shape the report is built from, with no summarised second version that drifts from the first.

POST /api/v1/audits

curl -X POST https://app.siteassay.com/api/v1/audits \
  -H "Authorization: Bearer $SITEASSAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}'

# 202 Accepted
# { "id": "aud_01J...", "status": "queued" }

GET  /api/v1/audits              # list, filter, paginate
GET  /api/v1/audits/{id}         # the full measured payload
GET  /api/v1/audits/{id}/sarif   # SARIF 2.1.0
GET  /api/v1/reports/{id}        # narrative, share link, issues

MCP

Every comparable server is read-only. This one can run the audit.

Point Claude Code, Cursor or any other MCP client at it with the same token the REST API uses, and "find the worst five of these and audit them" becomes something that happens rather than something you get a list about.

run_audit: Starts a run against a URL or a prospect. The only tool here that writes anything, and it is annotated as such.
get_audit · list_audits: Read-only and idempotent, annotated so a client knows it can retry them without consequence.
get_report: The narrative, the prioritised issues and the shareable link, as text a model can quote.
Errors are sentences: The caller is a language model, so a failure says what went wrong in words rather than returning a status code for it to guess at.

The rest of the surface

SARIF 2.1.0

Security findings in the format GitHub code scanning already understands, so an audit becomes an annotation on a pull request instead of a PDF somebody has to read.

Signed webhooks

audit.completed and report.ready, HMAC-SHA256 signed, delivered at least once with an event id so a retry cannot be counted twice.

An embeddable scanner

A small script that puts a "check your website" box on your own site. It runs in a frame with no cookie of ours, against an allowlist of hosts you set.

Your own mailbox

Gmail and Outlook over OAuth, so approved outreach leaves your domain with your reputation behind it rather than a shared relay.

Limits, stated up front

What the API will not let you do.

Two of these are ceilings and two are deliberate omissions. The omissions are the more interesting ones.

Rate limits: Requests and audit starts are both capped per workspace. The numbers are in the reference and the response tells you where you are against them.
Metered like the interface: An audit started over the API costs an audit. There is no cheaper back door, because there is no cheaper way to run one.
No discovery endpoint: Searching for businesses is not exposed. A rate-limited scraping surface behind an API key is somebody else's outage and our ban.
No outreach endpoint: Sending is not scriptable, on purpose. The approval gate is the product decision this whole thing rests on, and an API that skipped it would be a way to route around it.

Get a token

API access is on the Agency plan and above. Tokens are issued from the settings screen, and the same one drives REST, MCP and webhooks.

See the plans