Indexing API

01 Access on request

Almost everything the service does runs through the dashboard: you paste a list, you run the order, you watch it finish. That covers most of the book, which is why the machine-readable door stays small and gets opened for the accounts that actually need it.

What follows is the whole surface as designed. It is short, and if something you need is missing from it, tell us. One endpoint people actually call beats ten that nobody does.

02 The shape of it

REST over HTTPS, JSON in and JSON out, one key in one header, and no SDK to install. Anything that can make an HTTP request can drive it.

• One key per account. Issued to you, rotated or revoked on request.
• One header. No signing, no OAuth dance, no token to refresh.
• The same objects you already see. An order created over the API is the order in your dashboard – same statuses, same per-URL detail, same history.
• No separate pricing. The same rate, from the same balance, whichever way the order was created.

None of this is a second product. These are the dashboard's own operations with a machine-readable door on them.

03 Your key

You send the key on every call. That is the whole authentication story:

The key identifies the account and spends that account's balance. It can be rotated or revoked at any time without touching your password or your open sessions. Treat it as a credential: it belongs on your server, not in a browser, a public repository, or a support ticket.

A request without a valid key is refused, is not told why, and looks exactly like a request to a path that does not exist. We apply that principle everywhere else too.

04 What you can call

Six operations, mapping one-to-one onto what the dashboard does:

• Create an order – post a list of URLs and get an order back as a draft. Nothing is charged and nothing is queued yet.
• Run it – a second call starts the campaign and takes the credit off your balance. It stands apart because a draft is the one safe place left to check the list.
• List your orders – newest first, paged, with the state of each.
• Read one order – its status, its counters, and per-URL detail as the campaign progresses.
• Check your balance – what is left, the same figure the dashboard shows.
• Delete a draft – while it is still a draft. Once it has run there is nothing to cancel; see the Refund Policy.

No webhooks in the first cut, no bulk export, no reporting endpoints – you poll an order and you get its state. If polling is not enough for what you are building, tell us that too.

05 Limits and rules

Nothing here is special to the API. It is the same service with a different door:

• The same minimum and maximum URLs per order as the dashboard, and as many orders as you like – see pricing.
• The same price per URL, taken from your balance at the moment the order runs.
• Rate limits per key, set high enough for real automation and low enough to survive a loop with a bug in it.
• The Acceptable Use Policy applies exactly as it does in the dashboard. A key does not widen what you may submit.

Errors come back as JSON with a status code that means what it says. A rejected URL is reported per URL rather than as a failed request – one malformed entry does not throw away the rest of the list.

06 What it is not

API pages usually imply more than they deliver, so here is the other side of it:

• Not a way to buy the method. It creates orders. What happens to a URL afterwards is the same closed pipeline described in the Terms of Use, and no endpoint will ever expose it.
• Not a guarantee of indexation. An accepted order means the work is queued – exactly what pressing the button in the dashboard means, no more.
• Not a reseller interface. Reselling or white-labelling needs a written agreement first: sales@index-pages.com.
• Not the endpoints our own fleet uses. Those exist, they are internal, they are not customer-facing, and they are not what this page describes.

07 Ask for a key

Write to support@index-pages.com from the address on your account, with two lines on what you would automate. That second part is what moves it up the list, because we build against real usage and not against a feature request form.

Demand sets the schedule here. There is no waiting list, no beta programme and no gate: if you need it, say so. Everything else is on the contact page.