スタジオとプラットフォーム間のAPI統合の仕組み

プラットフォーム/アグリゲーターとのスタジオ（ゲームプロバイダ）の統合は、セッション、ウォレット、スピン結果、およびイベントテレメトリーの周りの同期および非同期コールのチェーンです。以下は、開発者とコンプライアンスのための苦痛なしにすべてがどのように接続するかの簡単で実用的なマップです。

1）手のひらの中の建築

俳優：

スタジオRGS（リモートゲームサーバー）-ゲームロジック、RNG、ボーナス、ジャックポット。
プラットフォーム/アグリゲーター-ルーティング、請求、プロモーション、コンプライアンス。
オペレータ-プレイヤーの財布、KYC/RG、ショーケース。
クライアント-Web/モバイルゲームコンテナ（iframe/webview/native）。

主要なバス：

Sync API：セッション、ウォレット、結果。
非同期/イベントバス：スピンイベント、ボーナス、ジャックポット、RG、技術的エラー。
メタデータ/カタログ：ゲーム、マーケットビルド、RTPプロファイル、ロケール。

2）議定書および基本的な解決

トランスポート：HTTPS/JSON（イベントバス/ウォレットの場合はgRPC）。

バージョン管理：'Accept： application/vnd。RGS。v1+json'または'/v1/……'；互換性の低下-新しいバージョンでのみ。

識別：'game_id'、 'build_hash'、 'operator_id'、 'session_id'、 'round_id'、 'spin_id'。

時間：厳密にUTC、ミリ秒でISO-8601。

通貨：ISO-4217+精度（マイナーユニット）。FX-オペレータ/アグリゲータ側。

3）認証と認証

Server-to-Server： OAuth2 Client Credentials （'X-Signature： подпись （payload、 HMAC_SHA256）'）をshared_keyします。

プレイヤーセッション：短命のJWT（看板プラットフォーム）c 'sub'、 'geo'、 'rg_flags'、' exp'、'aud=studio'。

アクセスリスト：本番ループのIP allow+mTLS。

4）ウォレットモデル： デビット/クレジットと転送

A）デビット/クレジット（オンザフライ）：

1.プラットフォームはRGSを呼び出します：'SpinRequest （stake）'→RGSは結果を計算します→'win'を返します。

2.並行して、プラットフォームはオペレータの場所で'debit （stake）'と'credit （win）'を作ります。

長所：簡単な簿記。短所：より多くのネットワークコール、idempotencyのための厳格な要件。

B）転送（セッション残高）：

1.セッションの冒頭で、プラットフォームはRGSで「transferIn （amount）」を行います。

2.スピン中、RGS自体はセッションのバランスをとります。on completion-'transferOut （remaining）'。

長所：ウォレットチャットが少なくなります。短所：「RGS側のお金」を会計、追加のリスクと和解。

推奨事項：

スロットでは、idempotentキーを持つデビット/クレジットがより頻繁に使用されます。

フリースピンやトーナメントでは、別々のベットタイプのspin_type=freeが便利です	プロモ'。

5） Idempotencyおよび一貫性

各マネーステップには一意の'idempotency_key'（例えば'round_id'または'spin_id'）が必要です。

重複（'HTTP 409/425'）は「、すでに実行されているエラー」ではなく、同じ結果を返します。

正確に1回は達成するのが難しいので、少なくとも1回は+idempotencyを構築します。

Idempotenceは'debit'、 'credit'、 'jackpot_contribution'、 'bonus_award'に拡張されます。

6）キークエリスキーム（略称）

6.1.セッションの開始

json
POST/rgs/v1/セッション
{
"session_id"： "s-……"、 "operator_id"： "op-……"、 "player_id"： "p-"……、 "game_id"： "g-BookOf……"、 "build_hash"： "sha256：……"、 "jwt"： "eyJhbGci……"、 "geo"： "DE"、 "currency"： "EUR"、 "rg_flags"： {"self_excluded"： false"、time_limit_min"： 60}
}

6.2.スピン（デビット/クレジット）

json
POST/rgs/v1/スピン
{
「spin_id"：」 spin-……「、」round_id"： 「rnd-……」、 「session_id"：」 s-……「、」stake「：{」amount'： 1。00、 「currency」： 「EUR」}、 「spin_type"： 「cash」、 「idempotency_key"： 「spin-」……
}

答え：

json
{
"spin_id"： "spin-……"、"結果"：{
"win"： {"amount'： 3。40、 「currency」： 「EUR」}「、features'：［{」type「：」bonus_trigger「、」name「：」FreeSpins'、 「count'： 10}］、」 symbols'： 「opaque-or-opitted」
}、"rgs_txns"：［
{"type"： "jackpot_contribution"、 "amount'： 0。01}
］、"telemetry_ref"： "evt-"……
}

6.3.イベントバス

json
POST/rgs/v1/events/バッチ
{
「イベント」：［
{
「type」： 「spin_finished」、 「ts'：」 2025-10-20T11： 22：33。123Z," "spin_id":"spin-...," "round_id":"rnd-...," "stake"： 1。00、「勝利」：3。40「、通貨」：」EUR」、 「game_id":"g-...,""build_hash":"sha256:...,」 「player_id":"p-...,""operator_id":"op-...,」 「spin_type":"cash」
}
]
}

7）バージョン管理ビルドと市場ビルド

'build_hash' （SHA-256）-各イベントに必要です。

グローバルvsマーケットビルド：言語、警告、レート制限、RTPプロファイル。

プラットフォームは「、特定の国の証明書と一致するビルドが現在再生されている」ことを検証します。

行列：'game_id country 。

8） RNG、数学とリプレイ

RNGはRGSに住んでいます。ビジネスロジックはチャンスを変えません。

フォレンジックの場合：ラウンド/スピン+メカニックバージョンごとに'seed/nonce'。

リプレイ：'spin_id'/'seed'により、RGSは結果を再現し、監査証跡を提供します。

9）責任あるゲーム（RG）とコンプライアンスフック

時間/限界のフック： 'session_time_ms'、「reminders」、タイムアウト；イベントバスの'rg_event'

自己排除/ブロック：フラグ付き-即時'403 RG_BLOCKED'。

UI不変量：プラットフォームは、クライアントがマーケットビルドから警告/年齢タグを表示することをチェックします。

10）バグ、レトレイ、SLA

コード：'400'（検証）、'401/403' （認証/RG）、 '409' （idempotency競合）、'422'（ビジネスエラー）、'429'（レート制限）、'5xx'（一時的な）。

リトレイポリシー：指数関数的で、レシーバでのidempotentキーと重複除外があります。

SLA ≥ 99 APIの可用性。9％、 'spin'のp95レイテンシ≤ 200-300ミリ秒（地域）、イベントバス-ほぼリアルタイム<60秒。

11）観察可能性および監査

ログ：相関'trace_id'を持つカットサーバーログ。

メトリクス：p95/p99レイテンシ、メソッドによるエラー率、RTP/ボーナス周波数の偏差、「弾性スピン」の割合。

アラート：SLAによる、数学の異常による、ウォレット障害の増加による。

監査：賭け/結果イベントのためのWORMストレージ。要求に応じて輸出して下さい。

12）安全性

mTLS+TLS 1。2+、HSTSのクライアントローダーの厳密なCORS。

キー回転、短いTTLトークン、JTI/nonceチェック。

クライアントのためのアンチタンパー：資産署名、整合性チェック、デバッガ保護。

秘密-秘密のマネージャーでのみ；「ゲームの設定のキー」はありません。

13）テスト環境および証明

サンドボックス：架空の財布、決定論的なRNG（固定シード）、RGシナリオの自動障害。

ステージング：実質のお金のないprod-infraのコピー。

実験室用パッケージ：GDD/数学、 RNG文書、ログ図、繰り返し可能なビルドとハッシュ。

14） APIのプロモーションとジャックポット

フリースピン：パケット転送：'grant_free_spins （count、 bet_size、 rtp_profile?）'；イベントはRGSに費やされ、ログに記録されます。

トーナメント：属性'spin_type=tournament'+イベントバスの個々の集計。

ジャックポット：'jackpot_contribution'と'jackpot_win'を個別のトランザクションとして指定します。idempotencyと「署名済み」イベントによる整合性。

15）報告と請求

"spins_total"、 "eligible_spins'、" turnover"、"ggr"、"netwin"、"jackpot_contrib"、"bonus_cost"、"royalty_due"。

spin/turnover-fee： "eligible_spins'または"Σ stake × rate"によるアカウント。

Rev-share： 'waterfall'が保持した後の'NetWin'から；FX/例外の四半期ごとのtrue-up。

16）典型的なシーケンス（ワードチャート）

スピン（デビット/クレジット）：

クライアント→プラットフォーム：StartRound→プラットフォーム→RGS：スピン→RGS→プラットフォーム：結果→プラットフォーム→ウォレット：デビット→プラットフォーム→ウォレット：クレジット→プラットフォーム→クライアント：結果→プラットフォーム→EventBus： spin_finished。

フリースピン：

プラットフォーム→RGS： GrantFreeSpins→Client： Start→RGS： Consume/Log each→EventBus： spin_finished （spin_type=free)。

17）変更管理と相互運用性

Contract-first： OpenAPI/Protobufは単一のスキーマのソースです。

SemVer：フィールドのみを追加します。delete/modify -/v2。

Feature flags-Enable options （Bonus Buy/Ante）認定プロフィールのみ。

拒絶：非活動領域での発表→猶予期間→シャットダウン。

18）チェックリスト

スタジオ→プラットフォーム

OpenAPI/gRPC仕様とサンプルペイロード。
IDempotency 'spin/debit/credit/jackpot'。
'build_hash'とマーケットはレジストリをビルドします。
RNGレプリカと監査ログ。
RGフックとエラー'403 RG_BLOCKED'。
フィックスシード、テストウォレット、オートスクリプト付きのサンドボックス。

プラットフォーム→スタジオ

短いTTL、 allowlist IP、 mTLSのJWT署名。
マーケットビルドと証明書のバリデータ。
イベントバスとダッシュボード（レイテンシ/エラー/RTPドリフト）。
正直なフィードバック'429-Retry-After'によるクォータとレート制限。
SLA/インシデント/リンク 24 × 7。

19） 30-60-90打ち上げ計画

0-30日

API契約とイベントスキームに同意し、ウォレットモデルを選択します。

サンドボックスを上げます：固定種子RNG、テストウォレット、idempotencyのオートテスト。

レジストリ'build_hash'とプライマリマトリックスマーケットビルド。

31-60日

ウォレットとスピンの統合；イベントバスとダッシュボードを有効にします。

負荷テスト（p95/p99）、 retrai/idempotency、ネットワークカオスシナリオ。

コンプライアンス：RGフック、ロケール、年齢ラベル；実験室へのパッケージ。

61-90日

1-2オペレータのためのパイロット、プロモーションのためのA/B（フリースピン/トーナメント）。

true-up/reporting、 RTP drift アラート/bonus-freqを入力します。

v2の改善の準備：バッチイベント、ウォレット用のgRPC、ジオルーティング。

20）短いFAQ

RTP/バージョンはどこでチェックされますか？プラットフォーム：'build_hash' ↔証明書↔国。

RTPは動的に変更できますか？いいえ、そうではありません。事前に認定されたプロファイルとスイッチング市場のみが構築されます。

「ダブルデビット」を解決するには？Idempotent key+storing transaction status；redo-結果を返します。

gRPCが必要ですか？大量のウォレット/イベントに便利です。RESTはメタデータ/管理パネルに残ります。

安定した統合はcontract+idempotency+observabilityです。透明なイベントスキーム、ビルド/マーケットコントロール、RGフック、バージョン規律により、開始時にリスクの90％が削除されます。さらに-プロモーションとレポートの自動化、ハードSLA、変更を「破る」ことなくAPIの慎重な開発。