Catalog and categories
Confirm the required content, categories and initial scope, as well as how applicable materials are provided.
Slots API / Integration scope
Confirm the scope of Slots content integration first.
For teams evaluating Slots API or casino games API integration, this page frames the game catalog, game launch, wallet collaboration and record-reconciliation topics around the current platform architecture.
Public integration map
Establish a shared vocabulary from the catalog to game launch.
The public technical reference provides the V5.0.0 endpoint catalog, signing method, representative fields and redacted examples. The real base URL, credentials, complete field constraints, final callback list and production configuration remain within controlled technical processes.
Game launch
Discuss each system's responsibilities for sessions, game launch and return paths without publishing sensitive fields.
Wallet collaboration
Evaluate a single or transfer wallet against the existing architecture, then clarify exception and reconciliation responsibilities.
Record reconciliation
Include transaction, round or operating-record reconciliation in the testing and issue-escalation scope.
Wallet models
There is no "best wallet model" outside a platform architecture.
Wallet choice affects balance collaboration, exception handling, reconciliation paths and responsibilities. Confirm it during the technical review.
Comparison pointSingle (seamless) walletTransfer wallet
Balance collaborationThe platform retains unified balance management; the real-time collaboration scope must be confirmed.Involves transfers in, transfers out and a supplier-side balance; the process needs separate confirmation.
Testing focusCallbacks, exceptions, duplicate requests and balance consistency.Transfer status, balance reconciliation, failure recovery and record consistency.
Fit assessmentDepends on the existing wallet and callback capabilities.Depends on existing transfer and reconciliation paths.
Before technical review
Use a checklist to shorten early technical discussions.
First clarify platform conditions and procurement goals. Complete API materials can then enter controlled discussions according to the applicable scope.
What the buyer should prepare
- Current platform architecture and wallet-collaboration model
- Desired content scope and initial integration priorities
- Language, currency, return-path and target-market requirements
- Requirements for security, exceptions, reconciliation and testing
What to clarify during the project
- Available catalog and technical-material scope
- Integration responsibilities, test planning and issue escalation
- Conditions for providing environments, accounts and materials
- Content, market and commercial boundaries
Test the whole path
Testing is about more than whether a game opens.
Scope consistency
The catalog, configuration and project scope already confirmed by both sides remain consistent.
Launch and return
Game launch, sessions and return paths follow the agreement, and exception scenarios can be identified.
Wallets and exceptions
Balance collaboration, duplicate requests, failure handling and responsibility assignment have clear criteria.
Records and escalation
Both sides can actually carry out record reconciliation, issue feedback and escalation.
API questions
Common questions in technical procurement.
Are materials available for single and transfer wallets?
Current business materials cover both wallet-integration topics. The specific fit must be confirmed against the platform architecture and project scope.
Can the complete API documentation be downloaded publicly?
The website publishes the endpoint catalog, signing method, representative fields and redacted examples, but this is not the complete production protocol. The real base URL, credentials, complete field constraints, final callback list and production configuration are provided as needed after project confirmation.
Is integration without changes guaranteed for an existing platform?
No. Compatibility scope, wallet collaboration, exception paths and testing items need technical confirmation first.
Are specific languages, currencies or markets supported?
These are project-scope confirmation items and are not subject to a universal commitment on a public page.