> ## Documentation Index
> Fetch the complete documentation index at: https://docs.benzinga.com/llms.txt
> Use this file to discover all available pages before exploring further.

# エラー

> Benzinga API からのエラーおよびステータスコードの扱い方

Benzinga API は、API リクエストの成功または失敗を示すために、標準的な HTTP レスポンスコードを使用します。概要は次のとおりです。

* **2xx**: 成功。
* **4xx**: クライアントエラー（例: パラメータ不足、無効なキー）。
* **5xx**: サーバーエラー（Benzinga 側で問題が発生）。

<Tip>
  リクエストが成功したかどうかを判断する際は、必ず最初に **HTTP ステータスコード** を確認してください。レスポンスボディだけに依存しないでください。フォーマットは API エンドポイントごとに異なる場合があります。
</Tip>

<div id="http-status-codes">
  ## HTTP ステータスコード
</div>

次の表は、遭遇しうる標準的なステータスコードの一覧です。

| Code    | Status                  | Description                                                            |
| :------ | :---------------------- | :--------------------------------------------------------------------- |
| **200** | `OK`                    | リクエストは正常に処理されました。                                                      |
| **400** | `Bad Request`           | リクエストに問題があります。多くの場合、パラメータの欠如または不正が原因です。                                |
| **401** | `Unauthorized`          | 有効な API Key が指定されていません。`Authorization` ヘッダーまたは `token` パラメータを確認してください。 |
| **402** | `Request Failed`        | パラメータは有効ですが、ビジネスロジック上の理由によりリクエストが失敗しました。                               |
| **403** | `Forbidden`             | API Key は有効ですが、このリソースへアクセスする権限がありません。                                  |
| **404** | `Not Found`             | リクエストされたリソース（例: ID、エンドポイント）が存在しません。                                    |
| **429** | `Too Many Requests`     | レート制限の上限を超過しています。                                                      |
| **500** | `Internal Server Error` | Benzinga のサーバー側で問題が発生しました。これはまれに発生します。                                 |
| **503** | `Service Unavailable`   | サービスは一時的に利用できません（例: メンテナンス）。                                           |

<div id="error-response-bodies">
  ## エラーレスポンスボディ
</div>

HTTP ステータスコードはエラーの主な指標ですが、レスポンスボディにはデバッグに役立つ詳細情報が含まれていることがよくあります。このボディの形式は、どの API を呼び出すかによって異なる場合があります。

<div id="format-1-simple-error-message">
  ### フォーマット 1: シンプルなエラーメッセージ
</div>

多くのエンドポイント（News API など）は、シンプルな文字列、またはメッセージを含むフラットな JSON オブジェクトを返します。

```json theme={null}
"Invalid or Missing Query Parameters"
```

または

```json theme={null}
{
  "message": "Invalid page size"
}
```

<div id="format-2-structured-error-object">
  ### フォーマット 2: 構造化エラーオブジェクト
</div>

新しい API（Data API Proxy やファンダメンタルズなど）は、エラーの一覧を含む構造化されたオブジェクトを返します。

```json theme={null}
{
  "data": null,
  "errors": [
    {
      "code": "database_query_error",
      "id": "ERR_12345",
      "value": "シンボルのデータを取得できません: INVALID"
    }
  ],
  "ok": false
}
```

<div id="handling-errors-programmatically">
  ### プログラムでエラーを処理する
</div>

レスポンスボディにばらつきが生じる可能性があるため、堅牢なエラー処理を行うことを推奨します。

1. **HTTP ステータスコードを確認します。** `>= 400` の場合はエラーとして扱います。
2. **レスポンスボディをログに記録します。** デバッグ目的でボディ全体をログに出力します。
3. **汎用的なメッセージを表示します。** 特定のエンドポイントと連携しておらず、その正確なエラー形式を把握していない場合は、ステータスコードとあわせてエンドユーザーに汎用的な「Something went wrong」メッセージを表示します。