The short answer
The hardest terminology problem in a Slots API project is rarely that nobody knows a term. It is that different teams use the same term for different objects. For example, “available” may mean listed in a catalog, connected in staging, enabled in production or verified for a target market. Stable definitions keep procurement questions, interface design, test evidence and production decisions tied to the same fact scope.
This page provides concise definitions that can be reused across the site. For complete selection, acceptance, reliability and market-verification methods, follow the topic guides rather than treating the glossary as an implementation tutorial.
Core roles and catalog concepts
| Term | Concise definition | What it does not establish |
|---|---|---|
| Provider / game provider | A party that supplies game content, game services or related interfaces. | That AG holds distribution rights, or that the content is available in a particular market. |
| Aggregator | An integration layer that normalizes or coordinates access between a platform and multiple providers. | That provider differences, commercial terms, certification or market review disappear. |
| Platform | A business system that manages player accounts, wallets, operations or front-end experience. | That it is the provider, RGS or legally responsible operator in a particular jurisdiction. |
| Operator / operating entity | The entity responsible for operations within a specified project or market scope; its precise meaning depends on the contract and jurisdiction. | That connecting an API grants operating authorization. |
| RGS / Remote Game Server | A system component that hosts or coordinates remote game operation, state and related transaction interactions. | That it is the aggregator, or that similarly named systems have the same certification scope. |
| Catalog / game catalog | A collection of game records with provenance, identity, version, status and review information. | That catalog inclusion means real-time inventory, production enablement or market admission. |
| Catalog Record ID | An internal identifier that tracks one catalog record consistently. | That it replaces a provider game code or transaction ID. |
| Provider Game Code | The code used by a provider or upstream interface to identify a game uniquely. | That it can be inferred from a display name or page slug. |
| Game Version | An identifiable version of game software or a content build. | That it is identical to the math model version. |
| Math Model Version | The version of the mathematical model governing probabilities, awards and theoretical statistical characteristics. | That an unchanged interface means the model has not changed. |
Sessions, rounds and transactions
| Term | Concise definition | What it does not establish |
|---|---|---|
| Launch | The process by which a platform requests and enters a specified game using agreed parameters. | That receiving a launch result completes the game flow or target-market review. |
| Launch URL | A game entry URL, or token-bearing address, generated for a particular launch context. | That it is a permanent public link or may be disclosed and reused outside the agreed scope. |
| Game Session | A bounded interaction context for an identified user, game and environment after game entry. | That it is the player account, login session, wallet or one round. |
| Round | A business unit that groups one or more bet and result events under the game rules. | That one round always maps to one transaction. |
| Transaction | An auditable business record that changes a balance or business state. | That API success means every system has reached final consistency. |
| Bet | A transaction type that requests or confirms deduction of a wager within a specified round. | That client-side animation proves the debit succeeded. |
| Win | A transaction type that increases a balance or creates a payable amount from a confirmed result. | Any outcome in another round or a long-term player return. |
| Refund | A rules-based return of all or part of an existing transaction’s effect. | That deleting the original transaction is an acceptable implementation. |
| Rollback / reversal | A traceable operation that offsets an existing business effect. | That an arbitrary refund request may be replayed; it must reference the original object and preserve idempotency. |
| Balance | The monetary state used for a business decision for a specified account, currency and point in time. | That one read proves all asynchronous records are reconciled. |
| Currency | The monetary unit and precision rules used for display, wagering, settlement or reporting. | That technical support for the currency establishes target-market permission. |
Wallet and reliability concepts
| Term | Concise definition | What it does not establish |
|---|---|---|
| Single Wallet | A model in which the platform manages the player’s balance and game transactions collaborate with the platform wallet through real-time APIs. | That timeouts, duplicates, unknown states and reconciliation requirements disappear. |
| Transfer Wallet | A model in which funds move between platform-side and game-side wallets and are recorded separately. | That the two balances are inherently consistent in real time. |
| Callback | A server-to-server interaction in which one party notifies an agreed address of an event or requests business handling. | Arrival order, uniqueness or exactly-once delivery unless the protocol says so. |
| Idempotency | The property that repeated handling of the same business request does not create a duplicate business effect. | Merely returning the same response; the system must recognize the same intent and preserve the relevant result. |
| Idempotency Key | A stable key used to identify the same business request. | That the key may be regenerated for every retry or reused without scope forever. |
| Retry | Another attempt under limited conditions, count and backoff policy when completion has not been established. | That a timeout equals failure; an unsafe retry may create a duplicate effect. |
| Unknown State | A state in which the caller cannot determine from the current response whether the business action completed. | That the system may post success or failure immediately; it should query, safely retry under explicit semantics or reconcile. |
| Correlation ID | A trace identifier linking requests, callbacks, logs and records across systems. | That it replaces a business transaction ID or idempotency key. |
| Reconciliation | The process of comparing independent transaction, round or balance records to identify and resolve discrepancies. | Real-time idempotency, state lookup or exception controls. |
| Final State | A business state that the protocol defines as no longer changing through the normal process. | That an HTTP success response is itself the final business state. |
Environments, versions and market evidence
| Term | Concise definition | What it does not establish |
|---|---|---|
| Staging | A non-production environment and configuration used for integration, verification and acceptance. | That a staging pass means production is deployed or real business behavior is verified. |
| Production | The environment that processes authorized live traffic and data. | That a production URL or credential means every game, market and version is approved. |
| API Version | An identifiable version of interface contracts, fields and behavior. | That the game or math model version is the same. |
| Integration Version | A versioned record of the selected topology and configuration among the platform, aggregator, RGS and provider. | That old evidence continues to apply after a critical component changes. |
| RTP / Return to Player | The theoretical average return over a large number of events under defined game rules and a specified math model. | A result for one event, short period or individual player. |
| RNG / Random Number Generator | A component or mechanism that supplies random values for game outcomes or related random processes. | That its implementation, version or certification has been verified merely because RNG is mentioned. |
| Certification / conformity evidence | Test or conformity evidence produced by a specified body for a defined object, version, requirements and scope. | A worldwide license, or automatic coverage of an operating entity, brand, domain or new version. |
| Integration Certification | Conformity evidence for a specified combination and interaction scope involving components such as platform, RGS, aggregator and provider. | Every other review required for an individual game or operating entity. |
| Test Body | An organization that performs testing or issues reports within a defined recognition scope. | That all services and reports from the body fall within a regulator’s recognition. |
| Standard | A specification describing technical, testing or control requirements. | That applying a laboratory standard such as GLI-19 automatically grants jurisdictional admission. |
| Market Availability | A scoped status formed from target market, operating entity, game and version, certification, currency, language, rights and a project decision. | A conclusion that catalog inclusion, language, currency or API connectivity can establish alone. |
| Language Support | A verified language capability for a defined interface, rules, help or communication scope. | Complete translation, valid certification or market availability. |
Unverified scope note for
RTP 0–1000This numeric range is not the glossary’s definition of RTP. It still requires definitions for its unit and meaning, math model version, access permissions, testing and certification material, target market and presentation. It must not be interpreted as a verified performance, return or market-compliance claim.
Common ambiguities to remove
| Ambiguous statement | Facts that must be separated |
|---|---|
| “It is in the catalog, so it is available.” | Cataloged, verified in staging, enabled in production, commercially available and verified for the target market |
| “The request timed out, so it failed.” | Unknown transport result, unknown business state, confirmed failure, safe retry and reconciliation requirement |
| “One round equals one transaction.” | A round is a game business unit; bet, win, refund and rollback may be separate transactions |
| “BRL and Portuguese are supported, so Brazil is ready.” | Currency, language, game version, integration topology, certification, operating entity, brand or domain, and market rules |
| “There is certification, so it works worldwide.” | Test-body recognition, standard, tested object, version, jurisdiction, validity and project conditions |
What can currently be evaluated on this site
- The public API reference uses concepts including catalog, launch, single wallet, transfer wallet, records and integration process.
- Reliability guides explain why duplicate requests, timeouts, callback failures, unknown states and reconciliation belong in one design.
- This glossary creates concise definitions for site-wide use without adding endpoints, signing methods, credentials or production-protocol facts.
- The catalog shows 11 providers and 1,194 game names. It is a name-level snapshot—not a conclusion about real-time supply, production enablement, content rights, versions, certification or target-market availability.
Boundaries to keep in mind
- No specific API field, production protocol, wallet implementation, performance level, SLA or release date is promised.
- No game, provider, certificate, language or currency is promised to be currently available in a target market.
- These general definitions do not replace a contract, interface specification, regulatory rule or project approval.
- The
RTP 0–1000business phrase is retained as a scoped term, but does not represent a verified numerical definition, universal capability, player result or market-admission fact.
FAQ
Are a provider and an aggregator the same type of company?
They are different roles. A provider primarily supplies game content or services; an aggregator coordinates access between multiple providers and a platform. One company may perform several roles, but project records should still separate its actual responsibilities.
Should callback, transaction and round use the same ID?
They should not normally be collapsed into one identifier. A callback is an interaction mechanism, a transaction is a business-state change, and a round is a game business unit. Each needs stable identity, with correlation IDs connecting them under the interface contract.
Does RTP mean a player receives that percentage every time?
No. RTP is a theoretical long-term statistical measure under specified rules and a math model. It does not guarantee one event or short-term outcome. Any numeric value also needs a game and math model version, test evidence and presentation scope.
Related reading and next steps
The first seven guides cover the full questions behind these definitions:
- What is a multi-provider Slots API? — the objects and boundaries connected by aggregation.
- Aggregator API vs direct provider integration — the trade-offs between integration routes.
- How to evaluate a Slots API provider — procurement evidence and due-diligence questions.
- From staging to production — evidence for a production decision.
- Idempotency, retries and reconciliation — handling failures, duplicates and unknown states.
- Game catalog data governance — fields, lifecycle states, versions and ownership.
- Market, game, version and certification matrix — target-market verification by object and scope.
Core pages: public API reference, game catalog and integration process.
When using the “Contact us” section, describe the target market, catalog scope, wallet model, environment and versions with these terms. AG can then confirm terminology and evidence scope before a project discussion. This is not a supply, certification or production commitment.
Sources and scope
- AG Game home
- Public API documentation
- Game catalog and count scope
- UK Gambling Commission RTS 3: rules, game descriptions and likelihood of winning
- Brazil Ministry of Finance SPA: Technical FAQ
- Gaming Laboratories International: Standards
Regulatory and standards sources are used to explain terminology. They do not prove that a project has met the referenced requirements. For a specific project, confirm that each definition matches the current interface, contract and target-market rules.
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.
