Skip to main content

GAP Casino API — Introduction

Source: https://docs.dreamdelhi.com/ DEV base URL: https://dev-api.dreamdelhi.com

Document Overview​

This document describes an integrated system which enables the GAP backend to integrate with online operators. It includes integrating new game providers, financial transactions, login calls and launch protocols used.

Integration Overview​

This GAP Casino is a B2B system which allows shops and online operators to offer games to their clients through their existing systems. A simple call to "open game" will generate the GAP casino system start up by activating the operator to open a game or Lobby. Once open, the user may navigate freely throughout the Casino system and play any game while tracking his balance. Four simple API calls allow the casino to credit and debit the player's account in real time using seamless wallet integration. All the financial calls are monitored and managed by the GAP casino system to ensure no financial transaction is lost.

Protocol​

The integration uses Http's POST communications based on Json message type. The operator must use HTTPS to communicate with our server, but we need to configure it in advance.

Security​

We are having multiple level of security checks:

  • IP White Listing: Operator and GAP must whitelist the other entity IPs on their servers and receive any kind of requests over these configured IPs only and rest of the messages/requests will be rejected/discarded.

  • Signature Check based on the RSA Key shared between GAP and operator: Operator and GAP will generate private and public key pair respectively and public key will be shared to other entity. Message/Request will be signed with the private key generated and sent to other entity and the same message will be verified with the public key received (by offline) and will decode the message.

  • HTTP over secure

Requirements​

Things required from operator side for integration​

  • All Games API requests have to be signed by Operator.
  • Operator server ip - All requests to originate from this ip to us, not from client side
  • Operator server endpoint url - This is where GAP shall send requests for balance/debit/credit/rollback
  • Operator's public key which was generated for signing and verification purpose

Things GAP shall provide​

  • All Wallet API requests have to be signed by GAP.
  • All Wallet API request must be practiced and verified by the Operator.
  • GAP server url – production url
  • GAP server endpoint url - This is where operator shall send requests for initial session login, getgames, etc…
  • GAP public key - After Operator shares their key

Confirmed Operational Details (from GAP team, March 2026)​

Currency​

  • Fiat currencies only: INR, BDT, AED, HKD, etc. Custom codes like "PTS" or "FP" are NOT supported.
  • Multiple fiat currencies are supported per operator.
  • Currency can be changed later (not locked at onboarding).
  • For points-based systems: use a real fiat currency (e.g., HKD) with a conversion rate on the operator side.

Token Lifecycle​

  • Session tokens expire after 6 hours.
  • Rollback/refund requests come only from the game provider, NOT from GAP directly.
  • User active state is NOT considered for token expiry — it's a hard 6-hour window.

Balance​

  • Balance is fetched real-time via the /balance endpoint on every relevant action — NOT cached from the login call.
  • The balance field sent at login is the initial balance, but GAP will call /balance for the authoritative value during gameplay.
  • Exception: Some providers (e.g., JiLi) need the login balance to be accurate. Do NOT send stale values.

Timeouts & Retries​

  • 4-second timeout on all wallet endpoint calls from GAP.
  • /balance: No retry on failure.
  • /betrequest: No retry. If timeout → bet is considered FAILED by GAP.
  • /resultrequest: 10 retries on failure.
  • /rollbackrequest: 10 retries on failure.

Sessions​

  • Single session only per user. Multi-session is NOT supported.
  • No token refresh — user must re-login for a new session after 6hr expiry.
  • No session end notification — GAP does NOT callback when session ends.

Min/Max Bets​

  • Min/Max bet limits are configured at the global operator level only (via BackOffice during operator creation).
  • There is NO per-game or per-provider min/max configuration.

Sports rate Parameter​

  • The rate field visible in GAP sports configuration is internal to GAP's sports module and does NOT apply to casino integration.

Request Signing and Verification​

  • Before the integration, the Operator generates a private/public key pair, and provides the public key to GAP.
  • Both parties should verify all requests will be signed with RSA-SHA256.
  • The integration transmit formation is Json. And is encoded by UTF-8.
  • The Operator generates a private/public key pair and sends the public key to GAP.
  • Similarly GAP sends its public key to the Operator.
  • The body of all requests will be signed with RSA-SHA256 using the respective private key and encoded to BASE64.
  • The signature will be placed in the "Signature" header.
  • The Operator needs to verify all Wallet API requests using the public key provided by GAP.
  • GAP verifies all Games API requests using the public key provided by the Operator.