一般的な応答の構造

正常な応答は、リクエスト、作成、変更、または削除されたオブジェクトを含む200シリーズのHTTPコードおよびJSONベースのペイロードと、リクエストにおけるサーバーの解釈の記述とともに示されます。

正常なリクエストを発行した場合、応答の一部として、リクエストをエコーバックするrequestノードを受け取ります。

例: GET accounts/abcdefg/campaigns?with_deleted=true

{
  /* the data of your response... */,
  "request": {
    "params": {
      "account_id": "abcdefg",
      "with_deleted": "true"
    }
  }
}

JSON応答のdataフィールドには、活用したリソースに関連した特定のオブジェクトが含まれます。応答に1つ以上の結果が含まれている可能性がある場合、dataノードの形式はJSON配列になります。応答で可能な結果が1つのみの場合、JSONハッシュとして返されます。稀なケースでは、通常はハッシュマップのコレクションが含まれる応答が代わりに表示される場合があります。この場合、ハッシュマップが1つであればtypeフィールドで指定される同じタイプのオブジェクトになると仮定してください。

エラー応答の構造

エラー応答は200シリーズ以外のHTTPコードで表示されます。通常、JSON応答は添付されますが、エラーの中には別のボディで応答することがあります。このような状況では応答の構造が構文解析できないため、HTTPコードの主な意味を優先してください。たとえば、HTTP 404とともにHTML応答が表示される場合があります。この場合、コンテンツが見つからないと仮定できます（HTTP 404は「Not Found（見つかりません）」という意味です）。

通常のエラー応答は、正常な応答と似たような構造に従います。エラーの性質は、応答のerrorsノードで通信されます。errors/codeノードは、プログラムを使って解決策の決定を消費できるCAPS_CASEコンスタントエラーコードを示します。errors/messageノードは（通常）人間が読めるエラーの説明を英語で示します。追加フィールドが添付され、エラーのより具体的な詳細が示される場合があります。

{
  "errors": [
    {
      "parameter": "start_time",
      "details": "invalid date",
      "code": "INVALID_PARAMETER",
      "value": "",
      "message": "Expected time, got "" for start_time"
    }
  ],
  "request": {
    "params": {
      "account_id": "hkk5"
    }
  }
}

上の例では、アナリティクスエンドポイントへのリクエストは、start_timeパラメータに無効な値が入っていました。無効なパラメータがあるリクエストのerrors/codeはINVALID_PARAMETERになります。