Getting Started

FlareKey sits between your customers and your protected Lua. Instead of shipping raw source, you register a script once, hand out license keys, and let the runtime API decide who receives the real code and when. Everything is organized under a service, and a short-lived ticket, not the license key, is what actually downloads the source. This page covers the core objects and the exact order a loader calls them.

What FlareKey Is

FlareKey is the licensing and delivery layer for protected scripts. You create services, attach scripts, generate customer license keys, verify those keys at runtime, and deliver source through short-lived tickets.

Service vs Script vs License Key

A service is the product container. A script is a protected asset inside that service. A customer license key normally unlocks one script, while optional service-wide keys can unlock every script in that service.

Runtime Session vs Customer Key

A customer license key identifies the buyer. A v2 loader creates a short-lived, session-bound runtime authorization and never carries the service-wide publisher/runtime key. Keep publisher credentials in dashboard/admin workflows only.

1. Owner creates a service and script.
2. Owner generates a script-specific customer license key.
3. Loader calls POST /v1/licenses/verify with the service ID and customer license key using protocol v2/session binding.
4. Verify returns a short-lived session token and signed challenge transcript.
5. Loader requests a script ticket.
6. Loader downloads signed metadata plus the exact ticket-bound artifact.
7. Loader downloads the protected script with the single-use ticket.
8. The source runtime guard validates the signed delivery metadata before real code runs.

• Start by creating one service, then add at least one script and generate a customer license key for it. Nothing verifies until those three exist.
• Generate a v2 loader from the dashboard after enabling session-bound delivery. The shipped loader needs the service ID and customer license key, not a service-wide runtime key.
• The customer license key starts the runtime session. The server then issues clearance, an exact-build ticket, and signed delivery metadata; none of those values is a reusable service-wide capability.
• Verification never returns source directly. It returns a short-lived session token; the loader then trades that token for a single-use ticket, and only the ticket downloads the code.
• Everything a public loader can see is public. Never place management, publisher, billing, Discord bot, or database secrets anywhere a customer can reach.