Sentinel Network is a cloud-hosted service. This page describes how the key workflows operate so you can reason about latency, consistency, and caching behaviour.

​
System Overview

Your Game Client ──► Your Game Server ──► Sentinel Network API
                                               │
                                               ▼
                                         Publisher Dashboard
  • Your game client reads a signed payload from the SentinelID device and forwards it to your game server.
  • Your game server calls the Sentinel Network API using your API key.
  • The API verifies the device, applies your enforcement policy, and returns the result.
  • The Dashboard is a web UI for managing publishers, games, API keys, bans, and team members.

​
Data Flow: Device Check

When your server calls POST /v1/device/check:
  1. The API verifies the ES256 signature against the device’s registered public key
  2. The API checks for replay attacks (each signed payload can only be used once within a 10-minute window)
  3. The API loads your publisher enforcement policy
  4. The API assembles the ban and reputation data for the device, scoped to your policy settings
  5. The API returns the DeviceCheckResponse with banned, bans, and reputation
The response reflects your publisher policy — only scopes you have opted into are enforced or included in reputation scores.

​
Data Flow: Ban Creation

When your server calls POST /v1/bans:
  1. The API checks the idempotency_key to prevent duplicate bans
  2. The ban is recorded
  3. Reputation scores are queued for recomputation (see Reputation Updates below)
  4. The API returns the ban confirmation immediately

​
Reputation Updates

Reputation scores are not updated synchronously when a ban is created or revoked. There is a brief processing delay — typically under 1 second — before the updated score is reflected in subsequent device checks. Additionally, reputation data is cached. After a ban operation, device check responses may return slightly stale reputation scores for up to 60 seconds.
For safety-critical decisions immediately after issuing a ban, query the ban list directly using GET /v1/device/{device_id}/bans/{type} rather than relying on the reputation score in the device check response.

​
Replay Protection

Each device check payload must include a unique jti (a UUID generated by the device). If the same jti is seen again within 10 minutes, the request is rejected with replay_detected. This prevents captured payloads from being replayed.

​
Policy Caching

Your publisher policy is cached after each read. Changes made via PUT /v1/policy may take up to 10 minutes to take effect in device check responses.