概要
エクソーラのAPIには以下が含まれます:
- Pay Station API — 決済UIとトークン化メソッド。
- IGS API — インゲームストアモジュールを使用するためのメソッド。
- Subscriptions API — サブスクリプションのためのメソッド。
- Login API — 独自のインターフェースを使用したユーザー認証のためのメソッド(連携ガイドを参照してください)。
APIは、HTTP認証やHTTP動詞などの組み込みのHTTP機能を使用します。これは、既製のHTTPクライアントによって解釈できます。また、クロスオリジンリソースシェアリングをサポートしているため、クライアントWebアプリケーションから安全にアクセスできます。
エクソーラのAPIは次のエンドポイントのパスを使います:https://api.xsolla.com
— Pay Station API、Subscriptions APIhttps://login.xsolla.com/api
— Login APIhttps://store.xsolla.com/api
— IGS API
リクエストとレスポンス
エクソーラAPIのリクエストに必要なこと:- HTTPSで送信。
- TLS 1.2以降を使用。
- 認証パラメータを含める。
- 追加ヘッダー
Content-Type: application/json
をPUTリクエストとPOSTリクエストに含める。
Authorization: Basic <your_authorization_basic_key>
Content-Type: application/json
既定では、すべてのリクエストが本文にJSONデータを持ち、Content-Type: application/json
ヘッダーを含むレスポンスを返します。
APIの変更内容
エクソーラはAPIの機能を次のように変更することがあります:- 新しいAPIリソースを追加する。
- オプションのリクエストパラメータを追加する。
- 既存のAPIレスポンスに新しいプロパティを追加する。
- 列挙可能な値の既存のパラメータに新しい値を追加する。
- 新しいウェブフックタイプとJSONパラメータを追加する。
- HTTPリクエストヘッダを追加する。
- 有効なパラメータに無効な値が含まれているリクエストを拒否する。
- 解析ロジックが変更された場合、寛大な構文解析のために以前に受け入れられた不適切な形式のリクエストを拒否する。
- 文書化されていない機能をいつでも追加、変更、削除することができる。
バージョン管理
すべてのエクソーラAPIメソッドはバージョン管理をサポートしています。現在のバージョンと互換性のない変更があるたびに新しいバージョンを発行します。バージョンは、URLの"/merchant"接頭辞に続く"v1"や"v2"などの識別子によって識別されます。 初めてAPIを使用する場合は、最新のバージョンを使用してください。バージョンを省略すると、デフォルトで最初のバージョンが使用されます。認証
エクソーラAPIは、次の認証タイプを使用します:- 基本アクセス認証。このようなAPIへのリクエストには、
Authorization: Basic <your_authorization_basic_key<
ヘッダーを含める必要があります。ここで、<your_authorization_basic_key>
はBase64標準に従ってエンコードされた「マーチャントID:APIキー」ペアです。アドミンページに移動して、以下のパラメータを見つけます:- マーチャントIDが表示されます:
- 「会社設定 > 会社」セクション。
- 任意のアドミンページのブラウザのアドレスバーにあるURL。URLの形式は以下の通り:
https://publisher.xsolla.com/<merchant ID>/<Publisher Account section>
。
- APIキーは、作成時に一度だけアドミンページに表示され、お客様側で保存する必要があります。次のセクションで新しいキーを作成できます:
- 会社設定 > APIキー
- プロジェクト設定>APIキー
- マーチャントIDが表示されます:
- ユーザーJWTを使用した認証。APIへのこのようなリクエストには、
Authorization: Bearer <user_JWT>
ヘッダーが含まれている必要があります。そこで、<user_JWT>
はユーザートークンです。 - サーバーJWTを使用した認証。このようなAPIメソッドには、
X-SERVER-AUTHORIZATION: <server_JWT>
ヘッダーが含まれている必要があります。そこで、<server_JWT>
はサーバートークンです。 - 認証なし。
APIキーの操作については、APIリファレンスを参照してください。
キーに関する推奨事項:
- 生成されたAPIキーは、お客様側で保存してください。APIキーは、アドミンページで作成時に一度だけ表示することができます。
- APIキーは秘密にしておいてください。APIキーは、お客様の個人アカウントとアドミンページのプロジェクトへのアクセスを提供します。
- APIキーはサーバーに保存する必要があり、決してバイナリやフロントエンドに保存してはいけません。
必要なAPIコールにproject_id
パスパラメータが含まれていない場合は、会社のすべてのプロジェクトで有効なAPIキーを使用して認証を設定します。
相互作用モデルによるAPIコール
エクソーラAPI経由でエクソーラ製品を統合する場合、APIコールを使用目的に応じて使用することが重要です:- クライアント側のAPIコール — パートナーのアプリケーションのクライアント部分とエクソーラサーバー間の相互作用のためのAPIコール。クライアントのユーザーアクションによって、これらのAPIコールのリクエストが開始されます。クライアント側APIコールの例:アイテムのリストを取得する、ユーザー認証、クライアントの決済トークンを取得する。
- サーバー側のAPIコール — パートナーのサーバーとエクソーラサーバー間の相互作用のためのAPIコール:
- ユーザーフローの実装。
クライアント上のユーザーアクションがパートナーのクライアントサイドAPIコールの呼び出しをトリガーし、エクソーラサーバーサイドAPIコールがパートナーのサーバー上で呼び出されます。ユーザーフローを実装するためのサーバーAPIコールの例:サーバーのユーザー属性を更新する、サーバー上で決済トークンを取得する。 - 管理タスク、またはパートナーによるエクソーラ製品のセットアップ。
クライアントのユーザーアクションはこれらのメソッドの呼び出しを開始できません。管理者サーバーAPIコールの例:アイテムやプロモーションの作成と編集。
- ユーザーフローの実装。
- レート制限を超える場合:
- サーバー側APIコールのレート制限は、クライアント側APIコールよりも厳しい。
- 管理者のサーバーサイドAPIコールのレート制限は、ユーザーフロー実装APIコールよりも厳しくなります。
- 応答で無関係な情報を受け取ります。例えば、クライアントサイドでアイテムリストを取得してカタログを作るAPIコールの代わりに、サーバーサイドで管理者用のアイテムリストを取得するAPIコールを使う場合。
- ユーザーによる不正なデータ変更。例えば、サーバー側のAPIコールではなく、クライアント側のAPIコールを使って属性を更新した場合。
- 決済インターフェースでの国と通貨の決定が正しくありません。
クライアント側 | サーバー側 | ||
---|---|---|---|
ユーザーフロー実装の場合 | 管理タスクの場合 | ||
相互作用 | クライアントトゥサーバー。 リクエストはゲームクライアントから直接エクソーラサーバーに送信されます。 | サーバートゥサーバー。 リクエストは、ゲームクライアントからゲームサーバーに送信され、ゲームサーバーからエクソーラサーバーに送信されます。 | サーバートゥサーバー。 リクエストは、パートナーのシステムのサーバーからエクソーラサーバーに送信されます。 |
認証 | ユーザーのJSONウェブトークン(JWT)または認証なし。 | 基本アクセス認証またはサーバーJWT。 | 基本アクセス認証。 |
レート制限 | 高負荷に耐えることができます。 | 高負荷に耐えることができます。 | パートナー専用に設計されているため、これらのAPIコールは低いパフォーマンス要件と厳しいレート制限があります。 |
ユーザーアクセス | APIコールはクライアント側で使用され、データを素早くユーザーに表示することができる。例えば、アイテムカタログやユーザー属性(購入回数やゲーム内のレベルなど)。 すべてのデータは、クライアントのコードで公開アクセスできます。 これらのAPIコールは、ユーザーが編集できないデータを扱うために使用しないでください。例えば、ユーザー属性を更新する場合。 | APIコールはサーバー間の相互作用に使用されるため、ユーザーはデータにアクセスできません。 これらのAPIコールを使用して、ユーザーが変更できないデータを操作します。 | APIコールはユーザーフローの実装には使用されません。 |
国と通貨の決定 | 国と通貨は、リクエストが送信されたクライアントのIPアドレスによって決まります。 したがって、サーバーではなくクライアント側でこれらのAPIコールを使用することが重要です。 | 国と通貨は、リクエストが送信されたサーバーのIPアドレスによって決まります。 したがって、使用するAPIコールの説明に従って、ヘッダーまたはパラメーターでユーザーの国/通貨データを渡すことが重要です。 | APIコールはユーザーフローの実装には使用されません。 |
認証スキームによって、APIコールがクライアント側かサーバー側かを判断できます:
- クライアントサイド—認証なしまたは
Authorization header: Bearer <user_JWT>
ヘッダーで呼び出されます。<user_JWT>
はユーザートークンです。 - ユーザーフローを実装するためのサーバーサイドAPIコール — は以下のヘッダーで呼び出されます:
X-SERVER-AUTHORIZATION: <server_JWT>
の中で、<server_JWT>
はサーバートークン。Authorization: Basic <your_authorization_basic_key>
の中で、<your_authorization_basic_key>
はproject_id:api_key
ペアはBase 64標準に従ってエンコードされます。
- 管理タスクのサーバーサイドAPIコール —
Authorization: Basic <your_authorization_basic_key>
ヘッダーで呼び出されます。<your_authorization_basic_key>
—project_id:api_key
ペアはBase 64標準に従ってエンコードされます。
サーバーサイド認証を使用したサーバーサイドAPIコールの例:
クライアント側認証を使用したクライアント側APIコールの例:
要件に応じて、ユーザーフローを実装する際に、サーバー側またはクライアント側のAPIコールで統合を設定する方法を選択できます。サーバー管理APIコールはユーザーフローの実装に使用しないでください。
クライアント側APIコールを使用したユーザーフローの実装例:
- ユーザーはクライアント上でアクションを実行します。例:カートに入れる、商品を購入する。
- ゲームクライアントはデータを含むリクエストをエクソーラサーバーに送信します。
- エクソーラサーバーはゲームクライアントに応答を送信します。
- ゲームクライアントは結果をユーザーに表示します。
このフローでは、ユーザJWTによる認証が使用されます。
サーバー側APIコールを使用したユーザーフローの実装例:
- ユーザーはクライアント上でアクションを実行します。例:カートに入れる、商品を購入する。
- ゲームクライアントはゲームサーバーにリクエストを送信します。
- 必要に応じて、パートナーはゲームサーバーに追加のデータ処理を実装します。
- ゲームサーバーはエクソーラサーバーにリクエストを送信します。
- エクソーラサーバーはゲームサーバーに応答を送信します。
- ゲームサーバーはデータを処理し、ゲームクライアントに応答を送信します。
- ゲームクライアントは結果をユーザーに表示します。
このフローでは、基本アクセス認証またはサーバートークンが使用されます。
サーバーサイド管理APIコールを使用する際の相互作用フロー:
- パートナーは、アプリケーションのクライアントまたはサーバーからエクソーラサーバーにリクエストを送信します。
- エクソーラサーバーはリクエストの処理結果を応答として返します。
エンドポイントの種類
エンドポイントのタイプは、どのような種類のデータを処理するのか、どのような処理を実行するのかを示します。最も一般的なアクションは次のとおりです。アクション | HTTPメソッド | 説明文 |
---|---|---|
作成 | POST | 指定されたタイプのエンティティを作成して保存します。 |
リスト | GET | クエリに一致するエンティティのリストを返します。エンティティの詳細を取得するには、最初に対応するリストのエンドポイントを使用してそのIDを見つけ、このIDを対応する取得のエンドポイントに提供します。 |
取得 | GET | 指定されたIDを持つエンティティの詳細を提供します。 |
置換 | PUT | 指定されたIDを持つエンティティのすべてのフィールドを変更します。 |
更新 | PATCH | 指定されたIDを持つエンティティの指定されたフィールドを変更します。 |
削除 | DELETE | 指定されたIDを持つエンティティを削除します。 |
日付形式
すべての日付は、ISO 8601に従って文字配列として指定されます。日付文字配列は、UTC(例:2013-01-15T00:00:00Z)、またはUTCオフセット(例えばUTC+8の場合、2013-01-15T00:00:00-08:00)を指定できます。後者の場合は、夏時間を考慮してください。ページネーション
リストのエンドポイントは、返された結果にページ区切りを付けることがあります。つまり、すべての結果を単一のレスポンスで返す代わりに、これらのエンドポイントは結果の一部と、次の結果セットにリンクするレスポンスヘッダを返す可能性があります。この目的のために、offsetトlimitのパラメータを使用します。エラー処理
サポートされているHTTPエラーの一覧:- 200、201、204-エラーはありません。
- 400 Bad Request-これは必要なパラメーターが欠落していることを示します。詳細については、レスポンス本文を参照してください。
- 401 Unauthorized-有効なAPIキーがありません。
- 402 Request Failed-パラメータは有効でしたがリクエストの実行に失敗しました。
- 403 Forbidden-許可されていません。詳細については、レスポンス本文を参照してください。
- 404 Not Found-要求された項目が見つかりません。
- 409、422-リクエストパラメータが無効です。
- 412 Precondition Failed —プロジェクトはまだアクティブ化されていません(トークンを作成するメソッドで使用されています)。
- 415 Unsupported Media Type-HTTPヘッダに
Content-Type: application/json
がありません。 - 500、502、503、504 Server Errors-サーバーエラーが起きました。
422
エラーコードを返します。
すべてのAPIエラーレスポンスは、JSONオブジェクトに次のフィールドを提供します。名前 | 種類 | 説明文 |
---|---|---|
http_status_code | integer | HTTPコード。 |
message | string | 人間が判読できるエラーの説明。このメッセージは常に英語で表示されます。将来的に変更される可能性があるため、特定のエラーのためにこの値に頼らないでください。 |
extended_message | string | より詳細なエラーの説明。 |
request_id | string | トラブルシューティングに使用する固有のリクエストID。 |
- http
{
"http_status_code": 500,
"message": "Internal Server Error",
"extended_message": null,
"request_id": "6445b85"
}
レート制限
一般情報
エクソーラシステムの過負荷を回避し、受信トラフィックのバーストからシステムを保護するために、エクソーラは、指定された期間内に エクソーラAPIによって受信されるリクエストの数を制限します。制限を超えた場合、エクソーラAPIは429
ステータスコードでHTTPレスポンスを返します。
制限値は、方式、プロジェクト、その他の要因によって異なります。現在の制限値は、エクソーラシステムの安定的かつ継続的な運用を保証するために定期的に更新されます。場合によっては、事前のリクエストにより、指定された制限を調整することが可能です。カスタマーサクセスマネージャーに連絡するか、メールcsm@xsolla.comまでリクエストを送信してください。レート制限を超える一般的な原因
- パートナー側のトラフィックが急激に増加した原因は以下通り:
- 季節セール
- クローズドテストとオープンテストの開始
- パートナー側でのDDoS攻撃の結果、トラフィックが急激に増加しました。
- 不適切に構成された統合。例:
- 一定時間内に過剰に多くのリクエストを起動すること。例:アイテムカタログを表示するための仮想アイテムリストを取得メソッドを1秒間に200回以上呼び出すこと。
レート制限の処理
レート制限によるエラーを防ぐために、以下のことをお勧めします:429
ステータスコードを追跡し、再試行メカニズムを作成します。連続再試行の代わりに、再試行間に固定または指数バックオフを持つ再試行パターンを使用することができます。- 必要なデータのみを取得するようにコードを最適化します。アプリケーションが必要とするリクエストのみを行い、不要なAPIコールを避けるようにします。IGS APIを使用している場合は、WebSocket APIを使用することで呼び出し回数を減らすことができます。
- アプリケーションで頻繁に使用されるデータをキャッシュします。静的なデータを手元に置いて、外部APIへのリクエストの数を減らすことができます。
- APIを破壊するDDoS攻撃を防ぐことができます。
- リクエストのレートを調整することで、よりスムーズな配信が可能になります。
429
エラーが定期的に発生する場合は、リクエストのレートを調節し、リクエストをより均等に分散できるようなプロセスをコードに含めることを検討してください。
APIキー
APIキーは、ユーザーデータの暗号化およびAPIリクエストの認証に使用される一意のキーです。アドミンページでは、会社のすべてのプロジェクトと個々のプロジェクトに対してAPIキーを作成できます。
APIキーを作成する
APIキーを作成するには:- アドミンページを開きます。
- 会社設定 > APIキーまたはプロジェクト設定 > APIキーセクションに移動します。
- APIキーを作成するをクリックします。
- 以下のフィルドを入力します:
- キーのリストに表示されるキーの名前。キーを簡単に識別できるような名前を設定します。
- キーのタイプ — 永久的または一時的。
- 有効期限 — 一時的なキーの場合のみです。有効期限を過ぎると、そのキーは無効となり、新たにキーを作成する必要があります。
- キーが有効なプロジェクト(プロジェクトページでAPIキーを作成しても、このフィールドは表示されません)。デフォルトでは、すべてのプロジェクトが選択されています。
- 作成するをクリックします。
- 開いたウィンドウで、APIキーをコピーするをクリックし、作成したAPIキーを自分側で保存します。
キーに関する推奨事項:
- 生成されたAPIキーは、お客様側で保存してください。APIキーは、アドミンページで作成時に一度だけ表示することができます。
- APIキーは秘密にしておいてください。APIキーは、お客様の個人アカウントとアドミンページのプロジェクトへのアクセスを提供します。
- APIキーはサーバーに保存する必要があり、決してバイナリやフロントエンドに保存してはいけません。
必要なAPIコールにproject_id
パスパラメータが含まれていない場合は、会社のすべてのプロジェクトで有効なAPIキーを使用して認証を設定します。
APIキーを削除する
APIキーを削除するには:- アドミンページを開きます。
- 会社設定 > APIキーまたはプロジェクト設定 > APIキーセクションに移動します。
- APIキーの行で、ビンのアイコンをクリックし、動作を確認します。
- このAPIキーが使われたプロジェクトで支払いを受ける
- このAPIキーを使用したAPIメソッドを呼び出す
- 新しいAPIキーを作成します。
- 新しいAPIキーを使用するようにアプリケーションを変更します。
- 初期のAPIキーを削除します。
ウェブフック
ウェブフックを使用すると、エクソーラ側で構成されたイベントの即時通知を受信できます。処理用エクソーラを設定することで、アプリケーションを自動化することができます。利用可能なウェブフックのリストとその動作の詳細については、当社のドキュメンテーションを参照してください。
誤字脱字などのテキストエラーを見つけましたか? テキストを選択し、Ctrl+Enterを押します。