Add self-service API key revocation/rotation and a documented way to report leaked keys

Start by reading the Developer Manual, the signup flow, and the documented API_KEY_DISABLED error to understand existing key issuance and revocation behavior. The issue proposes documentation, owner self-service rotation, public leaked-key reporting, and longer-term key scanning, but does not name implementation files or tests. Done means agreeing on scope and security requirements, then providing the chosen reporting instructions and/or revocation flow with tests for its behavior.

Adding an issue to this repository originally created in https://github.com/usgpo/api/issues/206 by @junxit:

Summary

There's no documented way for a key owner to revoke or rotate an api.data.gov API key, or to report one that has been exposed. I'm requesting (1) a documented reporting process now and (2) self-service revocation/rotation.

What happened

I got a key through the GovInfo signup page (https://www.govinfo.gov/api-signup) in August of2026. The key was later exposed publicly. I couldn't find any way to revoke it:

• The Developer Manual says keys should be kept private, but says nothing about what to do if one is exposed.
• There's no account page, and the signup email has no management link.
• The GovInfo API README points to usgpo/api for issues, but issue creation there is restricted, and the key is issued by api.data.gov anyway.
• The only route I found is the general contact form ("API key support"). Nothing says it handles security reports, and there's no stated response time.

One key works across every agency API behind api.data.gov. A leaked key can use up the owner's rate limit across all of them, and any abuse is attributed to the owner.

Admins can already disable keys (API_KEY_DISABLED is a documented error). The capability exists; key owners just can't trigger it. Programmatic key management, including revocation, was also on the 2014 roadmap in this repo's wiki.

Proposed changes

1. Docs (quick win): Add an "If your API key is exposed" section to the Developer Manual. Name the exact reporting channel and the expected turnaround.
2. Self-service revoke/rotate: The owner enters the email the key is registered to. api.data.gov emails a one-time link to revoke the key and optionally issue a replacement. This mirrors the signup flow, so no user accounts are needed.
3. Leaked-key reporting: A form or endpoint where anyone who finds a key can submit it to be disabled. It should return the same response whether or not the key is valid, and be rate-limited.
4. Longer term: Give new keys a recognizable prefix, and join GitHub's secret scanning partner program. Keys pushed to public repos would then be caught and disabled automatically. Today's bare 40-character keys are hard for scanners to match reliably.

I haven't included my key in this issue. I've reported it separately through the contact form.