RGCP API Documentation

Technical integration guide for state-mandated responsible gaming enforcement

API Overview

The RGCP API enables real-time enforcement of player-defined limits across all licensed operators. Every check-confirm cycle creates an immutable audit trail while ensuring sub-100ms response times.

🔒

Security First

mTLS required, OAuth2 client credentials, strict operator allowlisting, and certificate-based authentication

⚡

High Performance

Sub-100ms response time target, 99.99% uptime SLA, regional endpoints for low latency

🔄

Check-Confirm Pattern

Two-phase enforcement prevents operators from checking limits without reporting outcomes

📊

Complete Audit Trail

Every transaction logged with idempotency keys, globally unique IDs, and timestamp verification

Core Integration Flows

Flow 1: Login Gate (Pre-Play Enforcement)

User enters credentials at operator site

Operator authenticates user and resolves identity via IdP/KYC

Operator calls POST /v1/check/login with playerRef, state, operatorId, sessionId

RGCP returns decision: ALLOW RESTRICT DENY

Operator enforces decision before showing games or accepting deposits

POST/v1/check/login

Purpose: Validate player status before allowing access to gaming platform

Request:

{
  "playerRef": "STATE_ABC_12345",
  "state": "NJ",
  "operatorId": "OP_CASINO_001",
  "sessionId": "sess_abc123def456",
  "timestamp": "2026-01-20T18:03:12Z",
  "idempotencyKey": "login_uuid_unique"
}

Response:

{
  "decision": "ALLOW",
  "effectiveAt": "2026-01-20T18:03:12Z",
  "reasons": [],
  "limits": {
    "depositDaily": 500,
    "wagerDaily": 1000,
    "timeDailyMinutes": 60
  },
  "remaining": {
    "depositDaily": 500,
    "wagerDaily": 1000,
    "timeDailySeconds": 3600
  },
  "requiredActions": []
}

Flow 2: Deposit Enforcement

User initiates deposit of $X

Operator calls POST /v1/check/deposit with amount and transaction ID

RGCP checks deposit limits and returns decision

If ALLOW: Operator processes payment through payment processor

Operator calls POST /v1/confirm/deposit with outcome (SUCCESS or DENIED_BY_RGCP)

RGCP acknowledges and updates player limits

POST/v1/check/deposit

Purpose: Validate deposit against player limits before processing payment

Request:

{
  "playerRef": "STATE_ABC_12345",
  "operatorId": "OP_CASINO_001",
  "amount": 100.00,
  "currency": "USD",
  "sessionId": "sess_abc123def456",
  "txnId": "dep_txn_789xyz",
  "timestamp": "2026-01-20T18:05:00Z",
  "idempotencyKey": "deposit_uuid_unique"
}

Response:

{
  "decision": "ALLOW",
  "effectiveAt": "2026-01-20T18:05:00Z",
  "reasons": [],
  "remaining": {
    "depositDaily": 400,
    "depositWeekly": 1800,
    "depositMonthly": 7500
  },
  "requiredActions": []
}

POST/v1/confirm/deposit

Purpose: Report outcome of deposit attempt (creates audit trail)

Request:

{
  "txnId": "dep_txn_789xyz",
  "result": "SUCCESS",
  "providerTxnId": "PAY_PROVIDER_123",
  "actualAmount": 100.00,
  "timestamp": "2026-01-20T18:05:15Z",
  "idempotencyKey": "confirm_deposit_uuid"
}

Flow 3: Wager/Bet Placement

User places wager of $X

Operator calls POST /v1/check/wager with stake amount and game type

RGCP checks wager and loss limits, returns decision

If ALLOW: Operator submits wager to game engine

Game engine returns outcome (win/loss)

Operator calls POST /v1/confirm/wager with stake, outcome, and net result

POST/v1/check/wager

Purpose: Validate wager against stake and loss limits

Request:

{
  "playerRef": "STATE_ABC_12345",
  "operatorId": "OP_CASINO_001",
  "stakeAmount": 25.00,
  "gameType": "SLOTS",
  "sessionId": "sess_abc123def456",
  "wagerId": "wager_abc_001",
  "timestamp": "2026-01-20T18:10:00Z",
  "idempotencyKey": "wager_uuid_unique"
}

Response:

{
  "decision": "ALLOW",
  "effectiveAt": "2026-01-20T18:10:00Z",
  "reasons": [],
  "remaining": {
    "wagerDaily": 975,
    "lossDaily": 250
  },
  "requiredActions": []
}

POST/v1/confirm/wager

Purpose: Report wager outcome and update loss tracking

Request:

{
  "wagerId": "wager_abc_001",
  "stake": 25.00,
  "outcome": "LOSS",
  "net": -25.00,
  "timestamp": "2026-01-20T18:10:05Z",
  "idempotencyKey": "confirm_wager_uuid"
}

Flow 4: Time-of-Play Enforcement (Heartbeat)

Operator calls POST /v1/session/heartbeat every 60 seconds during active session

RGCP calculates elapsed time and checks against time limits

RGCP returns: CONTINUE WARN STOP

If STOP: Operator calls POST /v1/session/end and forces logout

POST/v1/session/heartbeat

Purpose: Update session time and receive continuation instructions

Request:

{
  "playerRef": "STATE_ABC_12345",
  "operatorId": "OP_CASINO_001",
  "sessionId": "sess_abc123def456",
  "elapsedSec": 1800,
  "timestamp": "2026-01-20T18:33:12Z",
  "idempotencyKey": "heartbeat_uuid"
}

Response:

{
  "decision": "CONTINUE",
  "remainingTimeSec": 1800,
  "reasons": [],
  "requiredActions": []
}

Complete API Endpoint Reference

Identity & Player Mapping

POST/v1/players/resolve

Purpose: Map operator identity to state canonical playerRef

Converts operator-specific player identifiers plus KYC claims into state-managed playerRef

Enforcement Checks (Pre-Action)

POST /v1/check/login

Validate player status before granting platform access

POST /v1/check/deposit

Check deposit limits before processing payment

POST /v1/check/wager

Validate wager and loss limits before bet placement

POST /v1/check/withdrawal

Optional: Check withdrawal patterns for fraud prevention

Confirmations (Post-Action)

POST /v1/confirm/deposit

Report deposit outcome and update limits

POST /v1/confirm/wager

Report wager outcome and loss tracking

POST /v1/confirm/session

Optional: Aggregated session confirmation

Session Control

POST /v1/session/start

Initialize new gaming session

POST /v1/session/heartbeat

Update session time and get continuation signal

POST /v1/session/end

Close session and finalize activity

Limits & Player Status (State Side)

GET /v1/players/{playerRef}/limits

Retrieve current player limits and exclusions

PUT /v1/players/{playerRef}/limits

Update player limits (state portal only)

POST /v1/players/{playerRef}/exclude

Activate self-exclusion

POST /v1/players/{playerRef}/cooling-off

Initiate cooling-off period

Compliance & Audit (Operators)

GET /v1/operators/{operatorId}/audit-export

Export compliance data for regulatory review

GET /v1/operators/{operatorId}/noncompliance-events

Retrieve flagged violations or integration issues

Decision Object Standard

All check endpoints return a consistent decision structure:

{
  "decision": "ALLOW | RESTRICT | DENY",
  "effectiveAt": "2026-01-20T18:03:12Z",
  "reasons": ["COOLING_OFF_ACTIVE", "TIME_LIMIT_EXCEEDED"],
  "limits": {
    "depositDaily": 500,
    "depositWeekly": 2000,
    "depositMonthly": 8000,
    "wagerDaily": 1000,
    "lossDaily": 300,
    "timeDailyMinutes": 60
  },
  "remaining": {
    "depositDaily": 120,
    "depositWeekly": 450,
    "depositMonthly": 3200,
    "wagerDaily": 450,
    "lossDaily": 150,
    "timeDailySeconds": 900
  },
  "requiredActions": [
    {"type": "MAX_STAKE", "value": 25},
    {"type": "DISABLE_DEPOSITS", "value": true},
    {"type": "SHOW_WARNING", "message": "You have 15 minutes remaining today"}
  ]
}

Decision Types

ALLOW

Player may proceed with requested action

No limits exceeded
No active exclusions or cooling-off periods
Operator should allow gameplay/deposit/wager

RESTRICT

Player may proceed with conditions

Partial limits apply (e.g., max stake reduction)
Warnings should be shown to player
Check requiredActions for specific restrictions
Deposits may be capped or disabled while wagering continues

DENY

Player must not proceed with action

Limit exceeded (deposit, wager, time, loss)
Active self-exclusion
Cooling-off period in effect
Operator must block action and inform player

Security & Reliability Requirements

Transport & Authentication

mTLS Required

Mutual TLS between operator and state RGCP. Operators must present valid certificates for authentication

OAuth2 Client Credentials

OAuth2 or signed JWT on top of mTLS for API authorization. Tokens expire and must be refreshed

Strict Allowlisting

Operators allowlisted by certificate and operatorId. Unauthorized access blocked at network layer

Data Integrity

Idempotency Keys

Every check/confirm must include unique idempotencyKey to prevent double counting and enable safe retries

Globally Unique IDs

txnId, wagerId, and sessionId must be globally unique per operator for audit trail

Timestamp Verification

All requests timestamped. Requests older than 5 minutes rejected to prevent replay attacks

Availability & Failover

Fail-Closed Policy (Conservative)

If RGCP is unreachable, operator denies all actions

Maximum consumer protection
Prevents limit bypass during outage
May impact player experience
Recommended for high-risk jurisdictions

Fail-Safe Policy (Practical)

If RGCP unreachable, operator allows limited play with strict caps

Operators cache last-known limits
Apply conservative caps (e.g., 50% of normal limits)
Mandatory reporting when RGCP returns
Balances availability with protection

Note: States configure failover policy. Operators must implement both modes and respect state configuration.

Integration Support

📚 Comprehensive Documentation

OpenAPI/Swagger specs, interactive API explorer, code samples in multiple languages

🧪 Sandbox Environment

Full-featured testing environment with mock player data and all scenarios

📦 SDKs Available

Official SDKs for Java, .NET, Node.js, Python, Ruby, PHP

🔔 Webhook Support

Optional webhooks for real-time limit updates and exclusion notifications

🛠️ Developer Portal

Self-service credential management, API key rotation, usage monitoring

👥 Integration Team

Dedicated support during integration, certification testing, go-live assistance

Ready to Integrate?

Get sandbox access, API credentials, and technical documentation

Request API Access