API keys

An API key is the credential your tooling, harness, or IDE uses to call Merki. Merki treats keys as something that can leak, and acts on that assumption.

Issuing and authenticating

Keys are bearer tokens sent as Authorization: Bearer <key>. See Authentication. Store them in environment variables or a secrets manager, never in source.

Automatic revocation

Merki revokes a key automatically, without waiting for you to notice, when either of these happens:

  • The key is committed to git. If tooling, a harness, an IDE config, or any other file that embeds the key is committed to a repository, the Merki API sees it and revokes the key. This covers commits Merki can observe, including public repositories and repositories connected to Merki integrations. Commits in a private repository with no Merki integration are not visible to Merki. Connect the integration, or rotate keys on employee offboarding.
  • The key is found on the public internet. If Merki finds the key exposed on a public code host or site, it revokes the key, typically within 24 hours of detection.

The full trigger list, with what each one detects and how fast it acts, is in Revocation triggers.

What happens when a key is revoked

  • The key stops authenticating. Requests using it are rejected with 401. See Errors.
  • Requests already in flight may complete or fail, depending on when revocation lands. Only tokens actually delivered are billed. See Usage and metering.
  • The revocation is recorded against the account. Repeated exposure can affect the account itself. See the Acceptable use policy.

False positives and appeal

If a key was revoked in error (for example, a test fixture that only looks like a key), issue a new key and contact billing@merki.dev with the key prefix and the commit or URL that triggered the revocation. Merki reviews appeals within 2 business days. There is no automatic un-revocation: a revoked key stays revoked.

What to do

  1. Rotate the key. Issue a new one and update your tooling.
  2. Move the secret out of source. Use environment variables or a secrets manager.
  3. Add the key pattern to your ignore rules so the same leak cannot recur.

Why this exists

An exposed key is an open door. Revoking on the first signal limits the window in which a leaked key can be used, and it removes the decision from the person least likely to notice.