Authentication

There is no rotate button, because you do not need one. Keys are independent: create the new one, deploy it, then revoke the old one. At no point is there a window where neither works.

• Create a second key and name it for the rollout — the account page allows 10 active keys.
• Ship it to your environment and confirm with a call to /v1/ping.
• Watch the old key’s last used timestamp on the account page. When it stops moving, nothing is still using it.
• Revoke the old key.

Immediately and permanently. The next request presenting that key gets 401 invalid_key — no grace period, no cached acceptance, no way to un-revoke it. Revocation is the correct first move whenever you are unsure; a new key is twenty seconds away.

HTTP/1.1 401 Unauthorized

{
  "error": {
    "code": "unauthorized",
    "message": "Authentication required"
  }
}

Note that a revoked key, an expired key, a mistyped key, a key on a suspended account and a key that never existed all return the same invalid_key. Distinguishing them in the response would only help someone guessing at keys. Your side of it is simple: whatever the cause, the fix is to check the credential you deployed.

A key may be given an expiry when you create it. After that moment it behaves exactly like a revoked key. Keys with no expiry never expire. An expiry is worth setting for anything short-lived — a contractor, a one-off migration, a demo — because it fails safe if everyone forgets.

Call the API from your own server and let the browser call your server. The key never leaves your infrastructure, and you get three things you would otherwise have to build: a cache, a place to enforce your own limits, and one point at which to rotate.

Browser  ──▶  your backend  ──▶  https://api.worldgovdata.com/v1
                    ▲
                    └── WGD_API_KEY lives here, and only here

Add a cache to that proxy. Authenticated responses come back private, no-store — they carry your balance, so no shared cache may hold them — but a cache inside your own service is yours to control, and it will usually cut your credit spend by more than the proxy costs to run.

• Environment variables, not source. Read WGD_API_KEY at runtime. Add .env to .gitignore before you write the key into it, not after.
• Never in a URL. Query strings land in access logs, proxy logs, browser history and Referer headers. We do not read keys from them, so this cannot even work by accident.
• Never in a notebook you publish. Jupyter saves cell output. Set the variable in the shell that launched the kernel.
• Never in a CI log. Register it as a masked secret so an accidental env dump does not print it.
• Never in a screenshot or a support ticket. Send the key id — the twelve-character middle segment. It is not secret and it is all we need.
• One key per deployment. Shared keys make revocation an outage; separate keys make it a shrug.

Revoke it first and investigate second. Revocation takes effect on the next request, so there is nothing to gain by waiting until you have worked out how far it spread. Then create a replacement, deploy it, and check your usage for requests you cannot account for. If the numbers look wrong, tell us — the key id is enough for us to trace it.