Security
PlayerPal's security model starts from what it does not hold: no player email, name or phone number, and no partner can see another partner's players. On top of that, every request is authenticated, scoped to one party and safe to retry. This page summarises the controls and their status.
The labels mean: Available (built and tested in the platform), In development (being built; behaviour may change) and Planned (designed, not built yet).
At a glance
| Control | Status |
|---|---|
| OAuth client credentials for partner APIs | Available |
| Signed requests (HMAC with timestamp and nonce) for partner APIs | Available |
| Scope taken from credentials, never from the request | Available |
| Per-partner credentials for linking and activity batches | In development |
| Player sessions in secure, HTTP-only cookies | Available |
| Passkeys and recovery codes; no email or SMS sign-in | Available |
| Assurance levels | In development |
| Idempotent writes | Available |
| Separate portal per audience | Available |
| Production sign-in for partner and staff portals | In development |
| Workforce single sign-on | Planned |
Partner API authentication
AvailablePartner APIs for KPIs, studio analytics and fact ingest accept two schemes. Both resolve to one principal: your party, your party type and the scopes you were granted.
| Scheme | How it works |
|---|---|
| OAuth 2.0 client credentials (recommended) | Your service account requests a short-lived access token (5 to 15 minutes) and sends it as a bearer token |
| PP-HMAC-SHA256 request signing | Each request is signed over its method, path, query, body hash, a timestamp and a single-use nonce |
Signed requests are rejected if the timestamp is more than five minutes from PlayerPal's clock or the nonce has been seen before, so a captured request cannot be replayed. Signing keys are issued per party, two can be active at once for rotation, the secret is shown once, and secrets are encrypted at rest. See Authentication.
Linking and activity batch endpoints currently use a single platform credential issued by PlayerPal. Per-partner credentials for these endpoints are being built. Operator link requests are already protected by a short-lived assertion signed with the operator's own key.
Scoped access
Available- Scope comes from credentials. A party ID in a query string, header or payload field is ignored. Activity is attributed to the integration that sent it, not to an operator named in the payload.
- Only your Aliases work. An Alias issued to another party gets the same response as one that does not exist, so probing reveals nothing.
- Fixed queries only. Partners call a fixed catalogue of KPI queries. Every query is filtered to the caller's party, and queries that would return individual player records outside the caller's own Aliases are refused.
- UI is not a boundary. Hiding a screen is never treated as access control; the API enforces audience, party and permission on every call.
Player sign-in and sessions
Available- Passkeys first. Players sign in with passkeys, an approved social account that shares only an opaque identifier, or a PlayerPal ID and password. Email magic links and SMS codes are not offered.
- Recovery without email. One-time recovery codes are stored hashed, limited by attempt rate and shown to the player only once.
- Cookie sessions. The player portal keeps the session in an
HttpOnly,Secure,SameSitecookie. Long-lived tokens are never stored in the browser. - Session control. Players can see their active sessions and sign out other devices.
- Step-up for sensitive actions. Unlink, Delete Account and generating new recovery codes require the player to confirm their identity again.
- Embedded flows. Linking from a casino opens a first-party PlayerPal window with one-time codes and exact origin checks. No tokens go in URLs and no third-party cookies are used.
Assurance levels
In developmentNot every Account carries the same trust. PlayerPal records an assurance level for each Account and uses it to decide which actions are allowed.
| Level | Proof | Intended capabilities |
|---|---|---|
| A0 | PlayerPal ID and password only | Sign in, add a stronger credential, connect a partner; no redemption or transfers |
| A1 | Passkey or approved social sign-in | Normal access |
| A2 | A1 plus a confirmed partner relationship | Earning from that partner and standard redemption |
| A3 | Several independent trusted proofs | Higher-value actions where policy permits |
A0 and A1 are recorded at sign-in today. The checks on economic actions arrive with redemption, which is Planned. Accounts are never merged automatically on matching devices, network addresses or behaviour.
Safe retries
AvailableEvery write that partners and players send can be retried safely. Activity
batches and fact ingest are deduplicated by batch and event ID; an identical
retry returns the original receipt, and a different payload under the same ID
is rejected as a conflict. Player account changes take an Idempotency-Key.
Points are credited at most once per event and campaign rule. See
Idempotency and errors.
Data minimisation
AvailablePlayerPal never receives a player's email, name or phone number, and partner facts must use an Alias PlayerPal issued; anything shaped like a direct identifier is rejected. Device information is limited to a display label, and network addresses and device fingerprints are never used to identify or link players. See Privacy.
Separate portals by audience
AvailablePlayers, PlayerPal staff, operators, game providers and affiliates each use their own portal address, with its own sign-in client, session cookie and permission policy. There is no role switcher: opening the wrong portal returns an access error. Sessions are never shared between audiences.
The player portal uses production sign-in. Sign-in for the partner and staff portals is In development, and single sign-on for PlayerPal's workforce and partner staff is Planned.