urlscan.io logo urlscan.io
SecurityTrails logo

operator.fizzybubbly.com Open in urlscan Pro
2606:4700:10::6816:4f46  Public Scan

Back to summary
URL: https://operator.fizzybubbly.com/
Submission: On May 21 via api from US — Scanned from DE

Form analysis 1 forms found in the DOM

POST https://operator.fizzybubbly.com/search.json

<form class="simple_form doc-search__form" data-action="ajax:success->doc-search#onPostSuccess ajax:error->doc-search#onPostError ajax:beforeSend->doc-search#onBeforeSend" data-doc-search-target="form"
  action="https://operator.fizzybubbly.com/search.json" accept-charset="UTF-8" data-remote="true" method="post">
  <svg width="14" height="14" viewBox="0 0 14 14" fill="none" xmlns="http://www.w3.org/2000/svg" data-doc-search-target="searchIcon">
    <path d="M13 13L10 10" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"></path>
    <path d="M6.14286 11.2857C8.98318 11.2857 11.2857 8.98318 11.2857 6.14286C11.2857 3.30254 8.98318 1 6.14286 1C3.30254 1 1 3.30254 1 6.14286C1 8.98318 3.30254 11.2857 6.14286 11.2857Z" stroke="currentColor" stroke-width="1.5"
      stroke-linecap="round" stroke-linejoin="round"></path>
  </svg>
  <div class="loader doc-search__loader" aria-label="Loading" aria-live="assertive" aria-hidden="true" data-loader-type="bars" data-doc-search-target="loader"></div>
  <input label="false" autocomplete="off" type="hidden" name="uid" id="uid" value="0.d7e5bd9f699cd">
  <input label="false" autocomplete="off" autofocus="autofocus" data-doc-search-target="input" data-action="input->doc-search#submitOnType" class="string required" required="required" aria-required="true" placeholder="Search" type="text" name="query"
    id="query">
  <button type="button" class="esc-button" data-action="click->dialog#close">ESC</button>
</form>

Text Content

Show Menu
Search… Ctrl+K

ESC





Example searches: “400”, “cashAmount”, “isGameRoundFinished”, “description”,
“amount”


Toggle dark mode

--------------------------------------------------------------------------------

 * API Changelog

--------------------------------------------------------------------------------

Download source
 * JSON OpenAPI specification
 * YAML OpenAPI specification


TOPICS

 * Introduction


ENDPOINTS

 * Wallet
   * Fetch user balance
     POST
   * Deposit
     POST
   * Rollback a withdraw request
     POST
   * Withdraw
     POST
 * Games
   * Game list
     POST
   * Get game round replay
     POST
   * Generate a game launch URL
     POST
 * Free spins
   * Get available bet values for game
     POST
   * Cancel a free spins campaign
     POST
   * Create a free spins campaign
     POST
   * Get details of a campaign
     POST
   * Get details of a player campaign state
     POST
 * History
   * Fetch transactions
     GET
   * Fetch transaction
     GET
 * Jackpots
   * Get active jackpots
     POST
 * Free spins (Callback)
   * Free Spins Campaign Status Update
     POST

Powered by Bump.sh
Dismiss highlight Show more

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------



--------------------------------------------------------------------------------




--------------------------------------------------------------------------------


FIZZY BUBBLY OPERATOR API
1.0.0

This document describes the process of integrating with the Fizzy Bubbly system.

 * Wallet API: API implemented by the operator
 * Games API: API implemented by Fizzy Bubbly
 * History API: API implemented by Fizzy Bubbly
 * Free spins API: API implemented by Fizzy Bubbly
 * Jackpot API: API implemented by Fizzy Bubbly

TERMS AND ABBREVIATIONS

Term Description Fizzy Bubbly Games provider Operator Operator Brand Operator
site or sub-site Staging Environment where integration is tested Private key
Secret key to generate HMAC_SHA256 hash Public key Plain text API key

OUTLINE OF THE INTEGRATION FLOW

 1. Fizzy Bubbly provides operator
    
    * Endpoint for Games API
    * Public key
    * Private key
    * Outgoing IP addresses for whitelisting

 2. Operator implements Wallet API and provides Fizzy Bubbly:
    
    * Endpoint for Wallet API
    * Testing environment details (site, test users)
    * Configuration details (max exposure, enabled currencies per brand)
    * Outgoing IP addresses for staging environment

 3. Fizzy Bubbly and operator perform testing and sign-off in staging
    environment

 4. Ready for production deployment

AUTHENTICATION

Authentication is handled via public api key and request signing.

Every request must contain two HTTP Headers:

Public-Key: Public key provided by Fizzy Bubbly

Signature: Signature computed using private key provided by Fizzy Bubbly. See
Request signing for more details.

REQUEST SIGNING

Request signing is used to ensure that the request is coming from the operator
and that the request has not been tampered with. The signature is computed using
the HMAC_SHA256 algorithm. Signature generation is required for all requests to
the Fizzy Bubbly API and the signing algorithm is identical for all endpoints.
Signature validation is required for all requests to the Wallet API. Information
to generate the request signature:

 * Request body. This must be a raw HTTP request body bytes.
 * HTTP Method. The uppercase HTTP method of the request e.g. POST.
 * HTTP URI. The full URI of the request including scheme, host, port, path and
   query parameters if any e.g. https://api.casino.com/n2/wallet/balance.
 * Private Key. The secret API key provided by Fizzy Bubbly.

Signature must be computed on the raw HTTP request body bytes. This means that
the request object should be serialized into bytes first and then the signature
should be computed.

Pseudo-code to generate the signature:

  String md5 = MD5.generate(requestBody).toUpperCase();
  String toSign = String.format("%s\n%s\n%s", httpMethod, httpUri, md5);
  String signature = HMAC_SHA256.generate(toSign, privateKey);


Test-case for generating signature:

Private key: XmsbLjUNrT4Ktj5YCBFdXvrR3EA6dMpB
Method: POST
Uri: https://api.casino.com/n2/wallet/balance
Body: {"sessionId":"HyvN1Sd2Pm3LAAzd9HV5","playerId":"b2996ddb9a51","currency":"EUR"}

MD5 of body:
E3760D425889FB7F9DF770FEEFF2018C

toSign:
POST
https://api.casino.com/n2/wallet/balance
E3760D425889FB7F9DF770FEEFF2018C

Expected signature:
1fa24ceaff03a97aff58c23d5a41b72a6c24c2abe20dcfb41a03c5e4c9bd939c


REQUEST IDEMPOTENCY

Wallet API withdraw, deposit and rollback requests must be idempotent. All these
requests have a field transactionId. Requests with same transactionId must be
processed only once and in case of retries the original response is expected.

SESSION HANDLING

Validation of the active session is required for all withdraw requests. Deposit
and rollback requests must be accepted without having an open session to ensure
reconciliation.

RETRY

The default behaviour for retries is following:

 * withdraw: Errors are not retried, rollback will be called.
 * deposit, rollback: Requests are first retried 3 times with 1500ms delay,
   after that requests are retried with exponentially increasing intervals until
   successful response is received.

FREE SPINS CAMPAIGNS

Free spins campaigns are managed via separate API. See Free spins API for more
details. There are two modes of free spins handling:

 * Transaction per free spin mode. In this mode every free spin is sent as a
   separate transaction for both bets and wins. This is the default mode.
 * Aggregation mode. In this mode only final deposit with the total win amount
   will be sent. Total win amount is calculated as a sum of all free spins wins.
   Free spins that were not consumed by a player on time (before consumeBefore)
   will be voided and not sent to the operator. The free spins mode has to be
   agreed with Fizzy Bubbly before the integration starts.

There are two fields related to free spins in the transaction request:

 * freeSpinsCampaignId - Id of the free spins campaign that the transaction
   relates to.
 * isFreeSpinsConsumed - Flag to indicate if the free spins are consumed and no
   more free spins are expected for the campaign. This flag will only be sent
   for the final DEPOSIT transaction.

ERROR HANDLING

Errors are handled via HTTP status codes and custom error codes. All requests
with HTTP status code 200 OK are expected to be handled successfully. All other
HTTP status codes are expected to have body with following structure:

{
    "code": "{Error Code}",
    "message": "{Message to describe the error in more detail}",
    "traceId": "Internal id to track the request-response"
}


Error Code Description ERROR_UNKNOWN_ERROR General error codes for errors
without specific code ERROR_BAD_REQUEST Request body is invalid
ERROR_BAD_REQUEST_PLAYER_BLOCKED Player is blocked ERROR_INVALID_PUBLIC_KEY
Request public key header is invalid ERROR_INVALID_SIGNATURE Request signature
is invalid ERROR_INVALID_SESSION Invalid session id is provided
ERROR_SESSION_EXPIRED Session has expired ERROR_TIMEOUT Handling the request
took too long time ERROR_TRANSACTION_DUPLICATE Duplicate transaction id was
provided with new parameters (amount, currency, gameRoundId, playerId
ERROR_TRANSACTION_WITHDRAW_NOT_FOUND Withdraw transaction not found for deposit
request ERROR_TRANSACTION_INSUFFICIENT_FUNDS User wallet has insufficient fund
for a withdraw request ERROR_TRANSACTION_LIMIT_EXCEEDED Player has exceeded any
kind of playing limit ERROR_ROLLBACK_TRANSACTION_NOT_FOUND Withdraw transaction
not found for rollback request. If such rollback was sent, further withdraw
requests with the same transactionId (originalTransactionId in rollback request)
are expected to be declined with ERROR_BAD_REQUEST error code.
ERROR_GAME_NOT_ACTIVE Problem with finding an active game. Message will contain
an exact reason, why the game could not be fetched

GAME CLIENT COMMUNICATION

Game client API is an HTML wrapper that embeds a game client into iframe and
acts as a middleware to facilitate in-browser communication between the game
client and a casino web page to provide better game experience. Communication is
handled via Window object. See
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage for more
details.

Support of client communication events can be different based on the game
provider. Please confirm with us before using the supported events. Game client
communication is an optional feature and will be enabled only when requested.

GAME CLIENT EXPOSED MESSAGES

All game client exposed messages have the following structure:

{
    "messageType": "{messageType}",
    "payload": {}
}


Message Type Description Payload n2.pr.balanceUpdated In-game balance has
changed. { "balance": 100.00 }

GAME CLIENT CONSUMED MESSAGES

All game client consumed messages have the following structure:

{
    "messageType": "{messageType}",
    "payload": {}
}


Message Type Description Payload n2.op.pingBalance Notify game to fetch new
balance from the wallet. {} n2.op.stopAutoPlay Stop game auto-play. {}

This is the documentation for version 1.0.0 of the API. Last update on May 21,
2024.

Base URL

BASE_URL