Integration API

How Custom mode works

In Custom mode the loader is bare: it never draws a key prompt. Your script owns the unlock — your ScreenGui, your branding, your copy — and hands the key to the loader before running it. A TextBox, a key saved from last session, or an ad unlock you trigger yourself all work.

The loader still does the real check. It computes the device’s HWID, verifies the key with AegisLoader and binds it to that device on first use. Validating from your UI is for a friendly error message, not for security.

1. Your UI gets a keyFrom a TextBox, a saved file, or the ad unlock.
2. Optional: validate itCall validate so you can say “expired” or “locked to another device” in your own words.
3. Set getgenv().KeyThe loader reads it once when it starts.
4. Run the loader lineIt checks the key, binds the HWID and runs your protected build. A bad key stops it before any of your code executes.

Endpoints

Base URL https://api.aegisloader.com. Every endpoint here is public and called from the client — no API key. Never put your account key in a script you ship. Responses are JSON.

{id} is a key system ID or a Custom script ID — a short code like gu93Zx0LH3 (it’s in your script’s loader line). The samples on this page use .

Rate limits

Limits are per IP, so one user hammering a button can’t lock out everyone else. There’s no 429 — over the limit the endpoints fail soft: validate answers 200 with "ok": false and "reason": "key unavailable" (back off — don’t validate on a loop), and /gate/…/wait returns {} — the same as “not ready yet” — so just reconnect.

Errors

A bad key is not an HTTP error: validate answers 200 with "ok": false and a reason. A non-200 means the request itself was wrong or we couldn’t answer it.

One key, every script

A key system groups Custom scripts behind one set of keys. A key issued by the key system — by hand or earned through its ad unlock — runs every attached script that takes the system key. Your users unlock once; you ship as many scripts as you like.

Key source, per script

Each attached script chooses which keys it accepts. Change it from the script’s row in Projects.

System key

Accepts keys issued by the key system, including ad-earned ones. This is the default when you attach a script.

Own keys

Ignores system keys and only accepts keys created for this script. Use it for a premium script that sits next to free ones in the same hub.

Running several scripts

getgenv() lives for the whole session, so set getgenv().Key once and every loader you run after it picks the key up. A script on its own keys needs its own key set before its loader runs.

Each connected script decides whether it takes the system key or its own. To check whether this key unlocks a particular script, call validate with that script’s own {id}.

The getgenv().Key convention

The loader reads getgenv().Key once, when it starts (a plain global Key works too). Set it, then run the loader line — in that order, in the same script.

You don’t send the HWID

Keys bind to the first device that runs them. If a user moves to a new PC, reset the key’s device from Users & Keys — don’t hand out a second key.

Full example: key prompt with a saved key

A minimal prompt in a ScreenGui. It remembers the last key with writefile so returning users skip the prompt, and falls back to asking when the executor has no file functions.

Validate a key

Parameters

Request

Responses

Reasons

Validate, then run

Wrap the request in pcall — HttpGet throws on network errors and on non-200 responses.

~120 requests a minute per IP. Validate when the user submits, not on a loop.

Ad unlock from your own UI

Same Linkvertise gate Ad-supported projects get, started from your button. You send the user a gate link; they finish a short ad step in their browser; your script long-polls until the key is ready. The link, anti-bypass check and key duration come from Ad Rewards — set those up first.

1. Make a tokenAny random string, unique to this user this run. It ties their browser unlock to your waiting script.
2. Send them the linkExecutors can’t open a browser, so setclipboard the gate link …/gate/{id}={token} and tell them to paste it. They pass a human check and the ad step.
3. Wait for the keyGET …/gate/{id}={token}/wait holds open ~25s and returns {"key":…} the moment they finish — or {} on timeout, so just call it again.
4. Run with the earned keyThe key is already bound to this device. Set getgenv().Key and run the loader.

The gate link

Parameters

Offer a provider choice in your UI

With two or more ad providers enabled (Linkvertise, LootLabs, Work.ink), you can let users pick in your own UI instead of on the gate page. Turn on “Let users choose the ad in your own UI” in Ad Rewards, read the enabled providers, and show a button per provider that opens its gate link.

{
  "providers": [
    { "id": "linkvertise", "name": "Linkvertise" },
    { "id": "lootlabs",    "name": "LootLabs" },
    { "id": "workink",     "name": "Work.ink" }
  ],
  "gate": "https://api.aegisloader.com/gate/{id}",
  "ttl": 86400,
  "pick_in_ui": true
}

Send the user to the gate link for their choice — the same gate link, with ?provider={id} appended:

After they finish, poll /gate/{id}={token}/wait for the key exactly as below — the flow from here is identical no matter which provider they chose.

Wait for the key

Parameters

Luau: “Get key” button

Make a token, copy the gate link for the user, then long-poll /wait with game:HttpGet until the key arrives — no executor request needed, since the whole flow is plain GETs.

Each /wait covers a ~25s wait — loop the reconnect, not a tight poll. The gate link stays valid a few minutes.