iGaming API versioning and retirement should keep wallet, PAM, RGS, sportsbook, payment, identity and reporting integrations predictable while a contract changes. The useful delivery artifact is an API lifecycle control pack that joins contract rules, a consumer register, deprecation signals, migration evidence, exceptions, rollback and a final retirement gate.
For an operator CTO, platform owner, integration lead or procurement team, the decision is not simply whether an endpoint has v1 in its path. The buyer needs to know which changes break consumer assumptions, who still depends on each contract, how a replacement is proved and who may close the old route.
Define compatibility as preserved behavior
API compatibility means an existing consumer can continue to perform its business operation safely without changing its implementation or assumptions. A field can remain present while its meaning, validation, ordering, error behavior, authentication or side effects change enough to break the contract.
Write compatibility rules for requests, responses, callbacks and operational behavior. Separate additive changes that consumers can ignore from changes that alter required input, remove output, narrow accepted values, change precision, reinterpret status, reorder events or produce a new financial side effect. A wallet callback that keeps the same JSON shape but changes retry meaning is not safely compatible.
The OpenAPI Specification 3.2.0 provides a machine-readable way to describe paths, operations, parameters, schemas and security. It also defines a deprecated flag for operations and other components. That flag can support discovery, but it does not inventory consumers, explain migration or authorize shutdown.
Give every released contract an immutable identifier. The identifier may appear in a URL, header, media type or negotiated capability, but the delivery decision is the same: a deployed behavior must be traceable to a reviewed definition, exact build and effective date.
Inventory consumers before announcing retirement
An API consumer register should identify every application, supplier and operational process that depends on the contract. Repository search and an integration spreadsheet are useful starting points, but they do not prove what still calls a live route.
OWASP API9:2023 Improper Inventory Management recommends inventorying API hosts by environment, network access and version, plus integrated services and data flows. It also calls for documentation of authentication, errors, redirects, rate limits, cross-origin behavior and endpoints, and warns that exposed old versions still need protection.
Join the owned register to runtime evidence such as gateway logs, service identities, issued credentials, callback destinations, traces and supplier confirmations. Record an owner, environment, version, business operation, data classification, replacement target, migration status and last verified activity. Anonymous traffic is a discovery failure, not permission to retire it.
The existing Wizards sportsbook API guide helps operators evaluate coverage, latency, settlement and commercial fit. Lifecycle control begins after that selection: it preserves the interface decision as consumers and versions change.
Separate deprecation from shutdown
Deprecation tells consumers to migrate; shutdown makes the legacy resource unavailable. Combining those states into one date removes the period in which providers and consumers can discover dependencies, test the replacement and resolve exceptions.
RFC 9745, published in March 2025, defines the Deprecation HTTP response header and a deprecation link relation. The header can communicate when a resource will be or was deprecated, while the link can point to policy or migration documentation. The RFC is explicit that deprecation itself does not change resource behavior.
RFC 8594 defines the Sunset response header for the timestamp at which a resource is expected to become unresponsive. RFC 9745 says that when both headers are used, the Sunset timestamp must not be earlier than the Deprecation timestamp.
Use those signals where HTTP clients can observe them, but do not rely on headers alone. Publish a dated notice, replacement contract, change summary, migration guide, test environment, support owner and closure criteria. Notify every registered consumer through its agreed operational channel and retain the acknowledgement or exception.
Run old and new contracts with one authority
Parallel API operation should preserve one authority for each business state while old and new interfaces coexist. Two versions may accept traffic, but they must not create independent truth for player balances, round settlement, limits or identity status.
Translate both versions into a controlled domain operation or explicitly document the different effects. Keep idempotency keys, transaction references, event ordering and audit records stable across the boundary where the business meaning is intended to remain the same. If behavior changes, expose and test that difference rather than hiding it in an adapter.
The iGaming platform migration guide covers a one-time transfer between platform authorities. API lifecycle work is narrower and continuous: individual integration contracts can change many times while the platform remains live.
Prove the replacement against business consequences
Replacement acceptance should test the business consequences that the interface controls, not only schema conformance or successful responses. A syntactically valid wallet call can still duplicate movement, a valid game callback can still settle twice, and an identity response can still lose a restriction.
Build contract tests for required and optional fields, unknown values, authentication, authorization, rate limits, timeouts, retries, duplicate callbacks, event order, precision, pagination and error mapping. Then add domain tests for wallet state, open rounds, bet settlement, player restrictions, reporting and supplier recovery where those concerns are in scope.
GLI-19 Interactive Gaming Systems Version 3.0 includes change-management expectations for version control, installation records, tested rollback, migration signoff and updated documentation. GLI is a technical baseline that markets may adopt or adapt, not universal legal advice or proof that an API is approved.
Retain the contract definition, test data class, environment, request and response evidence, downstream state, exceptions and exact release identity. The result should let a reviewer explain what changed and why the new route is safe for the named operations.
Gate retirement on evidence from every consumer
API retirement should occur only after every in-scope consumer has migrated, stopped by design or received an approved time-bounded exception. A traffic graph reaching zero is useful evidence, but it is not sufficient when seasonal jobs, recovery tools or dormant supplier callbacks may not appear during the observation window.
Require signed consumer status, runtime evidence across the agreed operating cycles, replacement acceptance, support readiness, rollback rehearsal, record retention and an owner for late traffic. Define what the legacy endpoint returns after closure and how an unexpected caller reaches the migration owner without restoring an unsafe version by improvisation.
The UK Gambling Commission’s testing and release good practice calls for separate development and test environments, a change plan, adequate testing, change control and authorization. Its testing procedure also addresses representative testing when RGS or RNG changes affect functionality or fairness. Those requirements apply within their stated Great Britain scope; the broader delivery lesson is to tie release authority to evidence for the exact change.
Make lifecycle control a procurement deliverable
The API lifecycle control pack should be accepted with the integration and revised for every breaking change or retirement. It gives the operator, platform provider and supplier one durable answer to what exists, who depends on it and what evidence permits change.
Require the compatibility policy, version catalogue, consumer register, contract definitions, change classifications, notice templates, replacement guide, test environments, support channels, migration dashboard, exception authority, rollback plan, retirement checklist and retained release evidence. Define these obligations in the service and supplier model rather than discovering them when the first old endpoint becomes expensive to support.
Frequently asked questions
What should an iGaming API lifecycle policy include?
An iGaming API lifecycle policy should define contract ownership, compatibility rules, version identifiers, consumer inventory, deprecation signals, migration support, verification evidence, exception authority and the gate for retirement. It should also distinguish deprecation from a shutdown date.
When does an iGaming API change need a new version?
An iGaming API change needs a new contract version when an existing consumer cannot continue safely without changing its implementation or assumptions. The decision should consider request and response meaning, validation, error behavior, authentication, ordering and side effects rather than URL shape alone.
How should an API provider announce deprecation?
An API provider should publish a dated notice, identify the affected contract, link the replacement and migration guide, expose runtime deprecation information where practical, and contact every known consumer through the agreed channel. A deprecation notice should not be treated as proof that migration is complete.
How can an operator find every API consumer?
An operator can combine an owned integration register with gateway logs, service identities, credentials, callback destinations, traffic traces and supplier confirmations. Each discovered consumer should have an owner, environment, contract version, data scope, replacement status and last verified activity.
What evidence is required before API retirement?
API retirement evidence should show that every in-scope consumer has migrated or received an approved exception, the replacement handles expected and negative paths, legacy traffic has reached the defined closure condition, rollback is tested, records are retained and named owners approve the exact release.
Is a Deprecation header the same as a Sunset header?
No. The Deprecation header signals that a resource will be or has been deprecated, while the Sunset header communicates when a resource is expected to become unresponsive. RFC 9745 also states that a Sunset timestamp must not precede the Deprecation timestamp when both are used.
If you are commissioning or replacing integration contracts for an iGaming platform, talk to Wizards about turning version rules, consumer discovery and retirement evidence into a testable API lifecycle control pack.
