API keys and security for indexing tools

Why indexing keys need care

Most indexing APIs authenticate with one static key per account, as described in the guide to indexer APIs. That key is a bearer credential: whoever presents it is treated as the account. With it, a third party can start jobs that consume the credit balance, read the URL lists in past jobs, and see which client sites they belong to. For an agency, the job history alone can reveal its link sources. A leaked key therefore costs money and leaks business data.

Storage

Keep the key out of source code. The usual options, in rising order of control:

• Environment variables. The application reads the key at startup, for example INDEXER_API_KEY. Local development uses a .env file listed in .gitignore.
• Platform secrets. CI systems, serverless platforms and hosting providers offer encrypted secret stores that inject values at runtime.
• A secret manager. Dedicated vaults add access policies, audit logs and versioning, which helps when several services share infrastructure.

The OWASP Secrets Management Cheat Sheet recommends centralising secrets, limiting who can read them and logging access. Those principles apply to a small indexing script as much as to a large platform.

Never in client-side code

A key placed in browser JavaScript, a browser extension or a mobile app is public. Anyone can open developer tools and copy it. If a web page or a no-code front end needs to submit URLs, send the request to a small server-side endpoint that holds the key, checks that the caller is allowed, and forwards the call. The same applies to spreadsheet scripts shared with clients: the script's code and properties may be readable by anyone with edit access.

Keys also do not belong in URLs. Query strings are written to web server logs, intermediary logs and browser history. Send the key in the Authorization header as the API documents.

Least privilege

Give each integration its own key where the vendor allows it, so one leak does not force every system to change at once and so usage can be traced. Where a tool offers only one key per account, consider separate accounts for unrelated clients or environments. Keep the number of people who can view keys small, and remove access when roles change.

Spending controls help too. Keep the credit balance close to expected usage instead of preloading a year's worth, and watch the balance endpoint for unexpected drops.

Rotation

Rotation means creating a new key, deploying it, confirming traffic uses it, then revoking the old one. Plan for it before it is urgent:

1. Read the key from one configuration point, not several files.
2. Document where each key is deployed.
3. Rotate on a schedule and whenever staff with access leave.
4. After a suspected leak, revoke first and investigate second.

Secret-scanning services such as GitHub secret scanning can flag keys pushed to repositories, but they do not recognise every vendor's format, so they are a backstop rather than a control.

Handling responses safely

Job reports contain client URLs. Store them with the same care as other client data, avoid logging full responses in shared logs, and strip keys from any error output before it reaches monitoring tools.

IndexChex keys

IndexChex, which publishes this handbook, issues API keys from the account's API settings. Each key belongs to one user, and jobs created with it are visible only to that account. The key is sent as the full Authorization header value with no prefix, and requests are limited to 120 per minute per user. The IndexChex software page summarises the rest of the API, and the software overview places it among other tools.