The API Key Model

Where it lives

// Inline in Atlas.h - set once and rebuild.
inline std::string API_KEY = "YOUR_API_KEY";
 
// Or override at runtime, before Startup:
Atlas::API_KEY = "YOUR_API_KEY";
Atlas::Startup();

What actually authenticates

A leaked API key alone does not let an attacker impersonate a user. The real auth stack:

1. X25519 ECDH handshake - fresh symmetric key per session.
2. Ed25519 server signature - the server's handshake reply is verified against three public keys pinned inside Atlas Auth.lib / Atlas.dll (primary, backup, emergency). A nulled server can't produce these signatures.
3. HWID mixing - the session key is derived with the HWID folded in, so a stolen token doesn't work from a different machine.
4. Per-request nonce - replays are dropped.
5. Builds, if you've added any on the dashboard.

Ed25519 key rotation

Three public keys are pinned - primary, backup, emergency. The server picks one per handshake, so you can rotate without shipping a new library. Verification is local: a server that can't sign with any of the three keys is rejected before the handshake completes.

Handshake

1. Client → Server: ephemeral X25519 public key + app id.
2. Server → Client: Ed25519-signed reply with the server's ephemeral X25519 public key plus the app's HMAC secret, encrypted under the shared key. The signature is checked against the three pinned pubkeys.
3. Shared secret derived. Every subsequent request uses it.

From request two onward, the app id is decorative. The session key is the only thing that matters.

Free tier

3 applications · 300 users per app · 3 file uploads per app. No card to start.

Get one

atlassecurity.site/dashboard → Applications → New application. The key is shown on creation. It can be revealed again, after a confirmation, under Settings → SDK and key.