Appearance
API Overview
FlareKey exposes two separate APIs with two separate kinds of credential. The dashboard API manages your workspace and is authenticated with a management API key that must never leave your own systems. The runtime API is what a shipped loader talks to, and it never carries your management key. Mixing the two up is the most common and most damaging integration mistake, so this page covers which credential goes where before you start.
Getting your management API key
- Open the dashboard and go to your account settings.
- Generate or regenerate the management API key. The full key is shown once, at creation time - store it immediately in your secret manager.
- Afterwards only a masked preview and the creation date are visible; FlareKey stores a hash, not the key, and cannot show it to you again.
- Send it as an HTTP header on dashboard API calls: Authorization: Bearer fk_live_xxx
- Lost or leaked keys are replaced by regenerating, which immediately invalidates the previous key. Rotation has to be done from a signed-in session, not with the API key itself.
The credentials, and which are safe to ship
| Credential | Looks like | Used by | Safe in a shipped loader? |
|---|---|---|---|
| Management API key | fk_live_... | Your own backend or tooling, against /api/dashboard and /api/obfuscation | No - it can manage your entire workspace |
| Service runtime key | pk_... | Service-level runtime configuration | No - keep it in dashboard and admin workflows |
| Runtime secret | 40 hex characters | The service's runtime guard | No |
| Customer license key | FLARE-XXXX-XXXX-XXXX-XXXX | The customer running your script | Yes - this is the value a buyer holds |
| Session token | api_sess_... | One runtime session, returned by license verification | Yes - short-lived and session-bound |
| Ticket | ticket_... | Authorizing exactly one protected download | Yes - single use |
Security awareness
- Anything a public loader can read is public. A customer can read every string in the script they were given, so the only credentials that belong there are the ones scoped to that customer's own session.
- The runtime flow is deliberately layered: a license key starts a session, the session buys a single-use ticket, and only the ticket downloads code. Do not collapse those steps or cache their results across users.
- Rotate a management key the moment you suspect exposure. Regenerating invalidates the old key immediately.
- Treat error codes as machine-readable outcomes rather than strings to display. Back off on rate_limited, re-verify on session_expired, and request a new ticket on ticket_used or ticket_expired.
- Never send management credentials from a browser. Calls that use fk_live_ keys belong on a server you control.
Limits
Two separate limits apply: a monthly request allowance tied to your plan, and a fixed per-minute rate limit that protects the service from bursts.
| Plan | API requests / month |
|---|---|
| Free | 10,000 |
| Basic | 200,000 |
| Advanced | 1,500,000 |
| Pro | Unlimited |
| Enterprise | Unlimited |
| Rate limit | Ceiling |
|---|---|
| Runtime and API endpoints | 120 requests per minute |
| Dashboard write actions | 60 requests per minute |
| License key generation | 20 requests per minute |
| Authentication attempts | 20 per 15 minutes |
- Exceeding a rate limit returns the rate_limited error code. Back off and retry rather than looping.
- Unlimited means the plan is not subject to the normal monthly cap. Per-IP abuse protection still applies.
Next
API Usage documents every runtime and dashboard endpoint with its request, response and error codes.