개요
- calendar 및 시그널 범위를 설정해 필요한 데이터만 수신
- 중복 제거를 위해 고유한
X-BZ-Delivery헤더와 페이로드id필드를 사용하는 멱등 전달 - 빠른 지수 백오프 재시도에서 장기 시간 간격(시간 단위) 재시도로 이어지는 견고한 재시도 스케줄
- 다운스트림 시스템의 요구사항에 맞추기 위한 선택적 content 변환 기능
웹훅 전송
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회 추가 재시도
- 고정 간격 단계: 장기 재시도를 위해 시간당 12회 × 하루 24시간 × 7일 동안 재시도
- 최대 대기 시간: 지수 단계에서 재시도 간 대기 시간은 최대 5분
- 요청 타임아웃: 요청당 30초
응답 요구 사항
- 성공 코드 (200-202, 204): 웹훅이 성공적으로 처리되었음을 의미합니다. 재시도는 수행되지 않습니다.
- 클라이언트 오류 코드 (401-403): 인증/인가 실패를 의미합니다. 추가 실패 시도를 방지하기 위해 재시도는 즉시 중단됩니다.
- 기타 코드 (4xx, 5xx): 위에서 설명한 재시도 정책에 따라 재시도가 트리거됩니다.
Webhook Payload 구조
페이로드 필드
최상위 필드
id(string, UUID): 해당 webhook 전송의 고유 식별자입니다. 중복 제거를 위해 이 값을 사용하십시오.api_version(string): API 버전 식별자입니다. 현재 값은"webhook/v1"입니다.kind(string): 데이터 유형 경로 식별자입니다. 가능한 모든 값은 지원되는 데이터 유형을 참조하십시오.
데이터 객체
action(string): 이벤트 action 유형. 가능한 값:"Created": 새로운 데이터가 생성됨 (새 webhook 키의 기본값)"Updated": 기존 데이터가 업데이트됨"Removed": 데이터가 제거됨- 참고: 레거시 webhook 키는 소문자 값
"created","updated","removed"를 받을 수 있음
id(string): calendar/signal 레코드의 고유 식별자timestamp(string, ISO 8601): webhook이 생성된 시점의 타임스탬프content(object): 실제 calendar 또는 signal 데이터. 구조는 데이터 유형에 따라 달라짐 (지원되는 데이터 유형 참조)
지원되는 데이터 유형
캘린더 데이터 유형 (v2.1)
시그널 데이터 타입 (v1)
추가 데이터 유형 (v1)
content 구조 예제
실적 예제
배당 예시
Ratings 예시
옵션 거래 동향 예시
이벤트 action
- Created: 새로운 calendar 또는 signal 데이터가 게시될 때 발생합니다
- Updated: 기존 데이터가 수정될 때 발생합니다
- Removed: 데이터가 삭제될 때 발생합니다
action 형식은 webhook 구성에 따라 달라집니다:
- 새 webhook 키: 대문자로 된 action을 수신합니다 (
"Created","Updated","Removed") - 레거시 webhook 키: 소문자로 된 action을 수신합니다 (
"created","updated","removed")
콘텐츠 필터링
필터 옵션
- 데이터 유형: 특정 calendar/시그널 유형으로 필터링 (예: 실적만, 리서치 의견만)
- 지리적 필터: 다음 데이터 수신 여부를 제어:
- 미국 시장 데이터 (
AllowUSA) - 캐나다 시장 데이터 (
AllowCanada) - 인도 시장 데이터 (
AllowIndia) - WIIMs 데이터용
- 미국 시장 데이터 (
- 날짜 필터: 지정한 날짜보다 이전의 과거 데이터 제외 (
MaxHistoricalDate)
Exchange 필터링
- 미국 거래소(US Exchanges): NYSE, NASDAQ, AMEX, ARCA, OTC, OTCBB, PINX, PINK, BATS, IEX
- 캐나다 거래소(Canadian Exchanges): TSX, TSXV, CSE, CNSX
Content 변환
- 필드 이름 변경
- 데이터 형식 변환
- 필드 필터링/제거
모범 사례
1. 멱등성
id 필드(UUID)를 사용하세요. 중복 처리를 방지하기 위해 처리된 delivery ID를 저장하세요.
2. 응답 처리
- webhook을 수신하면 즉시
200 OK또는204 No Content를 반환하세요 - 필요하다면 데이터를 비동기적으로 처리하세요
- 응답을 반환하기 전에 오래 걸리는 작업은 수행하지 마세요
3. 오류 처리
- 적절한 HTTP 상태 코드를 반환합니다
- 인증 오류(401-403)의 경우 엔드포인트가 올바르게 구성되어 있는지 확인합니다
- 일시적인 오류의 경우 재시도를 트리거할 수 있도록 5xx 상태 코드를 반환합니다
4. 보안
- 웹훅 엔드포인트에는 HTTPS를 사용하세요
- 인증/인가를 구현하세요 (API 키, 토큰 등)
- 추가 보안을 위해
X-BZ-Delivery헤더를 검증하세요
5. 모니터링
- 엔드포인트의 응답 시간을 모니터링하세요
- 반복된 실패에 대한 알림을 설정하세요
- 전송 시도를 식별하기 위해
X-BZ-Delivery헤더를 추적하세요
6. 데이터 타입 처리
- 데이터 타입을 판별하기 위해
kind필드를 확인합니다 - 데이터 타입 구조에 맞게
content객체를 파싱합니다 - 레거시 키를 지원하는 경우 서로 다른
action형식(대문자와 소문자)을 모두 처리합니다
웹훅 핸들러 예제
Python (Flask)
Node.js (Express)
Go
문제 해결
Common Issues
-
웹훅이 수신되지 않음
- 웹훅 URL이 올바르게 설정되었는지 확인하세요
- 엔드포인트가 외부에서 공개적으로 접근 가능한지 확인하세요
- API 키가 유효하고 활성 상태인지 확인하세요
- 필터가 모든 데이터 유형을 제외하고 있지 않은지 확인하세요
- 지리적 필터가 기대하는 데이터 범위와 일치하는지 확인하세요
-
중복 전송
id필드를 사용해 멱등성을 구현하세요- 엔드포인트의 응답 시간을 확인하세요 (응답이 느리면 재시도가 발생할 수 있습니다)
-
인증 오류 (401-403)
- 엔드포인트의 인증 구성을 확인하세요
- API 키와 토큰을 확인하세요
- 참고: 인증 오류가 발생하면 재시도가 즉시 중단됩니다
-
타임아웃 오류
- 엔드포인트가 30초 이내에 응답하는지 확인하세요
- 필요한 경우 데이터를 비동기적으로 처리하세요
- 성공 응답을 즉시 반환하고 이후에 처리하세요
-
예기치 않은 action 형식
- 기존 웹훅 키(소문자 actions)를 사용 중인지 확인하세요
- 대문자 actions를 수신하려면 새 웹훅 키로 업데이트하세요
- 여러 클라이언트를 지원하는 경우 두 형식을 모두 처리하세요
-
누락된 데이터 유형
- 웹훅 구성에 원하는 데이터 유형이 포함되어 있는지 확인하세요
- 지리적 필터(US/Canada/India 설정)를 확인하세요
- 날짜 필터가 최근 데이터를 제외하지 않는지 확인하세요
지원
- Benzinga API 문서를 확인하세요
- Benzinga 담당자에게 문의하세요
- 통합 팀과 함께 webhook 구성을 검토하세요
버전 이력
- v1.0.0: 초기 데이터 Webhook 서비스 출시
- 현재: 필터링, 변환 및 재시도 메커니즘 강화