Skip to content
Keylight Keylight Keylight Docs

SDK key

The SDK key is a per-tenant secret the Swift SDK sends on every call to Keylight as X-Keylight-SDK-Key. It gates /activate, /validate, and /deactivate.

If you’re building with the Swift SDK, you embed this in your app. If you’re calling the HTTP API directly, you send it as a header.

Shape

Section titled “Shape”
sdk_live_<64-hex-chars>

Example: sdk_live_a7b2c9e84f1d.... The prefix makes it easy to spot in code review and log scrubbers.

Generating / rotating

Section titled “Generating / rotating”

From the dashboard: Settings → SDK Key → Generate (first time) or Rotate (subsequent times). The plaintext key is shown once - copy it immediately.

Keylight keeps a one-time plaintext reveal available for 30 minutes after generation, specifically for the onboarding “install the SDK” step. After that, only the SHA-256 hash is kept.

Where to put it in your Swift app

Section titled “Where to put it in your Swift app”

Pass it to Keylight.manager:

Keylight.manager(
    sdkKey: "sdk_live_...",
    tenantId: "acme",
    productId: "pro",
    // ...
)

The SDK forwards it on every outbound request. See Keylight.manager for the full factory call.

Keeping it out of source control

Section titled “Keeping it out of source control”

Keylight treats the key like a public API key - it goes in shipped binaries. But that doesn’t mean it belongs in your repo:

  • Inject at build time from an .xcconfig the CI has access to.
  • Or pull it from a Keys.plist you .gitignore.
  • Or fetch it at first launch from a server you control.

The last option is the most defensible against leaks but adds a first-launch network dependency.

What to do if it leaks

Section titled “What to do if it leaks”
  1. Rotate immediately in the dashboard.
  2. Ship an app update carrying the new key.
  3. Users on the old build will 401 once they update to the new binary.
Section titled “Related”