Skip to main content

Integration Snippets

The reference client covers most scripts. Use these when you’re building your own client or checking keys from a backend. The full contract: key/check. The two rules every client must follow:
  1. Sign the request: HMAC_SHA1(auth_secret, nonce|key|hwid), lowercase hex, in the body’s signature field.
  2. Verify the response: HMAC_SHA1(auth_secret, nonce_echo|status|expiresAtUnix|project_id) must match the response’s signature, and nonce_echo must equal your nonce. Fail closed.

bash / curl

Signing needs a hex HMAC, so plain curl gets a hand from openssl:

Node.js

A backend-side check with verification (no dependencies):

Luau (executor)

Minimal fail-closed gate, if you’d rather not embed the reference client:
The reference client has the missing pieces (hmacSha1Hex, isoToUnix) ready to copy — and it’s been through a 14-scenario live suite on Delta, which a hand-rolled version hasn’t.

Hardware ID

HWID is passthrough — Vampauth compares strings. A single weak value is easy to spoof, so mix several signals and send the hash:
  • Persisted storage — Roblox’s per-machine storage survives sessions (e.g. rblxanalytics-backed storage). Store a random ID once, reuse forever.
  • Executor fingerprint — install IDs or API surfaces unique to the current install.
  • Runtime signals — platform, executor version, Roblox build, resolution, locale.
Hashing (or HMAC-ing with a secret baked into your script) hides which signals matter. Keep the result stable per machine; let it change when the hardware genuinely changes.

Nonce

Random, fresh, once per call, up to 128 chars. The server stores nothing — it echoes the nonce back and folds it into the response signature. Your client must check nonce_echo == nonce and verify the signature; the nonce check alone doesn’t prove anything (an attacker replaying traffic can echo your nonce too, but they can’t sign it).