3rd party / external key check API
This documentation is for 3rd party non-lua related applications who wants to use the Luarmor Ad Reward system to generate & validate keys.
If you are a script developer, refer to this documentation instead. This page isn't for you.
Your project must be approved before you can use any of these endpoints, if you don't have the "shared secrets" or "app name", contact federal.
INTRO
This API is straightforward, you can check if a key is valid / banned / expired / hwid locked etc., the only complicated part is the generation of SHA1 signatures in request and response bodies. These SHA1 signatures are required in order to ensure that important parts of the HTTP traffic haven't been tampered with.
Once the user has generated / renewed a key via ad link, their key will have the "reset" state. In this state, first validity check request will automatically mark the key as "claimed/HWID linked" and checking it's validity from a different HWID will return a HWID mismatch error.
All activity on this API is reflected to the dashboard and keys as "execution count". You can see the statistics of daily executions, total users, who executed how many times etc.
HTTP API
STEP 1 - First Request (Fetch server info):
GET https://sdkapi-public.luarmor.net/sync
Response:
{
st: 1739703913, // UNIX TIMESTAMP OF THE CLOUDFLARE WORKER
cf: "AMS", // CF COL (REGION) NAME << not needed for the auth
nodes: [ // available nodes that you can randomly pick from.
"https://eu1-roblox-auth.luarmor.net/",
"https://as1-roblox-auth.luarmor.net/",
"https://as2-roblox-auth.luarmor.net/",
"https://as3-roblox-auth.luarmor.net/",
"https://us1-roblox-auth.luarmor.net/",
"https://us2-roblox-auth.luarmor.net/",
"https://au1-roblox-auth.luarmor.net/",
"https://au2-roblox-auth.luarmor.net/"
]
}Parse this json good and nice, pick a random node URL from the "nodes" array. Make sure to randomly pick it at runtime, so load is equally balanced.
"st" stands for "server time", you will use this value while calculating the "request signature". Keep it in a variable for now. It is always a 32 bit integer.
Your implementation should be looking like this so far:
STEP 2 - Checking the key
GET https://[node-name].luarmor.net/external_check_key?by=...&key=...
Query parameters:
by: Integration / app name. Defined as "app_name" in the example code above.
key : User-inputted 32-char alphabetic (a-z A-Z) key to check the validity of.
Headers:
Content-Type
application/json
clienttime
1739703913
the unix timestamp retrieved from server.
clientnonce
s2mle100lesh420f
16-char random string generated by your code.
clienthwid
03b3b409-f0b97340-40b97304-48327b49827
HWID value.
exec-fingerprint
03b3b409-f0b97340-40b97304-48327b49827
HWID value, same as clienthwid. But "exec-" must be the name of your platform/executor.
externalsignature
0391a1e58f324b3a0c79d32dd09436bd45bfc773
SHA1 signature. See below for how it's calculated.
How is "externalsignature" calculated?
This ensures that the outgoing request parameters can't be spoofed / tampered with, without replicating the signature, which should be significantly difficult if you obfuscate/virtualize the auth part of your binary.
HTTP Response would look like this:
β οΈYou will get a "signature" field in the response if the code is "KEY_VALID".
For everything else, there will be no signature included. Just simply reflect the error message to the user. It doesn't matter if they spoof anything other than KEY_VALID. See below for response signature validation.
How is KEY_VALID -> "signature" calculated?
You will use this response signature to check if returned KEY_VALID is actually real, and not just coming from a skid's fiddler4 autorespond rule.
Rest of your code should look like this:
Possible status codes can be found here:
But generally, you're only interested in whether it is "KEY_VALID" or not.
Contact f.e.d.e.r.a.l for any questions.
Last updated