Access & Limits
The Public REST API is in beta. This page covers who can call it, and the limits that apply to a request once they can.
Who can access the API
Section titled “Who can access the API”The beta is open to Premium accounts. An API key inherits the access of the account that created it, so it reaches exactly the projects that account owns — and nothing beyond them.
| Status | error.code |
What it means |
|---|---|---|
403 |
MISSING_PUBLIC_API_ACCESS |
The account has no active API entitlement. |
403 |
ACCESS_DENIED |
The project_id is valid, but belongs to another account. |
Access rules may change after the beta: which plans include the API, and how much usage each of them covers, are among the things this period is meant to settle.
Rate limits
Section titled “Rate limits”Rate limits protect the API for everyone using it, and may be applied per key, per account, per endpoint, or by a combination of those.
Over the limit, a request answers 429 with error.code RATE_LIMIT_EXCEEDED and a
Retry-After header:
{ "error": { "code": "RATE_LIMIT_EXCEEDED", "message": "Rate limit exceeded. Try again later." }}Wait out the interval in Retry-After before retrying, and back off exponentially if
the limit is hit repeatedly. 401, 403, 404, and 422 will keep failing until
the key or the request changes, so retrying those only spends rate limit.
Pagination limits
Section titled “Pagination limits”List endpoints return at most 100 rows per request, and report the full size of the
result set in meta.total so you can tell how many requests are left.
| Parameter | Default | Range |
|---|---|---|
limit |
50 |
1–100 |
offset |
0 |
from 0 |
# Rows 51-100 of the issue list.curl "https://sitechecker.pro/api/v1/audit_issues?project_id=12345&limit=50&offset=50" \ -H "Authorization: Bearer $SITECHECKER_API_KEY"Page Details is the
exception. It attaches one optional block per request through include, and each
block pages on its own through its own <block>_limit and <block>_offset pair,
capped at 50 rows rather than 100.
| Block | Parameters |
|---|---|
internal_links |
internal_links_limit, internal_links_offset |
external_links |
external_links_limit, external_links_offset |
internal_backlinks |
internal_backlinks_limit, internal_backlinks_offset |
internal_backlink_anchors |
internal_backlink_anchors_limit, internal_backlink_anchors_offset |
images |
images_limit, images_offset |
css_files |
css_files_limit, css_files_offset |
javascript_files |
javascript_files_limit, javascript_files_offset |
# The second page of the internal-links block, 50 rows at a time.curl "https://sitechecker.pro/api/v1/page_details?project_id=12345&url=https%3A%2F%2Fexample.com%2Fpricing&include=internal_links&internal_links_limit=50&internal_links_offset=50" \ -H "Authorization: Bearer $SITECHECKER_API_KEY"Date ranges
Section titled “Date ranges”The endpoints that report over time — Site Monitoring summaries, GSC Insights, GA4
Insights, Rank Tracker and AI Visibility — take a date range through date_from and
date_to. Both are required, both are YYYY-MM-DD, and the range they describe is
inclusive of its end dates and interpreted in UTC.
# An inclusive, UTC date range.curl "https://sitechecker.pro/api/v1/content_updates_summary?project_id=12345&date_from=2026-02-01&date_to=2026-02-28" \ -H "Authorization: Bearer $SITECHECKER_API_KEY"A range can span up to 36 months. How much of it comes back is another matter: the available history depends on the account plan, the endpoint, and how long the project has been crawled. Ask for more than exists and the response covers the available period rather than failing — so read the dates in the response instead of assuming the range you asked for.
A range the endpoint cannot accept at all — reversed dates, or a span beyond the
supported maximum — answers 422 with error.code INVALID_DATE_RANGE.
Endpoints that set their own period
Section titled “Endpoints that set their own period”Three reports follow the product rather than the general rule, and reject
date_from / date_to or ignore them in favour of their own window:
| Report | Period |
|---|---|
| GSC Last Found Pages | A fixed lookback of 7, 30, 60 or 90 days. |
| Rank Tracker keyword position trends | At most 21 daily points per keyword — a longer range returns the latest 21 available days, anchored to its end. |
| Rank Tracker SERP Opportunities | A monthly snapshot, with the snapshot dates in the response meta. |
Comparison periods
Section titled “Comparison periods”Where an endpoint reports a change against a previous period, it takes one of two shapes, and the reference page for each says which:
- Manual. The GSC Performance Overview and Search Conversion endpoints accept
compare_fromandcompare_to, passed together. - Automatic. GSC Page Segments and New & Lost, GA4 Insights and AI Traffic resolve the previous period themselves — the same length, immediately before the selected range — and return the dates they used in the response meta.
Cannibalization, Rankings, Keyword Gap, Last Found Pages, Google AI Overview and AI Chats have no comparison period at all in this version.
Response caps
Section titled “Response caps”Some endpoints cap what one request can return, on top of the pagination limits above:
- Entity history endpoints — GSC page and keyword history, GSC Page Segments history — take a small capped list of entities per request.
- Rank Tracker keyword position trends returns at most 21 daily points per keyword.
- SERP snapshot takes one keyword per request and returns the top 100 results.
- History endpoints in AI Visibility chart one metric per request.
Usage and billing during the beta
Section titled “Usage and billing during the beta”API access is included in eligible plans for the duration of the beta, at no extra cost. We are using the period to learn how the API is actually used before setting final numbers.
Afterwards, usage allowances may depend on the plan, the endpoint, the number of requests, and the volume of data returned — with ordinary usage included in eligible plans, and high-volume or extended usage possibly a paid add-on. Final quotas and billing rules will be documented here before they take effect.