Quick start
From an empty dashboard to a compiled client that authenticates and receives your files. Around fifteen minutes.
You need the dashboard open and, for the last step, Visual Studio 2019 or newer with the C++ workload. Nothing else: the SDK links only against Windows system libraries.
Create an application
Go to Applications → New application. You need three things:
- Name — anything, shown to clients during init.
- Client version — the version string your loader will report, for example
1.0.0. - Key mask — the shape of your keys. Leave
SIMP-XXXX-XXXX-XXXXif unsure.
Decide the hardware policy now, because changing it later invalidates every device already bound. One device per key with CPU plus MachineGuid is a sensible default. See hardware locking.
On save you get a public application id and a 32 byte secret. The secret is never displayed; it only ever leaves the server inside an SDK download.
Upload the files your client will receive
Open the Releases tab. Create a release, give it a version such as 1.0.0,
then upload each file with a JSON key: core for your main module,
driver for a helper, and so on.
That key is the name your client asks for, so keep it stable. Publishing an update means putting a new binary behind the same key.
Finally press Make active. Only the active release is delivered, and a release with no enabled file cannot be activated.
Files at or below the inline limit (256 KB by default) come back inside the login response itself, so the client has the bytes after a single round trip. Larger files are pulled in encrypted chunks. Both paths are transparent to you.
Generate a key
Go to the Keys tab and press Generate. For a first test, one key, 30 days, level 1 is enough.
Keys are stored as an HMAC lookup plus ciphertext, so the table shows only a masked preview. Use the eye icon to reveal one, or Export CSV for a whole batch. Every reveal is written to the audit trail.
Download the SDK
Open the SDK tab and press Download SDK archive. The archive is
generated for this application, with the endpoint, application id, version, hardware policy and
masked secret already written into keyauth_config.h. You do not paste any credentials
by hand.
Unpack it and build:
build.bat
Or with CMake:
cmake -B build -S . -A x64
cmake --build build --config Release
Authenticate and read your files
Run keyauth_example.exe, paste the key, and you should see the license details followed
by the active release and its files. The example writes each payload next to the executable.
The whole integration is this short:
#include "include/keyauth.h"
#include "keyauth_config.h"
int main()
{
keyauth::Client client(keyauth_config::make());
if (!client.initialize()) return 1; // version check, opens a session
if (!client.login(userKey)) return 1; // key check, binds the device
for (const keyauth::FileInfo& info : client.files()) {
std::vector<std::uint8_t> payload;
if (client.download(info.key, payload)) {
// payload is plaintext, decompressed, SHA-256 verified
// info.key is the JSON key you chose in step 2
}
}
client.validate(); // heartbeat, call every few minutes
client.logout();
}
Watch the Activity tab while you do this. You should see
init, login.success and release.deliver appear live.
If something fails
Every failure carries a machine readable code. Read it with
client.error_code() and client.error_message(), then look it up in the
error reference. The most common first run problems:
| Code | Cause |
|---|---|
VERSION_MISMATCH | The client version does not match the application. Fix one of them. |
BAD_SIGNATURE | Wrong secret. Re-download the SDK rather than editing the config by hand. |
CLOCK_SKEW | The machine clock is more than the tolerance out. Sync time. |
HWID_LIMIT | The key is already bound to its device limit. Reset devices on the key. |
Next
- Releases and files for update workflows and level gating.
- C++ SDK reference for the full API.
- Security model for what is and is not protected.