概要
- calendar およびシグナルのカバレッジをスコープとして設定でき、必要なデータのみを受信可能
- 重複排除のための一意な
X-BZ-Deliveryヘッダーおよびペイロードのidフィールドによる冪等な配信 - 高頻度の指数バックオフから、長時間にわたる毎時の再試行まで段階的に拡張される堅牢な再試行スケジュール
- 下流システムの要件にペイロード形式を合わせるためのオプションの content 変換
Webhook の配信
HTTP リクエストの詳細
- Method:
POST - Content-Type:
application/json - User-Agent:
Benzinga-Dispatch/v1.0.0 {build-version} - Custom Header:
X-BZ-Delivery- 各配信試行ごとに固有の UUID(重複排除に利用可能)
再試行ポリシー
- 指数フェーズ:最初の5分間で15回再試行
- 追加の指数再試行:必要に応じて追加で11回再試行
- 固定間隔フェーズ:長期的な再試行として、1時間あたり12回 × 24時間/日 × 7日間の再試行
- 最大待機時間:指数フェーズにおける再試行間隔の最大値は5分
- リクエストのタイムアウト:1リクエストあたり30秒
レスポンス要件
- 成功コード (200-202, 204): 配信が成功したことを示します。再試行は行われません。
- クライアントエラーコード (401-403): 認証/認可の失敗を示します。これ以上失敗を重ねないよう、再試行は即座に停止されます。
- その他のコード (4xx, 5xx): 上記の再試行ポリシーに従って再試行が行われます。
Webhook ペイロード構造
ペイロードのフィールド
トップレベルのフィールド
id(string, UUID): この webhook 配信の一意の識別子です。重複排除に使用します。api_version(string): API のバージョン識別子です。現在は"webhook/v1"です。kind(string): データ種別のパス識別子です。取り得るすべての値については Supported Data Types を参照してください。
データオブジェクト
action(string): イベントアクションの種別。取りうる値は次のとおりです:"Created": 新しいデータが作成された(新しい webhook キーのデフォルト)"Updated": 既存のデータが更新された"Removed": データが削除された- 注意: レガシー webhook キーでは、小文字の
"created","updated","removed"が返される場合があります
id(string): calendar/signal レコードの一意の識別子timestamp(string, ISO 8601): webhook が生成された時刻のタイムスタンプcontent(object): 実際の calendar または signal データ。構造はデータ種別によって異なります(Supported Data Types を参照)
サポートされているデータタイプ
カレンダーのデータタイプ (v2.1)
| データタイプ | kind パス | 説明 |
|---|---|---|
| Earnings | data/v2.1/calendar/earnings | 企業の決算発表 |
| Dividends | data/v2.1/calendar/dividends | 配当の発表および支払い |
| Ratings | data/v2.1/calendar/ratings | アナリストのレーティングおよび目標株価 |
| IPOs | data/v2.1/calendar/ipos | 新規株式公開(IPO) |
| Guidance | data/v2.1/calendar/guidance | 企業ガイダンスの更新 |
| Conference | data/v2.1/calendar/conference | カンファレンスコールおよびプレゼンテーション |
| Economics | data/v2.1/calendar/economics | 経済指標および関連リリース |
| Offerings | data/v2.1/calendar/offerings | セカンダリーオファリング |
| Mergers & Acquisitions | data/v2.1/calendar/ma | M&Aの発表 |
| Retail | data/v2.1/calendar/retail | 小売売上高データ |
| Splits | data/v2.1/calendar/splits | 株式分割 |
| FDA | data/v2.1/calendar/fda | FDAによる承認および発表 |
シグナルデータタイプ (v1)
| データタイプ | kind パス | 説明 |
|---|---|---|
| オプションアクティビティ | data/v1/signal/option_activity | 異常なオプション取引 |
| WIIMs | data/v1/wiims | Why Is It Moving (WIIMs) データ |
| SEC インサイダー取引 | data/v1/sec/insider_transactions/filings | SEC インサイダー取引に関する提出書類 |
| 政府関連取引 | data/v1/gov/usa/congress | 米国連邦議会議員の取引データ |
追加データタイプ (v1)
| データタイプ | Kind Path | 説明 |
|---|---|---|
| Bulls Say Bears Say | data/v1/bulls_bears_say | 市場センチメント分析 |
| Bulls Say Bears Say (Korean) | data/v1/bulls_bears_say/korean | 韓国市場のセンチメント分析 |
| Analyst Insights | data/v1/analyst/insights | アナリストの見解とコメント |
| Consensus Ratings | data/v1/consensus-ratings | 集計されたコンセンサス・レーティング |
content の構造例
決算の例
配当の例
レーティングの例
オプション取引アクティビティの例
イベントアクション
- Created: 新しい calendar またはシグナルデータが公開されたときにトリガーされます
- Updated: 既存データが更新されたときにトリガーされます
- Removed: データが削除されたときにトリガーされます
- 新しい webhook キー: 先頭が大文字のアクション(
"Created","Updated","Removed")を受信します - レガシー webhook キー: 小文字のアクション(
"created","updated","removed")を受信します
コンテンツ フィルタリング
フィルターオプション
- データ種別: 特定の calendar/シグナル種別でフィルタリング(例: 決算のみ、レーティングのみ)
- 地域フィルター: 次のデータの受信有無を制御:
- 米国市場データ (
AllowUSA) - カナダ市場データ (
AllowCanada) - インド市場データ (
AllowIndia) - WIIMs データ向け
- 米国市場データ (
- 日付フィルター: 指定した日付より古い履歴データを除外(
MaxHistoricalDate)
exchange によるフィルタリング
- 米国の取引所: NYSE, NASDAQ, AMEX, ARCA, OTC, OTCBB, PINX, PINK, BATS, IEX
- カナダの取引所: TSX, TSXV, CSE, CNSX
コンテンツ変換
- フィールド名の変更
- データ形式の変換
- フィールドのフィルタリング/削除
ベストプラクティス
1. 冪等性
id フィールド(UUID)を使用して冪等性を実装します。重複処理を避けるために、処理済みの配信 ID を保存してください。
2. レスポンス処理
- Webhook を受信したら、すぐに
200 OKまたは204 No Contentを返す - 必要に応じて、データは非同期で処理する
- レスポンスを返す前に時間のかかる処理を行わない
3. エラー処理
- 適切な HTTP ステータスコードを返す
- 認証エラー(401~403)の場合は、エンドポイントが正しく構成されていることを確認する
- 一時的な障害が発生した場合は、リトライをトリガーするために 5xx ステータスコードを返す
4. セキュリティ
- Webhook エンドポイントには HTTPS を使用する
- 認証・認可(API キーやトークンなど)を実装する
- セキュリティを強化するために
X-BZ-Deliveryヘッダーを検証する
5. 監視
- エンドポイントのレスポンス時間を監視する
- 繰り返し発生する失敗に対するアラートを設定する
- 配信試行を特定するために
X-BZ-Deliveryヘッダーを追跡する
6. データ型の処理
- データ型を判別するために
kindフィールドを確認する - データ型の構造に基づいて
contentオブジェクトを解析する - レガシーキーをサポートする場合は、アクション形式の違い(先頭大文字 vs 小文字のみ)を考慮して処理する
Webhook ハンドラの例
Python (Flask)
Node.js (Express)
Go
トラブルシューティング
よくある問題
-
Webhook が届かない
- Webhook の URL が正しく設定されているか確認する
- エンドポイントが外部からアクセス可能か確認する
- API キーが有効でアクティブであることを確認する
- フィルター設定によってすべてのデータタイプが除外されていないか確認する
- 地理的フィルターが期待するデータの地域設定と一致しているか確認する
-
配信が重複する
idフィールドを使って冪等性を実装する- エンドポイントのレスポンス時間を確認する(レスポンスが遅いと再試行が発生する場合があります)
-
認証エラー (401-403)
- エンドポイントの認証設定を確認する
- API キーとトークンを確認する
- 注意:認証エラーが発生すると再試行は即座に停止します
-
タイムアウトエラー
- エンドポイントが 30 秒以内にレスポンスを返すことを確認する
- 必要に応じてデータを非同期で処理する
- 成功ステータスを即座に返し、その後で処理を行う
-
予期しないアクション形式
- レガシーな Webhook キー(アクションが小文字)を使用していないか確認する
- アクションを大文字で受信するには新しい Webhook キーへ更新する
- 複数クライアントをサポートする場合は両方の形式に対応する
-
データタイプが欠落している
- Webhook 設定に必要なデータタイプが含まれているか確認する
- 地理的フィルター(US/Canada/India の設定)を確認する
- 日付フィルターによって最新データが除外されていないか確認する
サポート
- Benzinga API ドキュメント を確認する
- Benzinga のアカウント担当者に連絡する
- 連携チームと webhook の設定を見直す
バージョン履歴
- v1.0.0: データ Webhook サービスの初回リリース
- 最新: フィルタリング、変換、リトライ機構の強化