はじめる

概要

エクソーラのAPIには以下が含まれます:

  • Pay Station API — 決済UIとトークン化メソッド。
  • IGS API — インゲームストアモジュールを使用するためのメソッド。
  • Subscriptions API — サブスクリプションのためのメソッド。
  • Login API — 独自のインターフェースを使用したユーザー認証のためのメソッド(連携ガイドを参照してください)。
エクソーラAPIはRESTに基づいて設計されています。APIには、予測可能なリソース指向のURLがあり、HTTPレスポンスコードを使用してAPIエラーを示します。APIは、エラーの場合を含め、常にJSON形式で応答します。

APIは、HTTP認証やHTTP動詞などの組み込みのHTTP機能を使用します。これは、既製のHTTPクライアントによって解釈できます。また、クロスオリジンリソースシェアリングをサポートしているため、クライアントWebアプリケーションから安全にアクセスできます。

エクソーラのAPIは次のエンドポイントのパスを使います:
  • https://api.xsolla.com — Pay Station API、Subscriptions API
  • https://login.xsolla.com/api — Login API
  • https://store.xsolla.com/api — IGS API
ほとんどのエンドポイントのパスには、merchant_idパラメーターが含まれています。これは、アプリケーションが出品者のために機能していることを示します。

リクエストとレスポンス

エクソーラAPIのリクエストに必要なこと:
  • HTTPSで送信。
  • TLS 1.2以降を使用。
  • 認証パラメータを含める。
  • 追加ヘッダーContent-Type: application/jsonをPUTリクエストとPOSTリクエストに含める。
Copy
Full screen
Small screen
    Authorization: Basic <your_authorization_basic_key>
    Content-Type: application/json
    

    既定では、すべてのリクエストが本文にJSONデータを持ち、Content-Type: application/jsonヘッダーを含むレスポンスを返します。

    APIの変更内容

    エクソーラはAPIの機能を次のように変更することがあります:
    • 新しいAPIリソースを追加する。
    • オプションのリクエストパラメータを追加する。
    • 既存のAPIレスポンスに新しいプロパティを追加する。
    • 列挙可能な値の既存のパラメータに新しい値を追加する。
    • 新しいウェブフックタイプとJSONパラメータを追加する。
    • HTTPリクエストヘッダを追加する。
    • 有効なパラメータに無効な値が含まれているリクエストを拒否する。
    • 解析ロジックが変更された場合、寛大な構文解析のために以前に受け入れられた不適切な形式のリクエストを拒否する。
    • 文書化されていない機能をいつでも追加、変更、削除することができる。
    変更に関係なく、クライアントは機能し続けます。たとえば、クライアントによって認識されない新しいJSONパラメータは、通常の操作を妨げてはいけません。

    バージョン管理

    すべてのエクソーラAPIメソッドはバージョン管理をサポートしています。現在のバージョンと互換性のない変更があるたびに新しいバージョンを発行します。バージョンは、URLの"/merchant"接頭辞に続く"v1"や"v2"などの識別子によって識別されます。 初めてAPIを使用する場合は、最新のバージョンを使用してください。バージョンを省略すると、デフォルトで最初のバージョンが使用されます。
    お知らせ
    エクソラでは、同じバージョン内でのみ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キー
    • ユーザー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コールの例:アイテムやプロモーションの作成編集
    正しく構成された統合は、最も一般的なエラーを回避できます:
    クライアント側サーバー側
    ユーザーフロー実装の場合管理タスクの場合
    相互作用クライアントトゥサーバー。
    リクエストはゲームクライアントから直接エクソーラサーバーに送信されます。
    サーバートゥサーバー。
    リクエストは、ゲームクライアントからゲームサーバーに送信され、ゲームサーバーからエクソーラサーバーに送信されます。
    サーバートゥサーバー。
    リクエストは、パートナーのシステムのサーバーからエクソーラサーバーに送信されます。
    認証ユーザーの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コールを使用したユーザーフローの実装例:

    1. ユーザーはクライアント上でアクションを実行します。例:カートに入れる、商品を購入する。
    2. ゲームクライアントはデータを含むリクエストをエクソーラサーバーに送信します。
    3. エクソーラサーバーはゲームクライアントに応答を送信します。
    4. ゲームクライアントは結果をユーザーに表示します。

    このフローでは、ユーザJWTによる認証が使用されます。

    サーバー側APIコールを使用したユーザーフローの実装例:

    1. ユーザーはクライアント上でアクションを実行します。例:カートに入れる、商品を購入する。
    2. ゲームクライアントはゲームサーバーにリクエストを送信します。
    3. 必要に応じて、パートナーはゲームサーバーに追加のデータ処理を実装します。
    4. ゲームサーバーはエクソーラサーバーにリクエストを送信します。
    5. エクソーラサーバーはゲームサーバーに応答を送信します。
    6. ゲームサーバーはデータを処理し、ゲームクライアントに応答を送信します。
    7. ゲームクライアントは結果をユーザーに表示します。

    このフローでは、基本アクセス認証またはサーバートークンが使用されます。

    サーバーサイド管理APIコールを使用する際の相互作用フロー:

    1. パートナーは、アプリケーションのクライアントまたはサーバーからエクソーラサーバーにリクエストを送信します。
    2. エクソーラサーバーはリクエストの処理結果を応答として返します。
    このフローでは、基本アクセス認証が使用されます。

    エンドポイントの種類

    エンドポイントのタイプは、どのような種類のデータを処理するのか、どのような処理を実行するのかを示します。最も一般的なアクションは次のとおりです。
    アクション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-サーバーエラーが起きました。
    エクソーラは、従来のHTTPレスポンスコードを使用して、APIリクエストが成功したかどうかを示します。一般的に、2xxは成功を示し、4xxは提供された情報のエラー(例えば、必要なパラメータの欠落、認証の失敗など)を示し、5xxはエクソーラのサーバに関する問題を示します。 しかし、すべてのエラーがHTTPレスポンスコードと完全に一致するわけではありません。たとえば、リクエストが有効であったにもかかわらず失敗した場合、APIは422エラーコードを返します。 すべてのAPIエラーレスポンスは、JSONオブジェクトに次のフィールドを提供します。
    名前種類説明文
    http_status_codeintegerHTTPコード。
    messagestring人間が判読できるエラーの説明。このメッセージは常に英語で表示されます。将来的に変更される可能性があるため、特定のエラーのためにこの値に頼らないでください。
    extended_messagestringより詳細なエラーの説明。
    request_idstringトラブルシューティングに使用する固有のリクエストID。
    Copy
    Full screen
    Small screen
    {
        "http_status_code": 500,
        "message": "Internal Server Error",
        "extended_message": null,
        "request_id": "6445b85"
    }
    

    レート制限

    一般情報

    エクソーラシステムの過負荷を回避し、受信トラフィックのバーストからシステムを保護するために、エクソーラは、指定された期間内に エクソーラAPIによって受信されるリクエストの数を制限します。制限を超えた場合、エクソーラAPIは429ステータスコードでHTTPレスポンスを返します。 制限値は、方式、プロジェクト、その他の要因によって異なります。現在の制限値は、エクソーラシステムの安定的かつ継続的な運用を保証するために定期的に更新されます。場合によっては、事前のリクエストにより、指定された制限を調整することが可能です。カスタマーサクセスマネージャーに連絡するか、メールcsm@xsolla.comまでリクエストを送信してください。

    レート制限を超える一般的な原因

    • パートナー側のトラフィックが急激に増加した原因は以下通り:
      • 季節セール
      • クローズドテストとオープンテストの開始
    • パートナー側でのDDoS攻撃の結果、トラフィックが急激に増加しました。
    • 不適切に構成された統合。例:
      • カタログサブセクションのメソッドの代わりに、頻繁に使用することに対応していない管理者サブセクションのメソッドを使用すること
      • 注文の状態とその中のアイテムのリストを取得するために、注文するメソッドを頻繁に呼び出すこと。例:推奨されるリクエストの遅延時間は3秒ですが、1秒に1回呼び出されます
    • 一定時間内に過剰に多くのリクエストを起動すること。例:アイテムカタログを表示するための仮想アイテムリストを取得メソッドを1秒間に200回以上呼び出すこと。

    レート制限の処理

    レート制限によるエラーを防ぐために、以下のことをお勧めします:
    • 429ステータスコードを追跡し、再試行メカニズムを作成します。連続再試行の代わりに、再試行間に固定または指数バックオフを持つ再試行パターンを使用することができます。
    • 必要なデータのみを取得するようにコードを最適化します。アプリケーションが必要とするリクエストのみを行い、不要なAPIコールを避けるようにします。IGS APIを使用している場合は、WebSocket APIを使用することで呼び出し回数を減らすことができます。
    • アプリケーションで頻繁に使用されるデータをキャッシュします。静的なデータを手元に置いて、外部APIへのリクエストの数を減らすことができます。
    • APIを破壊するDDoS攻撃を防ぐことができます。
    • リクエストのレートを調整することで、よりスムーズな配信が可能になります。429エラーが定期的に発生する場合は、リクエストのレートを調節し、リクエストをより均等に分散できるようなプロセスをコードに含めることを検討してください。

    APIキー

    APIキーは、ユーザーデータの暗号化およびAPIリクエストの認証に使用される一意のキーです。アドミンページでは、会社のすべてのプロジェクトと個々のプロジェクトに対してAPIキーを作成できます。

    お知らせ
    全社のプロジェクトで有効なAPIキーは、個々のプロジェクトのページには表示されません。
    注意

    以下のロールのいずれかに該当する場合、APIキーの操作(リストを表示、作成、または削除する)が可能です:

    • 開発者
    • 所有者

    会社設定 > ユーザーセクションのアドミンページでロールを変更できるのは、プロジェクト所有者のみです。

    APIキーを作成する

    APIキーを作成するには:
    1. アドミンページを開きます。
    2. 会社設定 > APIキーまたはプロジェクト設定 > APIキーセクションに移動します。
    3. APIキーを作成するをクリックします。
    4. 以下のフィルドを入力します:
      • キーのリストに表示されるキーの名前。キーを簡単に識別できるような名前を設定します。
      • キーのタイプ — 永久的または一時的。
      • 有効期限 — 一時的なキーの場合のみです。有効期限を過ぎると、そのキーは無効となり、新たにキーを作成する必要があります。
      • キーが有効なプロジェクト(プロジェクトページでAPIキーを作成しても、このフィールドは表示されません)。デフォルトでは、すべてのプロジェクトが選択されています。
    5. 作成するをクリックします。
    6. 開いたウィンドウで、APIキーをコピーするをクリックし、作成したAPIキーを自分側で保存します。
    お知らせ
    プロジェクトページでAPIキーを作成した場合、そのキーはこの特定のプロジェクト内のみで有効です。
    注意

    キーに関する推奨事項:

    • 生成されたAPIキーは、お客様側で保存してください。APIキーは、アドミンページで作成時に一度だけ表示することができます。
    • APIキーは秘密にしておいてください。APIキーは、お客様の個人アカウントとアドミンページのプロジェクトへのアクセスを提供します。
    • APIキーはサーバーに保存する必要があり、決してバイナリやフロントエンドに保存してはいけません。

    必要なAPIコールにproject_idパスパラメータが含まれていない場合は、会社のすべてのプロジェクトで有効なAPIキーを使用して認証を設定します。

    APIキーを削除する

    APIキーを削除するには:
    1. アドミンページを開きます。
    2. 会社設定 > APIキーまたはプロジェクト設定 > APIキーセクションに移動します。
    3. APIキーの行で、ビンのアイコンをクリックし、動作を確認します。
    以下の場合、APIキーの削除が中止されます:
    • このAPIキーが使われたプロジェクトで支払いを受ける
    • このAPIキーを使用したAPIメソッドを呼び出す
    それを防ぐには:
    1. 新しいAPIキーを作成します
    2. 新しいAPIキーを使用するようにアプリケーションを変更します。
    3. 初期のAPIキーを削除します。

    ウェブフック

    ウェブフックを使用すると、エクソーラ側で構成されたイベントの即時通知を受信できます。処理用エクソーラを設定することで、アプリケーションを自動化することができます。利用可能なウェブフックのリストとその動作の詳細については、当社のドキュメンテーションを参照してください。

    この記事は役に立ちましたか?
    ありがとうございます!
    改善できることはありますか? メッセージ
    申し訳ありません
    この記事が参考にならなかった理由を説明してください。 メッセージ
    ご意見ありがとうございました!
    あなたのメッセージを確認し、体験を向上させるために利用させていただきます。
    最終更新日: 2024年11月18日

    誤字脱字などのテキストエラーを見つけましたか? テキストを選択し、Ctrl+Enterを押します。