The client SDK lets your game client talk to a physically connected SentinelID USB dongle. It handles the HID framing protocol, reads the device’s signed 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.
FieldValue
Vendor ID0x239A
Product ID0xCAFE
ProtocolUSB HID, 64-byte reports

Installation

npm install @sentinelid/client
# Requires node-hid (bundled as a dependency)

Enumerate Devices

List all connected SentinelID dongles.
import { SentinelDevice } from "@sentinelid/client";

const devices = SentinelDevice.enumerate();
console.log(devices);
// [{ path: "/dev/hidraw0", vendorId: 0x239A, productId: 0xCAFE, ... }]

Open a Device and Request a Check

The typical flow is to open the first available device, send a check challenge, and receive a signed DeviceCheckRequest to forward to your server.
import { SentinelDevice } from "@sentinelid/client";

const device = SentinelDevice.openFirst();
try {
  const checkReq = device.requestCheck("pub_acme", "game_fps_01");
  // Forward checkReq to your game server
  const response = await fetch("/api/session/start", {
    method: "POST",
    body: JSON.stringify(checkReq),
  });
} finally {
  device.close();
}

Open a Specific Device

If multiple dongles are connected, select one by path.
const devices = SentinelDevice.enumerate();
const device  = SentinelDevice.open(devices[0]);

DeviceCheckRequest Fields

The object returned by requestCheck / request_check maps directly to the Device Check API body:
FieldTypeDescription
device_idstringUnique device identifier stored on the dongle
publisher_idstringEcho of the publisherId argument
game_idstringEcho of the gameId argument
algstringSignature algorithm — always ES256
payload_b64stringBase64-encoded signed payload from the device
sig_b64stringBase64-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:
ByteFieldValue
0Report ID0x00
1CMD0x03 (SIGN_PAYLOAD)
2FLAGSSTART=0x01, END=0x02
3SEQPacket sequence number (0-based)
4–63DATAChallenge JSON chunk
The challenge JSON {"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:
ByteFieldValue
0CMDEcho of the command
1FLAGSSTART=0x01, END=0x02, ERROR=0x04
2SEQPacket sequence number
3–63DATAResponse JSON chunk
Reports are read and concatenated until FLAG_END is set. If FLAG_ERROR is set, byte 3 contains an error code:
CodeNameDescription
0x01BUSYDevice is processing a previous request
0x10BAD_STATEUnexpected command in current state
0x11PAYLOAD_TOO_LARGEChallenge exceeded device buffer
0x30RATE_LIMITToo many requests — back off and retry
0x40ATECC_FAILSecure element signing failure
0xFFUNKNOWN_CMDUnrecognized command byte
0xE0PROVISION_DENIEDDevice not provisioned for this publisher
Reads time out after 5 seconds; a TimeoutError / RuntimeException is thrown if no response is received.

Sandbox Testing

During development you can use the sentinelid-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.
pip install sentinelid-sim

# Register the simulated device with your sandbox environment (once)
sentinelid-sim register --api-key sni_sandbox_... --publisher-id pub_acme

# Generate a signed payload (pass the output to your server instead of calling the SDK)
sentinelid-sim payload --publisher-id pub_acme --game-id game_fps_01
The simulator calls 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.