Skip to content
Keylight Keylight Keylight Docs

SDK key

The SDK key is a per-account secret that rides along on every SDK call to Keylight. Its job is not to authenticate end users - license keys do that. The SDK key authenticates your app build as the legitimate caller of your Keylight endpoints.

What it protects against

Section titled “What it protects against”

Without the SDK key, anyone could:

  • Enumerate license keys by hammering /activate with guesses against your account.
  • Drive your monthly API-call quota to exhaustion and take your legitimate users offline.
  • Scrape your product catalog via 404 vs 404-on-product probing.

With it, those attackers need the SDK key first. Getting the SDK key requires reverse-engineering a binary or compromising a build pipeline - not a trivial step.

What it doesn’t protect against

Section titled “What it doesn’t protect against”
  • A determined reverse engineer will extract it from a shipped binary. Ed25519 leases, the key prefix namespace, and the server-side state machine do the heavy lifting against that threat, not the SDK key. See the full threat model.
  • A leaked key - if someone extracts it, they can do anything an app build can do. That’s why rotation is a one-click dashboard operation, and why fresh app builds pick up new keys cleanly.

Why it’s per-account, not per-product

Section titled “Why it’s per-account, not per-product”

Your Keylight account represents you as the developer; products are what you sell. The SDK key authenticates your app builds - all products are ones you publish. A separate-per-product model would mean embedding N keys in one app binary for accounts with multiple products without adding a security property.

Server-side enforcement

Section titled “Server-side enforcement”

On every SDK request, Keylight:

  1. Reads the X-Keylight-SDK-Key header.
  2. SHA-256 hashes it.
  3. Timing-safe compares against the stored hash for your account.

Failure → 401 Invalid or missing SDK key.

Section titled “Related”