Migrating a SpeedyIndex API integration

Scope of this guide

This is a code-level checklist for moving a working SpeedyIndex integration onto IndexChex's v2 interface, which mirrors SpeedyIndex's API schema. Whether to switch at all, on price, refunds and coverage, is a different question handled on the alternatives site's IndexChex vs SpeedyIndex comparison. IndexChex publishes this handbook; its endpoint list is on the API reference.

Step 1: make the base URL and key configurable

Most integrations hard-code the host. Pull it and the key into configuration first, so the switch is a deploy setting rather than a code change.

# before
BASE = "https://api.speedyindex.com"
KEY = os.environ["SPEEDYINDEX_KEY"]

# after
BASE = os.environ.get("INDEXER_BASE", "https://indexchex.com/api")
KEY = os.environ["INDEXER_KEY"]
HEADERS = {"Authorization": KEY, "Accept": "application/json"}

The key goes in Authorization as the full header value, with no prefix. IndexChex keys are created in the account's API settings and are tied to one user.

Step 2: map the endpoints

Responses keep the SpeedyIndex envelope: code 0 on success, task IDs as strings, and status objects with id, size, processed_count, indexed_count, type, title, is_completed and created_at.

Step 3: test with a small task

curl -X POST https://indexchex.com/api/v2/task/google/checker/create \
  -H "Authorization: $INDEXER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title": "migration smoke test", "urls": ["https://example.org/"]}'

Expected reply:

{"code": 0, "task_id": "90377", "type": "google/checker"}

Then call /v2/account and confirm the balance dropped by one. Both balance.indexer and balance.checker report the same number, because IndexChex uses one credit pool for both task types.

Step 4: handle the differences

Google only

The {engine} path segment must be google. Any other value returns HTTP 422 with {"code": 3, "message": "Unsupported search engine."}. Integrations that also send Yandex tasks need a branch that keeps those on the old provider.

Two extra task options

Create calls on the indexer accept two fields SpeedyIndex code will not be sending:

• instantIndex: true runs the task in instant mode, at 60 credits per URL and up to 1,000 URLs.
• checker from 1 to 5 schedules an automatic index check that many days after submission, at 1 credit per URL.

Leaving both out gives a standard task: 1 credit per URL, up to 10,000 URLs.

Indexer reports need a scheduled check

On IndexChex, POST /v2/task/google/indexer/report returns the result of the task's scheduled index check. If the task was created without checker, the call returns HTTP 422 with {"code": 3, "message": "Report not available for this task."}. Until the check has run it returns "Report not ready. Check status and retry later." For indexer tasks, is_completed in status responses also stays false until the scheduled check finishes. Code that reads indexer reports should either set checker on create or run a checker task over the same URLs.

Billing model

SpeedyIndex prices by indexed link and refunds tokens for unindexed links after its report. IndexChex charges credits per submitted URL and does not refund URLs that were crawled but not indexed. Any reconciliation code that expects refunds should be removed.

Rate limit

IndexChex allows 120 requests per minute per user on v2, and over-limit calls get HTTP 429 with {"code": 2, "message": "Too many requests. Please retry shortly."}. See rate limits and batching if your current client polls aggressively.

Step 5: update error handling

Most SpeedyIndex clients already branch on code. The v2 values map as follows; the full list with HTTP statuses is on handling API errors.

An invalid or missing key returns HTTP 401 with {"message": "Invalid API credentials."}, which has no code field; check the HTTP status first.

Step 6: switch and watch

Change INDEXER_BASE and INDEXER_KEY in production, then watch the first day of tasks: creation responses, status polling and reports. Keep the old key until the balance there is used or no longer needed.

v1 or v2 after migrating

v2 exists so existing code keeps working. New code can use v1, whose job endpoints return richer counters such as failed_count and progress_percent; see submitting URLs and polling job status. The backlink indexer API overview compares the two styles, what backlink indexer software is covers the wider category, and the IndexChex entry lists the account-level facts.