DeviceCheckRequest, and hands it back to your code to forward to your game server.
The signed payload produced by the device must be forwarded to your game server, which then calls the Server SDK to verify it with the Sentinel Network API. Never send your API key to the game client.
Device VID / PID
All SDKs enumerate by the following USB descriptor. Note that these IDs are not exclusive to SentinelID hardware — the SDK matches on both VID and PID together.| Field | Value |
|---|---|
| Vendor ID | 0x239A |
| Product ID | 0xCAFE |
| Protocol | USB HID, 64-byte reports |
Installation
Enumerate Devices
List all connected SentinelID dongles.Open a Device and Request a Check
The typical flow is to open the first available device, send a check challenge, and receive a signedDeviceCheckRequest to forward to your server.
Open a Specific Device
If multiple dongles are connected, select one by path.DeviceCheckRequest Fields
The object returned byrequestCheck / request_check maps directly to the Device Check API body:
| Field | Type | Description |
|---|---|---|
device_id | string | Unique device identifier stored on the dongle |
publisher_id | string | Echo of the publisherId argument |
game_id | string | Echo of the gameId argument |
alg | string | Signature algorithm — always ES256 |
payload_b64 | string | Base64-encoded signed payload from the device |
sig_b64 | string | Base64-encoded ES256 signature |
HID Protocol
The SDK handles the low-level framing automatically. Each HID report is 64 bytes.Write (host → device)
Output reports use the following header layout:| Byte | Field | Value |
|---|---|---|
| 0 | Report ID | 0x00 |
| 1 | CMD | 0x03 (SIGN_PAYLOAD) |
| 2 | FLAGS | START=0x01, END=0x02 |
| 3 | SEQ | Packet sequence number (0-based) |
| 4–63 | DATA | Challenge JSON chunk |
{"publisher_id":"…","game_id":"…"} is split into 60-byte chunks and spread across one or more reports. The START flag is set on the first report; the END flag is set on the last.
Read (device → host)
Input reports have no leading report ID byte:| Byte | Field | Value |
|---|---|---|
| 0 | CMD | Echo of the command |
| 1 | FLAGS | START=0x01, END=0x02, ERROR=0x04 |
| 2 | SEQ | Packet sequence number |
| 3–63 | DATA | Response JSON chunk |
FLAG_END is set. If FLAG_ERROR is set, byte 3 contains an error code:
| Code | Name | Description |
|---|---|---|
0x01 | BUSY | Device is processing a previous request |
0x10 | BAD_STATE | Unexpected command in current state |
0x11 | PAYLOAD_TOO_LARGE | Challenge exceeded device buffer |
0x30 | RATE_LIMIT | Too many requests — back off and retry |
0x40 | ATECC_FAIL | Secure element signing failure |
0xFF | UNKNOWN_CMD | Unrecognized command byte |
0xE0 | PROVISION_DENIED | Device not provisioned for this publisher |
TimeoutError / RuntimeException is thrown if no response is received.
Sandbox Testing
During development you can use thesentinelid-sim package to generate valid signed payloads without physical hardware. The simulator persists its identity (device ID + EC key pair) on first run, so the same device ID is reused across test sessions.
POST /v1/device/sim/register which is only available in the sandbox environment. Attempting to register a simulated device in production will be rejected. See the Device Simulator page for full subcommand reference and CI/CD usage.