You do not need to wait for a sales conversation to start exploring Waija’s casino game API. Register in the backoffice for instant account and API testing access with $10 test credit. That gives your team a starting point for a real integration test, rather than a promise that a production casino is ready to run.
The most useful first session is small. Pick a few questions you want the API to answer and keep a record of what you tried. You can then separate working connections from missing configuration or decisions your team still needs to make.
Get the connection ready
Open backoffice Settings to retrieve your configured API Base URL. Generate api_login and api_password, whitelist the server IPs you will use and configure your callback URL. Keep credentials on the operator backend, not in a browser page or player-facing application.
Method requests use POST with JSON to that configured base URL. Avoid copying an endpoint from an illustration or assuming a generic Bearer-token example is the Waija protocol. The current setup documentation is the reference for the required fields.
Explore the games your account can retrieve
Use getGameList for the selected currency. Inspect the returned games and the id_hash values your launch requests will use. Choose a small test set that reflects the game categories you intend to offer.
This is also a chance to plan your lobby. Decide how you will refresh game information and connect a player’s selection to the correct game identifier. A game appearing in a list is not a substitute for checking provider and market suitability for your business before production.
Try a launch with a test player
For a real-money player/session flow, call createPlayer before getGame, even when the player may already exist. getGame returns a launch URL and session_id. Your frontend opens the returned URL in an iframe or a new window.
For demo play, use getGameDemo instead. Keep demo tests and wallet-connected tests distinct in your notes: they answer different questions. Record which game you selected, the request result and whether the frontend opened the returned URL correctly.
Check the wallet, not just the screen
Your operator platform owns the wallet. Waija requests balance at session start, then sends debit and credit callbacks during play to your configured URL. Your backend processes them and returns the documented JSON error and balance response with HTTP 200. Balances are in integer cents.
Read the balance and debit/credit rules before testing transactions. Credit can arrive without a preceding debit, so do not make a strict debit-then-credit order a wallet assumption. Preserve call_id and follow the documented validation and transaction rules.
Decide what to do next
A useful first test ends with evidence: a retrieved game list, a launch result and wallet checks your team understands. Note failed requests and unanswered questions too. Before production, review your integration, available games, business requirements and current usage terms.
See the aggregation overview and real API flow when you need to explain the connection to the rest of your team. Instant access removes the wait to start testing; your team still builds and validates the platform connection.