The short answer

Do not evaluate a Slots API provider only by its demo, game count or “one API” message. A more reliable process asks for verifiable, traceable and scope-specific evidence in eight areas: catalog provenance, version change, wallet boundaries, exception handling, record reconciliation, test acceptance, operational support, and whether a specific game and version can be used in the target market.

Missing evidence does not necessarily make a provider unsuitable. It does mean that a buyer should not turn a marketing claim into a production fact. When material has not been supplied or verified, the accurate status is pending verification, not “passed by default.”

Eight evidence areas for procurement

Evidence area Minimum material to request Follow-up question Common warning sign
1. Catalog and rights scope Dated catalog snapshot, provider and game IDs, status fields, asset-use scope and source notes Are display, staging, commercial and production scopes the same? Who updates the catalog? Only a total count; no snapshot date; demo visibility is treated as commercial availability
2. Version and change management API or game version records, changelog, deprecation conditions, notice process and owners How are breaking changes detected? Under what conditions does an old version remain available? Current documentation has no version, changelog or affected scope
3. Wallet and integration fit Wallet-model description, balance and record boundaries, stable identifiers, flow diagram and responsibility matrix Who holds the authoritative ledger in each wallet model? What must the platform adapt? The two wallet models are presented as equivalent; zero platform change is promised
4. Exceptions and consistency Principles for timeouts, duplicates, disconnections, partial success and unknown states After a timeout, how is the final result established? Which operations are safe to retry? HTTP success is treated as business success; unlimited retries replace state checks
5. Records, reconciliation and audit Stable business IDs, query or export scope, reconciliation fields, discrepancy workflow and retention scope Can a request be followed through transaction, round and balance movement? Who closes a discrepancy? Only a final balance is visible; requests, transactions and rounds cannot be correlated
6. Testing and acceptance Defined staging scope, test cases, pass criteria, defect records and sign-off evidence Beyond opening a game, were wallet, exception, record and permission paths tested? Only the happy path is shown; no failed-case evidence, candidate version or approver
7. Operational support and ownership Contact paths, incident escalation, change notifications, responsibility boundaries and contract schedules Who responds first to financial or state discrepancies, provides evidence and decides next action? There is only a sales contact; engineering, operations and commercial duties are interchangeable
8. Market applicability Mapping between target market, game, version, certification or test report, and scope Does technical integration prove this version may launch in the target market? Is the evidence current? A logo or certificate screenshot has no entity, version, market, date or scope

1. Catalog: verify identity before quantity

Catalog evidence should identify the provider, stable game code, status, snapshot date and permitted material-use scope for each game. A headline total without deduplication rules, status definitions and an update date does not support a procurement decision on its own.

Record “visible in a demo,” “available in staging,” “commercial scope confirmed” and “verified for the target market” separately. They may overlap, but they are not synonyms.

2. Version management: determine how future changes are handled

Buyers should review the API version, changelog, deprecation conditions, impact assessment and notification ownership—not only the current documentation. For content, confirm whether catalog, game-version and market-applicability changes use the same governance path or separate ones.

Without explicit evidence, do not infer a fixed compatibility period or disruption-free upgrade.

3. Wallet model: compare responsibilities, not labels

A single wallet generally keeps real-time accounting on the platform side. A transfer wallet generally moves funds between platform and game-side wallets. The important questions are which ledger is authoritative, how requests correlate with balance changes, how the final state is established after failure and what the existing platform must change.

Product pages describe both models, but the model, fields and adaptations for a specific project still depend on its platform architecture.

4. Exception handling: the provider must explain an unknown state

A timeout or dropped connection shows only that the caller did not receive a complete result. It does not prove that the server did nothing. The provider should explain error classification, business-result semantics, stable identifiers, query or reconciliation paths, and which requests are safe to retry. Algorithms and retry parameters belong in the integration agreement, not inferences from a marketing page.

5. Records and reconciliation: trace intent to final effect

Useful record evidence lets both parties correlate a request with a transaction, round, amount, currency and final state. Query range, retention, export, time zone and discrepancy escalation also need clear scope. A balance screenshot is usually not enough to establish whether an uncertain operation posted once, posted twice or remains unresolved.

6. Testing and acceptance: a successful demo is not production acceptance

Evidence should cover the agreed catalog, launch and return flow, wallet happy path, exception paths, record lookup, reconciliation and permissions. Preserve the candidate version, environment, cases, results, defects and approvers. See the staging-to-production acceptance checklist for a detailed framework.

7. Operational support: turn “someone is available” into ownership

The provider should identify who receives technical incidents, catalog issues, financial discrepancies, security events and commercial-scope questions; what evidence is needed for escalation; and how changes are communicated. Response targets, availability and remedies exist only when formally agreed. This article does not replace a contract or SLA.

8. Market applicability: maintain a traceable matrix

A market conclusion should be recorded against the combination of market × game × version × certification or test evidence, including entity, source, date and scope. Official materials such as the UK Gambling Commission’s remote technical standards and testing strategy illustrate the types of evidence a target market may require. They do not verify any particular supplier, game or version.

Technical connectivity, a playable demo or a standalone certificate image does not establish permission to use a product in every market.

A practical conclusion format

Use three outcomes for each evidence area rather than hiding critical gaps inside a total score:

  • Verified: source, date, scope and owner are recorded and match the target project.
  • Conditionally accepted: some evidence exists, but an explicit verification or contractual condition remains before launch.
  • Pending verification: evidence is missing, cannot be traced or consists only of a claim without scope.

Any pending item involving financial consistency, production access, target-market applicability or a critical responsibility boundary should become a production blocker. It should not be offset by high scores elsewhere.

What can currently be evaluated on this site

  • The public API reference lists 17 endpoints across games, sessions, wallets and records.
  • Examples describe single- and transfer-wallet directions and show request, transaction and round identifiers that can support traceability discussions.
  • The integration process separates discovery, technical scope, test acceptance and pre-production coordination.
  • Public pages support early evaluation. Actual interfaces, environments and production acceptance remain governed by project documentation agreed by both parties.

Boundaries to keep in mind

  • The catalog does not prove that every listed game is commercially authorized, continuously available or suitable for a target market.
  • The current API version, endpoint count and fields are not promised to remain unchanged indefinitely.
  • No platform is promised a zero-change integration, fixed launch date, fixed performance, SLA or absolute security.
  • Staging, demos and public documentation are not production-admission evidence.
  • This framework does not replace legal, regulatory, contractual, security or production engineering review.

FAQ

Does a larger game count mean a better provider?

Not necessarily. A count needs deduplication rules, statuses, an update date, commercial scope and target-market applicability. A smaller, traceable catalog may be more useful than a large number with no verifiable source or status.

Is a game opening in a demo enough to prove readiness?

No. A demo proves that one controlled path was accessible at that time. It does not establish wallet behavior, exceptions, reconciliation, production permission, commercial rights or target-market applicability.

Should buyers request files behind a certification badge?

Yes. At minimum, verify the certified entity, game, version, market, issuing or testing body, date, status, scope and traceable source. A standalone badge cannot populate an applicability matrix.

Must all eight areas be completed at once?

Due diligence can be phased, but every gap needs an owner, completion condition and blocker classification before production. Unknowns involving financial consistency, production access or market applicability cannot be assumed to pass.

To evaluate a specific project, use the “Contact us” section to provide the target market, wallet model, current platform boundary and evidence areas to verify. AG can then describe next steps against confirmed materials without promising production admission or a launch date in advance.

Sources and scope

For product scope, see the Slots API overview, integration process and public API reference.

Market-evidence examples use the UK Gambling Commission’s Remote Gambling and Software Technical Standards and Testing Strategy. These official sources illustrate a verification method; they do not confirm that AG or any game is available in the UK or another market.

API versions, catalog status, market evidence and contact processes still require review by the responsible technical, commercial, operational and compliance owners.

Need to turn this guidance into a project plan?

This article supports project evaluation and does not replace technical, contractual, certification or local-law confirmation.

Contact us