API documentation

Edge-native license control, end-user register/login/upgrade, and Bearer API keys for developer tooling.

Three audiences

SDKey exposes one API under /api/v1. How you authenticate depends on who is calling:

Client program — license validate

No API key. Your binary opens a crypto session, then validates a license key (optional hardware id). Start with License control.

Client program — end-user register / login / upgrade

Same sealed session as license validate. After POST /session/init, seal requests to POST /api/v1/client/register, /login, and /upgrade (username + new license key, no password). Optional HWID, IP/HWID bans; version gated at session init. Details in License control and the API reference.

Developer tooling (scripts / CI)

Use a sdk_live_… Bearer token for the same actions as the dashboard — apps, settings, licenses, bans, tiers, users. See API keys.

Base URL

Use this origin in clients and tooling (no trailing slash):

API base

https://api.sdkey.dev

Versioned routes are under /api/v1. Health check: GET https://api.sdkey.dev/health. The developer dashboard stays on https://dash.sdkey.dev and talks to the API over same-origin /api/*.

Errors and custom messages

Plaintext failures (session init, plaintext validate / client auth when CRYPTO_ENFORCE=false) use a consistent shape. The error string is often editable per app (responseMessages):

{
  "success": false,
  "error": "Human-readable message",
  "code": "ERROR_CODE"
}

Sealed license validate and sealed client auth are different: after decrypt, both success and failure plaintext use message (not error). Session init success bodies have no message field. Details: License control.

Data protection

If you collect end-user personal data through SDKey, you are typically the controller. See Data protection for roles, retention, and export/delete APIs.

Full reference

Every endpoint (auth, apps, licenses, session, client, metrics, account) is listed on API reference.