Amazon インセンティブ API

Amazon インセンティブ API

連携を開始する前に、必ず Amazon インセンティブ API アカウントを設定してください。インセンティブ API アカウントを作成します


インセンティブ API は、以下のタスクをリアルタイムで実行するために使用できるプログラム的なエンドポイントを提供します。

  • Amazon のウェブサイトで商品を購入するための通貨として使用できるギフト券コードを作成します。
  • 物理的なギフト券を有効にします。
  • アプリまたはウェブサイトを通じてカスタマーアカウントのギフト券の残高を入金します。
  • 実店舗でカスタマーアカウントのギフト券の残高を入金します。

ユーザーのソフトウェアは、インセンティブ API エンドポイントへの同期リクエストを行うことができます。リクエストがギフト券コードになった場合は、Amazon が承認した方法で顧客にコードを提供できます。

エンドポイント

ユーザーのプログラムからインセンティブ API へのリクエストには、完全なエンドポイントアドレスの一部である、基礎となる URL が含まれます。ユーザーのプログラムは、運用する国に応じて決まる 1 つの基礎となる URL にリクエストを送信します。また、インセンティブ API エンドポイントを、影響なく呼び出せるサンドボックスも提供しています。次の表は、インセンティブ API が使用可能な国のサンドボックスと本番環境の基礎となる URL の値を示しています。

注: これらのエンドポイントの基になる IP アドレスは、地理と負荷に基づいて頻繁に変更されます。ユーザーのプログラムやファイアウォールのホワイトリストに IP アドレスをハードコードしないでください。エンドポイントに到達するには、ここに示す完全な DNS アドレスのみを使用してください。

サンドボックスエンドポイント

ベースエンドポイント URL
北米
(米国、カナダ、メキシコ)
https://agcod-v2-gamma.amazon.com
(リージョン:US-East-1)
欧州
(イタリア、スペイン、ドイツ、フランス、イギリス、トルコ、アラブ首長国連邦)
https://agcod-v2-eu-gamma.amazon.com
(リージョン:eu-west-1)
極東
(日本、オーストラリア)
https://agcod-v2-fe-gamma.amazon.com
(リージョン:us-west-2)

本番環境エンドポイント

ベースエンドポイント URL
北米
(米国、カナダ、メキシコ)
https://agcod-v2.amazon.com
(リージョン:US-East-1)
欧州
(イタリア、スペイン、ドイツ、フランス、イギリス、トルコ、アラブ首長国連邦)
https://agcod-v2-eu.amazon.com
(リージョン:eu-west-1)
極東
(日本、オーストラリア)
https://agcod-v2-fe.amazon.com
(リージョン:us-west-2)

インセンティブ API へのリクエストの作成

インセンティブ API のエンドポイントへのすべてのリクエストは、インセンティブ API のセキュリティ認証情報と署名バージョン 4 の署名アルゴリズムを使用してデジタル署名する必要があります。署名バージョン 4 を使用して正しく署名することは、インセンティブ API エンドポイントを呼び出すときの最も難しいハードルになる可能性があります。このセクションでは、署名コードの構築に使用するリソースについて説明します。

インセンティブ API スクラッチパッド

インセンティブ API スクラッチパッドを使用して、サンドボックスでいくつかのインセンティブ API 操作を呼び出すことができます。このツールは、リクエストとレスポンスの詳細を明示するので、インセンティブ API 操作への呼び出しがどのように見えるか実際にやってみることができます。

注: JSON 本体でリクエストを渡すと、スクラッチパッドは application/json に設定されている content_type ヘッダーを表示しません。

AWS 署名バージョン 4 のサンプルコード

署名バージョン 4 は AWS の標準仕様です。AWS ドキュメントには、この署名を使用して操作を呼び出すことができるコードスニペットが含まれています。次の表は、完全なバージョン 4 署名プロセスの例にある Python POST のサンプルで変更できるパラメータを示しています。これらの変更により、Python コードは JSON 本体を使用して、北米サンドボックス内の CreateGiftCard 操作を呼び出します。

パラメータ value
service AGCODService
host agcod-v2-gamma.amazon.com
region us-east-1
endpoint https://agcod-v2-gamma.amazon.com/CreateGiftCard
content_type application/json
amz_target com.amazonaws.agcod.AGCODService.CreateGiftCard
request_parameters (JSON 本体を使用するインセンティブ API スクラッチパッドで作成されたリクエストから本文をコピーする)
access_key, secret_key キーを提供する
canonical_url /CreateGiftCard

また、Java、C#、Python、Ruby、JavaScript で追加のスニペットを利用できます。 署名バージョン 4 の署名キーを取得する方法の例

インセンティブ API のサンプル

また、Java、C#、Python、Ruby、PHP、HTML (JavaScript) のサンプルコードも提供しています。これらのサンプルは、ほとんどのインセンティブ API 操作を呼び出すようにカスタマイズされています。

注:

  • サンプルコードは適切なエラー処理機能がないため、「本番環境向け」ではありません。ガイドとしてのみ使用してください。
  • シークレットキー/アクセスキー/PartnerId は、このソースコードにクリアテキストで表示されます。
  • ソースコードとその中にある機密情報は、未処理のエラーがプログラムの非決定的な動作につながる場合など、いくつかのシナリオで明らかになる可能性があります。

テストを行う前に、独自の値を使用して、次のパラメータに指定します。

  • partnerId:Acme1
  • currencyCode:米国ドルには USD、欧州ユーロには EU、日本円には JPY、カナダドルには CA、オーストラリアドルには AU、トルコリラには TRY、UAE ディルハムには AED
  • agcodAccessKey:あなたのセキュリティクレデンシャル
  • agcodSecretKey:あなたのセキュリティクレデンシャル
  • regionus-east-1 (場所と環境によって異なります。リージョンとエンドポイントを参照)
  • endpoint:(場所と環境によって異なります。リージョンとエンドポイントを参照)

共通のリクエストヘッダー

インセンティブ API は、各 HTTP リクエストに次のヘッダーを必要とします。

ヘッダー 説明/値
メソッド POST
host [リージョンとエンドポイント] の下に表示されるゲートウェイエンドポイント。
x-amz-date/date x-amz-date または日付ヘッダーを使用して指定された署名の作成に使用される日付。フォーマットは ISO 8601 基本フォーマット(YYYYMMDD'T'HHMMSS'Z') でなければなりません。詳細については、以下を参照してください。
x-amz-target com.amazonaws.agcod.AGCODService.<operation>
ログイン&レシーブは、次の操作を提供します。 LoadAmazonBalance、VoidAmazonBalanceLoad、GetAvailableFunds
Authorization リクエストの認証に必要な情報は次を含みます。 AWS4-HMAC-SHA256、認証情報、署名ヘッダー、および署名。このヘッダーの作成の詳細については、「リクエストの署名」を参照してください。
accept */*に設定すると、既定値は XML になります。結果を JSON 本体として受け取るには、application/jsonに設定します。
content-type application/json または application/xml
regionName リージョンの端点。下記のリージョンとエンドポイントの表を参照してください。
serviceName サービスの名前、AGCODService

x-amz-date/date の場合、次の日付時刻は有効な x-amz-date 値です。 20120325T120000Z。x-amz-date ヘッダーは、すべてのリクエストに対して任意のオプションです。date ヘッダーが ISO 8601 の基本形式で指定されている場合、x-amz-date は必須ではありません。詳細については、AWS 全般のリファレンスの「署名バージョン 4 の日付の処理」を参照してください。タイムスタンプは、リクエストが受信された Amazon のシステム時刻から 15 分以内である必要があります。そうでない場合、リクエストは RequestExpired エラーコードで失敗し、他のユーザーがリクエストをできないようにします。

署名バージョン 4 の実装

上記のサンプルは、シナリオをカバーしていない可能性があります。署名バージョン 4 を最初から実装するには、まず次のトピックを学習してください。

ユーザーのプログラムが送信するすべての REST 操作リクエストに署名を含める必要があります。リクエストに署名するには、リクエストのテキストとシークレットアクセスキーを含む文字列を作成します。この文字列は、ハッシュ値を返す暗号化ハッシュ関数に渡します。このハッシュ値は、REST 操作リクエストの Authorization ヘッダーの Signature フィールドに含めます。リクエストを処理する前に、当社のサービスは同じ入力を使用して署名を再計算し、認証ハッシュ値が当社独自の計算と一致することを確認します。

API ゲートウェイは、AWS 署名バージョン 4 を使用した認証をサポートします。署名を計算するプロセスは、次の 3 つのタスクに分けることができます。

タスク 1: 正規リクエストの作成

AWS 全般リファレンスの「タスク 1: 署名バージョン 4 の正規リクエストを作成する」で説明されている正規形式で HTTP リクエストを作成します。

タスク 2: 署名する文字列の作成

暗号化ハッシュ関数への入力値の 1 つとして使用する文字列を作成します。署名する文字列と呼ばれる文字列は、ハッシュアルゴリズムの名前、リクエストの日付、認証情報スコープ文字列、および前のタスクからの正規リクエストを連結したものです。認証情報スコープの文字列自体は、日付、リージョン、およびサービス情報の連結です。

x-amz-credential パラメータには、リクエストを送信するエンドポイントのコード (例:us-east-1) を指定します。エンドポイントテーブルでリージョンを見つけます。例:

x-amz-credential=AKIAIGHKAVYIDBOH3O3A/20170118/us-east-1/AGCODService/aws4_request

重要: リージョン、サービス名、および特別な終了文字列には小文字を使用する必要があります。 x-amz-credential ヘッダーは、認証パラメータがクエリ文字列に追加されるときに使用されます。これらは単一の認証ヘッダーに簡単に追加され、そのインスタンスでは x-amz-credential は表示されません。したがって、特定のインスタンスでのみ使用され、必須ではないキーワードである x-amz-credential に関する記述には注意してください。この値は必須ですが、x-amz-credential は、クエリ文字列パラメータを使用して認証を行う場合にのみ必要です。

タスク 3: 署名の作成

署名する文字列と派生キーの 2 つの入力文字列を受け入れる暗号化ハッシュ関数を使用して、リクエストの署名を作成します。派生キーは、シークレットアクセスキーから開始し、認証情報スコープの文字列を使用して一連のハッシュベースのメッセージ認証コード (HMAC) を作成することによって計算されます。次の図は、署名を計算する一般的なプロセスを示しています。

署名済みリクエストの例

署名するペイロード

{"loadBalanceRequestId":"Amazon123456","partnerId":"Amazon","amount":{"currencyCode":"USD","value":"1000"},"transactionSource":{"sourceId":"Customer Service"},"account":{"id":"amz1.account.123512341234","type":"2"}}

ハッシュ化されたペイロード

24921f8ae68d62e1d96fd98e33f28da3e52826f43c5fa0389bfa33817e2711a1 

正規リクエスト (空の行を含む)

POST /LoadAmazonBalance

accept: application/json
content-type: application/json
host: agcod-v2-gamma.amazon.com
x-amz-date: 20160708T073147Z
x-amz-target: com.amazonaws.agcod.AGCODService.LoadAmazonBalance

accept;content-type;host;x-amz-date;x-amz-target 24921f8ae68d62e1d96fd98e33f28da3e52826f43c5fa0389bfa33817e2711a1

ハッシュ化された正規リクエスト

a6a2e4283152cbcc7114409dfbc3dda721663f4bb14b6e34f8e1f71c374f9c14 

署名する文字列

AWS4-HMAC-SHA256 
20160708T073147Z 
20160708/us-east-1/AGCODService/aws4_request 
a6a2e4283152cbcc7114409dfbc3dda721663f4bb14b6e34f8e1f71c374f9c14 

派生した署名キー

780860beb9efce461eaee56c38d7f904cf1b803cd9ea6f2c3402415b92af9453 

署名

セキュリティアクセスキーの認証情報が異なるため、署名は異なります。ただし、次の形式に従います。

66bd6a9ee258bcc34b7c0084ef871f2cb734e579b26f62ffce3ca1a33c06074a

署名済みペイロード

POST /LoadAmazonBalance HTTP/1.1 
accept:application/json 
content-type:application/json 
host:agcod-v2-gamma.amazon.com 
x-amz-date:20160708T073147Z 
x-amz-target:com.amazonaws.agcod.AGCODService.LoadAmazonBalance 
Authorization:AWS4-HMAC-SHA256 Credential=<AWS Key Id used for signing>/20160708/useast-1/AGCODService/aws4_request, SignedHeaders=accept;content-type;host;x-amz-date;x-amz-target, Signature=66bd6a9ee258bcc34b7c0084ef871f2cb734e579b26f62ffce3ca1a33c06074a 
{"loadBalanceRequestId":"Amazon123456","partnerId":"Amazon","amount":{"currencyCode":"USD","value":"1000"},"transactionSource":{"sourceId":"Customer Service"},"account":{"id":"amz1.account.123512341234","type":"2"}}

エラーの処理

Web サービスゲートウェイから送信される各レスポンスには、特定の操作の実行ステータスを説明するステータス要素が関連付けられています。ステータス値は SUCCESSFAILURERESEND の 3 つがあります。再試行ロジックを使用して RESEND の結果を処理する方法などの説明については、「エラー処理」を参照してください。

署名コードのトラブルシューティング

次の一般的なコーディングエラーを確認してください。http://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html

一般的なコーディングエラーは次のとおりです。

  • 中間キーを計算するときに、誤ってキーとデータを交換する。前のステップの計算結果がキーで、データではありません。暗号プリミティブのマニュアルを慎重に確認して、パラメータを適切な順序で配置してください。
  • 最初のステップで、キーの前に文字列「AWS」を付加することを忘れる。「for ループ」またはイテレータを使用して派生したキーを実装することは可能です。その場合、最初のイテレーションに「AWS」文字列を含めるように特別なケースを忘れないでください。
  • JavaScript の HMAC.Crypto 関数に asBytes オプションを使用することを忘れている。asBytes オプションを使用しない場合、HMAC 実装はデフォルトで追加の 16 進エンコーディングを実行します。
  • リクエスト内のクエリ文字列が正しくソートおよびエンコードされ、ヘッダー名も小文字に変換され、ヘッダーが文字コードでソートされていることを確認します。「署名バージョン 4 の正規リクエストを作成する」を参照してください。
  • JSON 本文リクエストの場合、application/json に設定された content_type のみが成功します。

セキュアなデータ転送

インセンティブ API エンドポイントは、セキュアポート (HTTPS) を介してのみ開放され、このチャネル上のすべてのトラフィックは、SSL/TLS 1.2 を使用して保護されます。この業界標準のプロトコルは、転送中にギフト券のデータを暗号化します。SSL/TLS 1.2 で使用される暗号化キーへの不正アクセスを防ぐために、システム内に独自の安全なメカニズムを提供する必要があります。

重要: API リクエストでは、TLS 1.2 以上を使用する必要があります。

API レスポンスの変更

インセンティブ API エンドポイントからのレスポンスには、XML または JSON データ交換形式の情報が含まれることがよくあります。今後、これらのレスポンスに新しい属性が追加され、要素が異なる順序で表示される可能性があります。ユーザーのプログラムは、XML または JSON パーサーを使用して、レスポンス本文の XML または JSON が今後の変更を適切に対応できるようにしてください。たとえば、XPath は、式の構文を使用して XML コンテンツから値を解析します。パーサーライブラリは、XML または JSON レスポンス本文のスキーマが変更または拡張された場合に、より信頼性が高くなります。

インセンティブ API ポータル

インセンティブ API ポータルでは、次の操作を行うことできます。

  • アカウントの残高、1 日の平均使用量 (過去 14 日間)、残り日数 (平均使用量に基づく)、およびアラートを表示します。
  • ブラウザまたはダウンロードとして、詳細なトランザクションアクティビティを表示します。
  • 低残高のアラートを設定します。
  • 支払いが完了したことを Amazon に通知します。
  • (管理者のみ) 新しいアクセスキーを作成し、既存のキーを制御します。

キーの取り扱い

アクセスキーは、インセンティブ API エンドポイントへのプログラムリクエストを署名するために使用する認証情報です。ユーザー名とパスワードと同様に、すべてのリクエストの認証において、アクセスキー ID とシークレットアクセスキーの両方を同時に使用する必要があります。

管理者権限を持つパートナーアカウントは、インセンティブ API ポータル内の API セキュリティ認証情報ページから新しいアクセスキーと既存のキーを制御できます。(管理者権限を持たないパートナーアカウントは、このページを表示できません。アカウント管理者のアクセス権の付与を依頼する場合は、incentives-api@amazon.com にメールでお問い合わせください。

認証情報のセキュリティ

API セキュリティ認証情報ページで提供されるアクセスキーとシークレットキーは、不正アクセスや偶発的なリリースから保護する必要があります。これは、本番環境とサンドボックスの認証情報の両方に該当します。システムと資金のセキュリティは、これらの機密情報の安全な取り扱いに依存しています。キーを共有しないでください。

キーのローテーション

アクセスキーを定期的に変更することは、キーの不正使用によるビジネスへの影響を軽減する、セキュリティ上のベストプラクティスとしてよく知られています。セキュリティ上のベストプラクティスとして、アクセスキーを定期的にローテーション (変更) することをお勧めします。確立されたプロセスを定期的に実行することにより、キーのローテーションに関する運用手順も検証されます。したがって、キーを変更することが組織にとって危険な手順になることはありません。

少なくとも 180日 (6 ヶ月) に 1 回、アクセスキーを変更することをお勧めします。プロセスを開始するためのリマインダーとして、キーをローテーションする 30 日前にメールが届きます。ご不明な点がございましたら、アカウントマネージャーまたは incentives-api@amazon.com にお問い合わせください。

アクセスキーをローテーションするには、次の手順を実行します。

  1. インセンティブ API ポータルで、「セキュリティ認証情報」をクリックします。
  2. 新しいアクセスキーを作成する」をクリックします。
  3. 新しいアクセスキーを使用するようにすべてのアプリケーションを更新します。
  4. 新しいキー値を使用して、インセンティブ API 操作へのすべてのリクエストが成功していることを確認します。
  5. 元のキーに対して「無効化」をクリックします。
  6. 新しいキー値を使用して、インセンティブ API 操作へのすべてのリクエストが成功したことをもう一度確認します。正しく設定されていることを必ず確認してください。 一度削除したアクセスキーは復元できません。
  7. 元のキーに対して「削除」をクリックします。

新しいキーが使用されるようになり、元のキーは非アクティブになり、再度使用することはできません。

データストレージのガイドライン

このセクションでは、CreateGiftCard の結果を処理するためのベストプラクティス、特に gcClaimCode の値を説明します。

また、法人向け Amazon ギフト券の購入および配布規約の情報セキュリティ要件 (Amazon インセンティブ API サービス規約にある法人向けギフト券ポリシーのセキュリティベストプラクティスなど) も確認してください。

https://www.amazon.com/gp/help/customer/display.html?nodeId=202120960

以下は、CreateGiftCard への呼び出しが成功した場合に返される Amazon ギフト券コードをリクエストおよび保存するためのガイドラインです。

  • クライアントコードは、CreateGiftCard 操作の新しい呼び出しごとに、一意の creationRequestId 値を生成します。
  • クライアントコードは、各リクエストで使用されるcreationRequestId、金額、および通貨コード値を格納する必要があります。
  • Amazon は、すべての gcClaimCode を保存します。ギフト券のコードを生成した後、ユーザーのプログラムでは同じ creationRequestId金額通貨コードを使用して CreateGiftCard に新しいリクエストを送信することで、同じギフト券コードを再度取得できます。これは、Amazon ギフト券コードをデータベースに保存するよりは安全な方法です。
  • Amazon ギフト券コードは保存しないでください。ユーザーのプログラムで Amazon ギフト券コードが一時的に保持されている場合は、Amazon ギフト券コードを顧客に送信した後に、これらの値を破棄する必要があります。(「セキュリティ」を参照してください。)
  • ギフト券コードをキャンセルする必要がある場合、ユーザーのプログラムではコード作成から 15 分以内に CancelGiftCard を呼び出す必要があります。

スロットルレート

AGCOD は、システムの誤用を防ぐために、着信リクエストを抑制/拒否します。リクエストレートは、すべてのトランザクションタイプを含み、1 秒あたり 10 を超えることはできません。

API スロットルレート (リクエスト数)
CreateGiftCard
(Web 作成 API を使用している場合にのみ適用)
10/秒
CancelGiftCard
(Web 作成 API を使用している場合にのみ適用)
10/秒
ActivateGiftCard
(Web アクティベーション API を使用している場合にのみ適用)
10/秒
DeactivateGiftCard
(Web アクティベーション API を使用している場合にのみ適用)
10/秒
ActivationStatusCheck
(Web アクティベーション API を使用している場合にのみ適用)
10/秒

ユーザーのプログラムからのリクエストがスロットルレートを超えると、リクエストは失敗し、ThrottlingException が返されます。

<ThrottlingException>
  <Message>Rate exceeded</Message>
</ThrottlingException>

エラー処理

AGCOD ゲートウェイから送信されるすべてのレスポンスには、特定の操作の実行ステータスを記述する Status 要素が関連付けられています。statusCode には、次の 3 つの値があります。 SUCCESSFAILURERESEND

SUCCESS

操作が成功すると、操作のレスポンスには SUCCESSstatusCode 値が含まれます。


FAILURE

インセンティブ API でリクエストを受け付けられない場合、操作のレスポンスには FAILUREstatusCode が含まれます。このステータスレスポンスには、無効なリクエストデータや、パートナーが確認する必要があるビジネスロジックエラーが含まれる場合があります。このような場合は、errorCode フィールドが入力され、エラーに関する追加の詳細が表示されます。


RESEND

操作のレスポンスには、RESENDstatusCode と F400 エラーが含まれます。一時的なシステム障害は、リクエストを再試行することで解決できます。F400 エラーは「不明な状態」であり、アカウントに課金される可能性があるため、ユーザーのプログラムで再試行ロジックを提供することが重要です。RESEND エラーは、失敗として解釈されるべきではありません。

注: 次の手順は、ActivateGiftCard/DeactivateGiftCard への呼び出しのためのバックオフ方法を示します。また、ユーザーのプログラムでこのバックオフ方法を使用して、CreateGiftCard/CancelGiftCardLoadAmazonBalance/VoidAmazonBalanceLoadへの呼び出しを行います。

  1. リクエストから F400 エラーメッセージが返された場合、同じ ActivateGiftCard 操作を再試行できる場合は、操作を再試行してください。再試行できない場合は、ステップ 2 に進みます。
  2. 同じ *requestId 値を使用して、DeactivateGiftCard 操作を送信します。
  3. DeactivateGiftCard の呼び出しがSUCCESS を返した場合は、新しい*requestId 値を使用して ActivateGiftCard をもう一度呼び出します。
  4. DeactivateGiftCard の呼び出しが失敗した場合は、1 秒を一時停止して、同じ DeactivateGiftCard リクエストをもう一度送信します。
  5. DeactivateGiftCard リクエストが成功しないで 10 秒が経過した場合は、指数関数的なバックオフスキームを使用して遅延を増やします。
  6. 24 時間後、再試行を中止し、失敗した操作の詳細が記載されたメールを Amazon に送信してください。

エラーコード

エラーがユーザーのリクエストにある場合は F2XX系のエラーコードを使用してエラーを示し、原因が Amazon にある場合は F1XX系のエラーコードを使用してエラーを示します。

Create/Cancel の呼び出しでの特定のエラーレスポンスをシミュレートするために、モックエラーリクエスト ID を提供しました。エラーレスポンスをシミュレートする場合、通常のリクエスト IDと同様に、モックエラーリクエスト ID を creationRequestId フィールドに渡す必要があります。残りのフィールドに渡された値は、レスポンスでそのまま返されるだけです。成功したレスポンスをシミュレートするために、F1000 の値をモックエラーリクエスト ID に渡すことができます。詳細については、「モックテスト例」のセクションを参照してください。

Amazon のテクニカルサポートへのお問い合わせ (有効な契約/規約への同意が必要)

開発と連携のプロセス全体を通して、技術的な質問はAmazon に問合せすることができます。

有効な契約がなく、サンドボックスのアクセスが許可されていない場合、この宛先の担当者には認識されない可能性があります。アカウントマネージャと協力して、サンドボックスにアクセスするために必要な手順に従うことが重要です。

開発者がアカウントを簡単に識別できるようにするため、開発者との連絡にパートナー ID を含めることが重要です。ご連絡の際には、以下の情報をできるだけ多くご提供ください (該当する場合)

  • インセンティブ API への呼び出しのリクエスト/レスポンスのすべてのペア
  • リクエストを行うために使用される完全なエンドポイント URL (サーバ URL を含む)
  • 上記のリクエスト/レスポンスにない場合、リクエストで使用される StringToSign
  • 上記のリクエスト/レスポンスにない場合、使用される StringToSign 値の対応する署名
  • リクエストで使用されたおおよその時間 (タイムゾーンも含む) (上記のリクエストを行うマシンで設定されたタイムゾーン)
  • 使用したプログラミング言語
  • お客様の側で最近行われた変更 (プログラミングとインフラストラクチャの両方)
  • エラーのスクリーンショット

法律上の注意事項

インセンティブ API と連携して使用することにより、(お客様自身またはお客様が代表する事業に代わって) https://www.amazon.com/gp/help/customer/display.html?nodeId=202120960にある法人向けAmazonギフト券の購入および配布規約に拘束されることに同意したものとみなされます。