Browse the library

Test before you sell

Software that activated its first key is not yet ready to sell. This guide is a test list in order, each line with what to do on the dashboard and what your software must get, so you see every error a customer could meet before a customer does.

3 min read

Get ready

Use test keys for every test: they do not count against your limits, expire after 24 hours and carry a TEST label. Make them on the Connect software page (the Make a test key button) or in the key creation panel, see Test keys.
Test the very build you will release, not the one running in your editor: its settings, state folder and version must be the real ones.
Keep Integration › Connect software open: step 4 shows every call, refused ones with their error code and how to fix it.

The test list

Test	How	Your software must get
First activation	A new TEST key	Activation succeeds; the Connect software page shows Connected
Reopen on the same machine	Close the software and open it again	Still succeeds, without using another seat (the device key is kept)
A mistyped key	Change one character of the key	`invalid_credentials`, with the right sentence shown to the user
A second machine	The same key on another machine (the default plan allows 1 machine per key)	`device_limit`
Suspend	Licenses › ⋯ › Suspend while the software runs	The next heartbeat gets `session_expired`; activating again gets `license_suspended`. Reinstate, and it runs again
Reset devices	Licenses › ⋯ › Reset devices	The running session ends (`session_expired`); activating again takes the seat back
No network	Disconnect after activating	An error with `retryable` after the SDK's own retries; the saved token keeps the software running, unless Online-Only Mode is on
Forced update	Set the Minimum version above the build you test	The next activation gets `update_required`
Public release	Turn on Publicly released in Integration › App settings	A machine already holding a TEST key gets `test_key_disabled`; a new machine gets `invalid_credentials`

Every code comes with a sentence for the user in English and Vietnamese in every SDK; the whole table is in Error codes. Make sure your software shows that sentence, not just the code.

When you use other scenarios, test their parts too: sign-up and a wrong password (Sign-in modes and trials), a second trial on the same machine, reading variables (App variables), signed update checks (Signed releases and updates).

Test on a clean machine

Install the release build on a machine that never had development tools (a fresh virtual machine will do) and run it to a completed activation:

No library is missing: each Get started by language guide says what the build needs on a customer's machine.
The state folder sits where the user can write (usually %APPDATA% on Windows), not in the install folder.
A clock a few minutes off still works: the SDK corrects itself when the server reports the difference.

Look at the dashboard

End users › Devices & sessions: the test machine and its sessions.
App security › Activity log: every accepted activation and every refusal at sign-in with its reason, in the order you just tested. When a customer says they cannot get in, this is also the first place to look, see Activity log.
App security › Protection: no unusual signal from the test machine. A signal such as forged signatures usually means the API address or public key in the build is wrong.

Before you sell