IndexChex API v1

Scope

Version 1 is the original programmatic interface to IndexChex. It exposes the two core jobs of the product, checking whether URLs are in Google's index and submitting URLs for Googlebot crawling, plus a balance lookup so a client can confirm it has enough credits before queuing work. It does not expose the backlink monitor or drip-feed scheduling, which remain dashboard features.

Integrations that already target SpeedyIndex's request format should use the SpeedyIndex-compatible v2 instead. Both versions draw from the same credit balance and return the same underlying jobs, so a team can mix them.

Base URL and authentication

All routes sit under https://indexchex.com/api/v1. The application mounts its API routes under the /api prefix and this version under /v1.

Authentication uses a per-user API key. The client sends the key as the full value of the Authorization header:

Authorization: YOUR_API_KEY
Content-Type: application/json
Accept: application/json

The server trims the header value, hashes it and looks up the matching key. A missing or unknown key is rejected before any job is created. Keys belong to a single user, and every job lookup is scoped to that user: requesting another account's job ID returns 404 with {"message": "Resource not found."}.

Endpoints

Creating an index-check job

The body is a JSON object with a urls array. Each entry is trimmed of whitespace and must be a non-empty string. Arrays longer than 10,000 entries fail validation with the message "Too many URLs. Maximum allowed: 10000". Each URL costs 1 credit, matching the index checker in the web app.

POST /api/v1/index-check/jobs
{ "name": "October guest posts", "urls": ["https://example.com/post-1", "https://example.org/review"] }

The response returns job_id, status (initially pending), total_urls, checked_urls, indexed_count, not_indexed_count, name and queued_at as an ISO 8601 timestamp.

Reading check status and the report

GET /index-check/jobs/{run} adds failed_count, progress_percent and completed_at. Poll it until the job finishes. The report endpoint then lists every URL in one of three arrays: indexed_links, unindexed_links and failed_links. If the job is still running, the report endpoint answers with "Report not ready. Check status and retry later." rather than a partial list. A URL in failed_links is one the checker could not resolve; it is not evidence of non-indexation.

Creating a submission job

The submission body takes the same urls and name fields plus two options:

• instantIndex: true selects instant mode (60 credits per URL, at most 1,000 URLs). Omitted or false selects standard mode (1 credit per URL, at most 10,000 URLs). The snake-case alias instant_index and the strings "true", "false", "1" and "0" are also accepted.
• checker: an integer from 0 to 5. A value of 1 to 5 schedules an automatic index check that many days after submission; 0 or omission schedules none. See scheduled index checks for how those credits are reserved.

The response carries job_id, status, total_urls, submitted_urls, successful_count, failed_count, name, queued_at, and three scheduled-check fields: scheduled_check_days, scheduled_check_status and scheduled_check_at.

Reading submission status

GET /index-submit/jobs/{run} returns the counts above plus progress_percent, success_percent, completed_at and scheduled_check_run_id. Once a scheduled re-check has started, that ID can be passed to the check endpoints to read which submitted URLs were found in Google. "Successful" here means the URL was delivered for crawling; indexation is only known after a check.

Balance

GET /balance returns {"balance": 12345}, the account's current credits, never below zero.

Errors and limits

The rate limit is 120 requests per minute, counted per authenticated user. A client polling many jobs should back off between status calls instead of looping on them; status polling every 30 to 60 seconds is ample for jobs that take minutes to hours.

Behaviour worth knowing

Submission through the API is the same process the dashboard uses, so the published performance figures apply equally. Those figures, and how they are produced, are on the measurement methodology page; the full limits table is in the IndexChex specifications. As with every submission route, IndexChex guarantees that Googlebot crawls the URLs, not that Google indexes them, and it does not use Google's Indexing API, which Google limits to job-posting and livestream pages.

A typical automated loop looks like this:

1. GET /balance to confirm credits.
2. POST /index-submit/jobs with checker set to 3, so a re-check runs three days later.
3. Poll GET /index-submit/jobs/{run} until scheduled_check_run_id appears and that check completes.
4. GET /index-check/jobs/{id}/report and resubmit the unindexed_links.

Changes to the API are dated in the IndexChex changelog.