A successful first game launch is a clear milestone: your backend requests a session, Waija returns a launch URL and your frontend opens it for the player. Getting there is easier when you keep configuration, game selection and wallet behavior separate.
Start with instant API registration and $10 test credit. You can begin testing without a lengthy sales onboarding process. Production readiness is a later step, after your own integration and business checks.
First, confirm where requests go
Use the API Base URL shown in backoffice Settings. Generate your api_login and api_password, whitelist your server IPs and configure the operator callback URL. Your backend sends method requests as POST JSON. Keep credentials away from the frontend and out of screenshots, public logs and shared examples.
If a request fails, compare its configuration and fields with the setup documentation before changing the rest of the flow. A wrong base URL or missing configuration can look like a game-launch problem even before a game has been selected.
Choose a game identifier from the list
Call getGameList for the currency you are testing. Select an available game and retain its id_hash. That value becomes gameid in the launch request; do not use a display name or invent an identifier.
Your lobby should connect the visible title to the identifier it received. For the first test, make this mapping easy to inspect. Later you can build the catalog-refresh and presentation work around the same documented game data.
Create the player before requesting the game
The real-money flow calls createPlayer first. Do this even when you think the player already exists; the method handles playerExists internally. Then call getGame with the documented fields and selected gameid.
Keep the results from these two calls separate. If createPlayer did not complete as expected, investigate that response before treating getGame as the failing step. For a demo launch, follow getGameDemo rather than substituting the real-money sequence.
Open the URL Waija returns
The getGame response contains the launch URL and session_id. Your frontend opens that returned URL in an iframe or a new window. Do not construct a game URL from provider names or the lobby title.
Check the full player journey: select the title, request the launch, open the game and return to the lobby. Save enough non-sensitive test detail to connect the frontend result with the backend request. A visible game is useful evidence, but it is not the whole wallet test.
Make the callback path part of the test
At session start, Waija sends a GET balance request to your configured callback URL. During play, debit and credit callbacks reach the same operator-owned wallet connection. Your backend updates its records and returns JSON error and balance in integer cents with HTTP 200.
Credit is not always preceded by debit. Keep transaction validation, call_id handling and repeated-request behavior aligned with the wallet documentation. Compare wallet records with the activity you observed instead of relying only on the game screen.
Finish with a short launch record
Record the selected game, whether each API step succeeded, whether the launch URL opened and what happened to wallet balances. Keep credentials and personal player details out of shared notes. List remaining issues with a clear owner.
The Waija API flow gives your team a shared view of these steps. Once the first launch is understood, broaden the test set and review production requirements before taking the integration live.