Getting Started

The Sitechecker Public REST API gives you programmatic access to your projects and to the crawl data behind them — Site Audit findings, page-level details, the saved segments you group pages by, and the change history Site Monitoring records over time. Where a project has Google Search Console or Google Analytics 4 connected, Site Audit responses can carry those metrics alongside the crawl data.

Every endpoint is a GET over HTTPS, returns JSON, and is authenticated with a Bearer API key.

The API is in beta

Access is currently open to Premium accounts, and the limits are still being tuned against real traffic — see Access & Limits. GSC Insights, GA4 Insights, Rank Tracker, AI Visibility, and SEO Tests are planned for later stages of the rollout.

Quickstart

1. Create an API key in Account Settings → API keys and copy it.

   API KeysStep-by-step, with screenshots of the creation and revoke flow.

2. Put the key in your environment rather than in the command itself, so it stays out of your shell history and out of version control.

   export SITECHECKER_API_KEY="sk_live_..."

3. Call the projects endpoint. It needs no parameters, which makes it the quickest way to confirm the key works.

   curl https://sitechecker.pro/api/v1/projects \
     -H "Authorization: Bearer $SITECHECKER_API_KEY"

4. Take the project_id from the response. Every other endpoint is scoped to a project and takes it as a parameter.

Base URL

All endpoints live under a single versioned prefix:

https://sitechecker.pro/api/v1

This is the host this copy of the docs is built against, and the API reference alongside it defaults to the same one — so the examples below can be run as they are.

Authentication

Send your API key as a Bearer token in the Authorization header of every request. There is no other auth scheme — no session cookie, no key in the query string.

cURL

curl https://sitechecker.pro/api/v1/projects \
  -H "Authorization: Bearer $SITECHECKER_API_KEY"

JavaScript

const response = await fetch('https://sitechecker.pro/api/v1/projects', {
  headers: { Authorization: `Bearer ${process.env.SITECHECKER_API_KEY}` },
});

const { data, meta } = await response.json();

Python

import os
import requests

response = requests.get(
    'https://sitechecker.pro/api/v1/projects',
    headers={'Authorization': f"Bearer {os.environ['SITECHECKER_API_KEY']}"},
)

payload = response.json()

PHP

$ch = curl_init('https://sitechecker.pro/api/v1/projects');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => ['Authorization: Bearer ' . getenv('SITECHECKER_API_KEY')],
]);

$payload = json_decode(curl_exec($ch), true);

Keep the key server-side

An API key carries the access of the account that created it. Never ship it in front-end code or in a mobile app, where anyone can read it — proxy the call through your own backend instead.

Your first response

List endpoints answer with the same envelope: the rows under data, the counts under meta.

GET /api/v1/projects

{
  "data": [
    {
      "project_id": 12345,
      "project_name": "example.com",
      "url": "https://example.com",
      "domain_scope": {
        "protocols": ["https"],
        "scope_type": "subdomains",
        "path": "/"
      },
      "site_audit_enabled": true,
      "last_crawl_date": "2026-05-12T08:30:00Z",
      "last_crawl_status": "finished",
      "website_score": 78,
      "crawled_pages": 298
    }
  ],
  "meta": {
    "total": 137,
    "limit": 50,
    "offset": 0
  }
}

project_id is the value the rest of the API is keyed on — hold on to it.

Request scope

project_id selects the project; three further parameters narrow a request inside it. Which of them an endpoint accepts is on its reference page.

Parameter	Selects
project_id	The project. Every endpoint below /projects takes it.
segment_id	One saved segment, where the endpoint supports segments.
crawl_id	One crawl, on the Site Monitoring endpoints.
url	One page — or, on list endpoints, the pages matching it.

Site Monitoring data is organised by crawl: a summary endpoint returns one point per crawl over the date range you ask for, each carrying the crawl_id that the matching list and details endpoints then take. Treat that value as opaque — copy it from the summary response rather than deriving or guessing it.

Pagination

List endpoints page with limit and offset, and report the full size of the result set in meta.total, so you can tell how many pages are left before fetching them.

Parameter	Default	Range	Purpose
limit	50	1–100	How many rows to return in one response.
offset	0	from 0	How many rows to skip.

# Rows 101-150 of the result set.
curl "https://sitechecker.pro/api/v1/projects?limit=50&offset=100" \
  -H "Authorization: Bearer $SITECHECKER_API_KEY"

Errors

Failures share one envelope. Branch on error.code — it is the stable machine-readable value; error.message is written for humans and may be reworded.

{
  "error": {
    "code": "unauthorized",
    "message": "Invalid or missing API key."
  }
}

Status	error.code	What went wrong
401	unauthorized	The key is missing, malformed, or revoked.
403	api_access_denied	The account has no active API entitlement.
403	forbidden	The requested project belongs to another account.
404	project_not_found, segment_not_found, crawl_not_found	The resource does not exist, or the key cannot reach it.
409	crawl_in_progress	The crawl is still running, so there is no audit data to return yet.
422	validation_error, invalid_date_range	A parameter is missing or invalid — error.message names it.
429	rate_limit_exceeded	Too many requests. Wait for the interval in the Retry-After header.
500	internal_error	Something failed on our side. Safe to retry.
502	upstream_error	A service the endpoint depends on is temporarily unavailable.

Retry on 429, not on 422

429, 500, and 502 are worth retrying — back off, and honour Retry-After when it is present. 409 clears on its own once the crawl finishes, so retry it on a timescale of minutes. 401, 403, 404, and 422 will keep failing until the key or the request changes, so retrying them only burns rate limit.

Next steps

Access & LimitsBeta availability, rate limits, pagination caps, and the date ranges endpoints accept.

API referenceEvery endpoint, generated from the OpenAPI spec, with a playground for trying calls.

ProjectsList the projects a key can reach and the project_id every other endpoint needs.

Site AuditCrawl-based issues, the crawled page list, and per-URL page details.

Site MonitoringWhat changed between crawls — content updates, audit-issue changes, and page history.