Runtime Logging

FlareKey has two logging paths. Generated FlareKey loaders report loader starts automatically. Use the public Runtime SDK only when your own loader or script needs to send additional named events.

Automatic logging for generated loaders

The standard generated loader reports a start when its fetched loader code runs. It does not need the Runtime SDK or any extra setup. A loader that is only downloaded is not counted as an execution. The report is best-effort: network or executor restrictions can prevent it from arriving.

When the client makes the information available, the event includes:

• Server timestamp, service, script, and loader ID.
• Roblox username, display name, and user ID.
• Experience name, place ID, universe/game ID, and server job ID.
• Executor name.
• Raw HWID.

Some values can be empty when Roblox or the executor does not expose them. The report is sent near the start of the loader, so it confirms that FlareKey received a loader-start beacon; it does not prove the protected script finished or that its own features succeeded. The standard loader-start event does not include a license key because it can occur before license verification.

Raw HWIDs are encrypted at rest and shown without masking only to workspace users who have the service's Manage Keys permission. Full license keys are available on event types where FlareKey actually received the key, such as license verification; they are not inferred for events that do not contain one.

Custom events with the Runtime SDK

The Runtime SDK is for custom logging. It is not required by the normal generated-loader flow. Its public Lua source can be fetched from https://flarekey.xyz/v1/sdk/runtime.lua; the SDK contains no service secret or embedded license. Set apiBase to https://flarekey.xyz, not the GitHub URL.

Fetch the module, then create a logger with the current FlareKey session and the service/script it is authorized for:

local Runtime = loadstring(game:HttpGet("https://flarekey.xyz/v1/sdk/runtime.lua"))()

local logger = Runtime.new({
    apiBase = "https://flarekey.xyz",
    serviceId = "svc_your_service_id",
    scriptId = "scr_your_script_id",
    sessionToken = FlareKey._session
})

local ok, err = logger:log("round_started", "Round started", {
    mode = "ranked",
    map = "Desert",
    round = 3
})

FlareKey._session must be the active runtime session token from a successful license verification. It is a short-lived bearer credential, not a public service ID or dashboard API key. If your custom loader stores the returned token under another name, pass that value as sessionToken. Do not hardcode or publish a real session token.

Each log call automatically collects the available Roblox username, display name, user ID, place ID, game ID, job ID, experience name, and executor. eventName and message describe what happened; the optional third argument is a table of extra scalar fields. logger:collect() returns the available context for your own use.

The SDK sends a POST to /v1/runtime/log and returns true when FlareKey accepts the event, or false plus an error code when it cannot send or the server rejects it. A successful response means the telemetry was recorded, not that your game action succeeded.

What the log endpoint accepts

POST /v1/runtime/log requires Authorization: Bearer <sessionToken>. FlareKey checks that the session is active, the service matches it, the script is within the session/license scope, and the license is still valid. An unauthenticated request is rejected; changing IDs cannot redirect the session to another service or a script the license does not authorize.

FlareKey limits context to known identity/game fields and bounds custom fields to a small number of short scalar entries. Some credential-like field names are rejected, but custom message and field contents are not a secret scanner. Do not put license keys, HWIDs, tokens, passwords, source code, or payloads in an event name, message, or custom field. Custom values are ordinary event details, not the separately encrypted sensitive fields. Where available, FlareKey associates the session's own HWID and license key with the event separately and encrypts those values at rest.

Runtime logs are telemetry only. They do not issue a license, grant a download, change a key, or affect tamper enforcement. Client-reported names, game metadata, executor names, and custom messages can be spoofed by a modified client; they are useful for owner visibility, not proof of identity or gameplay state.

Custom runtime.log events appear in Activity and can be selected for Discord webhook delivery. They do not add points to the Executions chart, which counts loader execution events.

Activity and Executions

Open Activity for the readable event feed, including script and key activity. Use its Script and Keys views to separate the two, and expand an event to inspect its details. Turn on Show advanced logs to include low-level delivery steps. Events that contain sensitive values show the full values only to users with Manage Keys permission for that service.

The Keys page also lets service managers filter by service and copy the full license key. Full keys and raw HWIDs are shown to authorized users; they are not replaced with hashes in those owner views.

Open Executions for the loader execution chart and recent execution rows. The chart fills empty time buckets with zeroes. Filter by outcome and select multiple scripts. The built-in ranges are day, week, month, and year; Custom uses an inclusive start and end date and accepts up to 366 days. The chart groups a day into hours, longer ranges into days, and a year into weeks. The recent execution list is limited to the latest 500 matching events.

The default loader beacon is recorded as a successful report when FlareKey receives it. That status does not mean the protected source completed successfully. Use your own runtime.log events for application-specific milestones; these remain activity logs rather than execution counts.

Discord webhooks

Webhooks are outbound Discord notifications, not a generic URL or signed webhook integration. In Dashboard → Operations → Webhooks, choose a service, paste an HTTPS Discord incoming-webhook URL, select the events to send, and save. Use Send test to verify delivery. FlareKey accepts Discord webhook URLs on discord.com or discordapp.com only.

Available event types are key.created, key.verified, key.failed, key.disabled, key.enabled, key.device_reset, key.archived, key.device_bound, key.device_mismatch, session.created, script.ticket_created, script.downloaded, runtime.loader, and runtime.log. The webhook sends a Discord embed with the event result, service, script, and available event details. Where the event has sensitive data, that can include the full license key and raw HWID; choose a private channel and limit its membership. A Discord webhook URL contains its own secret token, so keep it private. Send test uses a sample key.verified event, so select that event when testing delivery.