jili games api: Retire Game IDs Without Losing Settlements

A jili games api integration needs a retirement process, not just a launch process. When a title disappears from a catalog, changes identifiers, or becomes unavailable through your contracted route, deleting its database record can break reconciliation and leave valid payouts unresolved. The practical goal is to stop new play without destroying the identity and transaction history needed to finish existing financial obligations.

This guide covers an operator-controlled workflow for retiring game identifiers. It does not assume that JILI exposes particular status fields, callback types, or retirement endpoints. Confirm those details with your integration partner before implementing the controls below.

Why removing a lobby tile is not enough

A game exists in several places beyond the lobby: cached catalog responses, favorites, direct launch URLs, active sessions, wallet transactions, reporting exports, and support tools. Removing its tile changes only one surface.

Two failures deserve particular attention:

• A cached page or saved link can still request a new launch after the operator considers the title retired.
• A late settlement can reference an identifier that the wallet no longer recognizes because someone deleted or replaced its mapping.

These failures need separate controls. Launch authorization determines whether new play may begin. Settlement processing determines how authenticated financial events are handled. Neither should depend exclusively on whether a game is visible in the current catalog.

jili games api retirement: separate discovery, launch, and settlement

Use independent internal controls rather than one universal `enabled` flag. The following are suggested operator-side states, not documented JILI API fields.

Discovery status

Controls whether the title appears in search, categories, recommendations, and favorites. Hiding a title should not erase its historical record.

Launch status

Controls whether the server may create a new session. Enforce this at the launch service, even when the request comes from a previously cached lobby page.

Financial processing status

Controls which authenticated callbacks remain eligible for normal processing, investigation, or rejection under the agreed protocol. Retirement alone must not cause valid credits or reversals to be discarded.

An internal lifecycle could be `active`, `draining`, and `retired`. During draining, discovery and new launches are disabled while existing obligations remain supported. Retired records still retain their transaction mappings and an exception path for legitimate late events.

Existing sessions require a separate decision: may they finish an open round, continue placing new bets temporarily, or stop immediately? Document that behavior before scheduling removal.

Preserve an immutable game identity

Keep an internal game record that survives catalog changes. At minimum, retain:

• Internal game key and original external game identifier.
• Provider namespace and contracted integration route.
• Identifier mappings with effective dates and source evidence.
• Operator or brand scope where relevant to routing.
• Retirement reason, effective time, and approval reference.
• Links to historical sessions, rounds, and wallet transactions.

Store external identifiers exactly as specified. Do not lowercase them, trim meaningful characters, or convert numeric-looking strings to integers unless the contract explicitly permits that normalization.

A replacement catalog entry should not automatically inherit the old record. Similar titles and artwork are not proof of identical financial identity. If the partner confirms an identifier migration, preserve both identifiers and their effective mapping rather than overwriting the old value.

Never route a callback through a display name. Names can change; historical transaction attribution must remain stable.

Treat catalog disappearance as evidence, not a deletion command

A synchronization job might receive an incomplete response because of pagination errors, timeouts, changed credentials, or a filter applied upstream. One missing entry does not establish permanent withdrawal.

Before treating absence as a retirement signal:

1. Check that the catalog fetch completed successfully across all required pages.
2. Confirm the response scope: route, operator, currency, and other applicable filters.
3. Compare against the last complete snapshot, not a partially imported working table.
4. Quarantine unexpected removals for review rather than immediately deleting records.
5. Obtain authoritative confirmation when the reason or effective time is unclear.

Use a removal threshold to alert on unusually broad changes, but do not mistake that threshold for proof that smaller changes are safe.

An explicit withdrawal notice may require an immediate launch block. Your workflow should support that action without waiting for another catalog refresh or deleting financial mappings.

Run retirement as a controlled change

Before the cutoff

Record the affected identifiers, responsible owner, effective time, and agreed existing-session behavior. Ask the partner about expected late events, reconciliation reports, retry behavior, and any replacement identifiers.

Build an inventory of open rounds and unresolved transactions using the evidence available through your integration. If a definitive open-round query is unavailable, document how callback records, session history, and partner reports will be combined. State the remaining uncertainty instead of claiming complete visibility.

Test the change against direct launch requests, not just the lobby interface.

At the cutoff

Disable new launches at the authoritative server-side check and invalidate relevant discovery caches. Prevent scheduled imports from automatically restoring the title.

Define what happens to a launch request already in flight. Where supported, use short-lived launch authorization and a final policy check near session creation. If the integration cannot cancel an issued launch, record that limitation and agree how those sessions will be handled.

Return a neutral player message such as “This game is currently unavailable.” Do not silently redirect a pending financial session to another game.

After the cutoff

Continue validating callbacks using the normal authentication, signature, idempotency, and transaction rules. A known retired identifier is not, by itself, a reason to reject a settlement.

Conversely, knowing an old game identifier does not authorize a debit. For post-cutoff wagers, apply the agreed session and round rules. Where debits can arrive late, distinguish delayed delivery from genuinely new wagering using trusted protocol evidence, not receipt time alone.

Unknown identifiers should enter the documented exception workflow. Do not create payable game mappings automatically from unverified callback payloads. Use contract-defined responses and retries rather than inventing acknowledgment behavior.

Prove the workflow with acceptance tests

Run these scenarios in a controlled environment with agreed expected outcomes:

• Cached launch: A saved URL requests the game after cutoff. The server blocks new session creation.
• Late credit: A legitimate pre-cutoff round settles afterward. The credit follows normal validation and posts once.
• Duplicate settlement: The same event is retried after retirement. The established idempotency behavior prevents a second posting.
• Delayed debit: A wager callback arrives after cutoff. The system applies the contracted timing rules rather than assuming arrival time equals bet time.
• Reversal: A valid reversal references the retired identifier. Historical attribution remains intact and the documented reversal rules apply.
• Catalog reappearance: The next import includes the title again. It stays blocked until an authorized reinstatement decision.
• Identifier replacement: A new listing resembles the old game. Historical transactions remain attached to their original identity.
• Incomplete import: A failed catalog page omits several titles. No permanent records are deleted.

For each test, retain the policy version, identifiers, ledger outcome, and relevant sanitized evidence. Keep session secrets and unnecessary player data out of the test report.

Close the change without erasing the trail

Retirement completion should be evidence-based, not simply “seven days have passed.” Define closure criteria with the integration partner:

• Known open rounds and transaction exceptions have an agreed resolution.
• Available settlement reports reconcile to the operator ledger.
• Launch attempts are blocked across supported entry points.
• Catalog imports cannot override the retirement decision.
• Late-event monitoring has an owner and escalation path.

Preserve a tombstone record after operational closure. Retain detailed records according to contractual, legal, and privacy requirements; financial traceability does not justify keeping every raw payload indefinitely.

GamingAPI offers 16,000+ games from 150+ studios through one API with a seamless wallet. Aggregation simplifies the integration surface, but operators still need explicit retirement and reconciliation controls. Use contact to confirm current JILI availability, identifier behavior, and supported settlement workflows for your proposed integration.

FAQ

Should retired games reject every wallet callback?

No. Valid credits, reversals, and other supported financial events may arrive after launches stop. Authenticate and validate them under the agreed protocol, including duplicate protection and historical transaction checks.

Can an old game ID be replaced with a new one?

Only through a confirmed mapping process that preserves historical attribution. Do not overwrite the identifier used by existing sessions and transactions merely because a new catalog entry looks equivalent.

When can a retired game record be deleted?

Avoid deleting the identity record while it supports financial or audit obligations. A minimal tombstone can preserve mappings after operational closure, while associated payloads and personal data follow their applicable retention schedules.