Home πŸ”Œ Integrations & API πŸ” Site Audit v2 Standalone API Contracts

πŸ” Site Audit v2 Standalone API Contracts

Last updated on Oct 29, 2026

πŸ“Œ What a standalone audit is

Site Audit v2 can run against a domain as a standalone audit. You identify that run by its audit_id, such as 101009. Reading status, page count, effective settings, or issues for that ID does not create or require a permanent project.

Use only the routes published for your workspace on sa.searchatlas.com. Route names can differ by API version, so do not guess a path from an example ID. If your API reference is not visible in the platform, confirm the current contract in live chat before you automate calls.

πŸ“‘ What you can read for one audit

For a specific audit_id, a read request should return three kinds of information:

  • Status shows whether the audit is queued, running, complete, or failed.
  • Page count shows how many URLs were discovered or crawled for that run.
  • Issue payload lists URL-level findings for the completed or partially completed run.

Use a GET read for an existing audit_id. A GET does not start a new crawl and does not change crawl settings. Call the status read while the audit is in progress, then call the issues read when status shows the run is ready. If issues are paginated, request each page until the payload indicates there are no further results.

βš™οΈ Settings and crawl budget

Effective settings belong to the audit or domain configuration returned with that audit. Read them from the settings response rather than assuming a default. A value such as crawl_budget: 25 is enforced only when that audit’s effective settings say so. It is not a universal rule for every new domain. Compare the requested budget with the effective budget in the response before you rely on a page count.

On a new domain, the platform applies the settings saved for that standalone audit. If no custom budget was saved, use the effective value returned by the API. Do not treat an example budget from another audit as the limit for yours.

πŸ”„ Fresh results without changing settings

To refresh an existing domain, request a new run with the same saved settings. Do not send a settings update in that request. A read-only GET never refreshes crawl data. The rerun action should keep the current budget, scope, and other options, then issue a new audit_id or run identifier for the fresh results.

  1. GET the current status and effective settings for the existing audit_id.
  2. Confirm the budget and scope you want to keep.
  3. Request a fresh run without including changed settings.
  4. Store the new audit_id and poll its status.
  5. GET the page count and URL-level issues only after the new run is ready.

Keep the previous audit_id if you still need the older issue payload. A fresh run does not erase a completed audit unless you explicitly delete it.

βœ… Practical checks

  • Call GET only when you are reading status, page count, effective settings, or issues.
  • Pass the exact audit_id. An unknown ID should return a not-found response, not a new project.
  • Treat empty issues on a still-running audit as incomplete data, not as a clean site.
  • Use the effective settings in the response as the source of truth for crawl budget.
  • Request a rerun, not a settings write, when you want fresh results with the same configuration.

If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be instantly connected with a member of our team.