Skip to main content
The webhook engine pushes calendar and signal updates directly to your HTTP endpoint with built-in retries, filtering, and transformation options. Use this guide to understand delivery mechanics, payload shape, and integration best practices.

Overview

The Benzinga Data Webhook service delivers real-time calendar and signals data to your configured webhook endpoints. When calendar events (earnings, dividends, ratings, etc.) or signals (option activity, halts, etc.) are created, updated, or removed, the service automatically sends HTTP POST requests to your webhook URL with the data payload. Key capabilities:
  • Configurable scopes for calendar and signal coverage so you only receive the data you need
  • Idempotent deliveries with a unique X-BZ-Delivery header and payload id field for deduplication
  • Robust retry schedule that escalates from rapid exponential retries to long-tail hourly attempts
  • Optional content transformations to align payloads with downstream system expectations

Webhook Delivery

HTTP Request Details

  • Method: POST
  • Content-Type: application/json
  • User-Agent: Benzinga-Dispatch/v1.0.0 {build-version}
  • Custom Header: X-BZ-Delivery - A unique UUID for each delivery attempt (useful for deduplication)

Retry Policy

The data webhook service implements a robust retry mechanism:
  • Exponential Phase: 15 retries within the first 5 minutes
  • Additional Exponential Retries: 11 more retries if needed
  • Fixed Interval Phase: 12 retries per hour × 24 hours/day × 7 days (for long-term retries)
  • Max Wait Time: 5 minutes between retries in exponential phase
  • Request Timeout: 30 seconds per request

Response Requirements

Your webhook endpoint should return one of the following HTTP status codes:
  • Success Codes (200-202, 204): Indicates successful delivery. No retries will be attempted.
  • Client Error Codes (401-403): Indicates authentication/authorization failure. Retries will be halted immediately to prevent further failed attempts.
  • Other Codes (4xx, 5xx): Will trigger retries according to the retry policy above.
Important: Your endpoint should respond quickly (ideally within 30 seconds) to avoid timeout. The engine will retry on timeouts.

Webhook Payload Structure

Each webhook delivery contains a JSON payload with the following structure:

Payload Fields

Top-Level Fields

  • id (string, UUID): Unique identifier for this webhook delivery. Use this for deduplication.
  • api_version (string): API version identifier. Currently "webhook/v1".
  • kind (string): Data type path identifier. See Supported Data Types for all possible values.

Data Object

  • action (string): Event action type. Possible values:
    • "Created": New data was created (default for new webhook keys)
    • "Updated": Existing data was updated
    • "Removed": Data was removed
    • Note: Legacy webhook keys may receive lowercase values: "created", "updated", "removed"
  • id (string): Unique identifier for the calendar/signal record
  • timestamp (string, ISO 8601): Timestamp when the webhook was generated
  • content (object): The actual calendar or signal data. Structure varies by data type (see Supported Data Types)

Supported Data Types

The data webhook service supports the following calendar and signal types:

Calendar Data Types (v2.1)

Signals Data Types (v1)

Additional Data Types (v1)

Content Structure Examples

Earnings Example

Dividends Example

Ratings Example

Option Activity Example

Event Actions

The data webhook service sends events for three types of actions:
  1. Created: Triggered when new calendar or signal data is published
  2. Updated: Triggered when existing data is modified
  3. Removed: Triggered when data is deleted
Note: The action format depends on your webhook configuration:
  • New webhook keys: Receive capitalized actions ("Created", "Updated", "Removed")
  • Legacy webhook keys: Receive lowercase actions ("created", "updated", "removed")

Content Filtering

Your webhook configuration can include filters to control which data you receive:

Filter Options

  • Data Types: Filter by specific calendar/signal types (e.g., only earnings, only ratings)
  • Geographic Filters: Control whether to receive:
    • US market data (AllowUSA)
    • Canadian market data (AllowCanada)
    • Indian market data (AllowIndia) - for WIIMs data
  • Date Filter: Exclude historical data older than a specified date (MaxHistoricalDate)

Exchange Filtering

The service automatically filters by exchange based on your geographic settings:
  • US Exchanges: NYSE, NASDAQ, AMEX, ARCA, OTC, OTCBB, PINX, PINK, BATS, IEX
  • Canadian Exchanges: TSX, TSXV, CSE, CNSX

Content Transformation

The webhook engine supports content transformation for specific data types. Transformations are applied based on your webhook configuration and may include:
  • Field renaming
  • Data format conversion
  • Field filtering/removal

Best Practices

1. Idempotency

Use the id field (UUID) in the payload to implement idempotency. Store processed delivery IDs to avoid duplicate processing.

2. Response Handling

  • Return 200 OK or 204 No Content immediately upon receiving the webhook
  • Process the data asynchronously if needed
  • Don’t perform long-running operations before responding

3. Error Handling

  • Return appropriate HTTP status codes
  • For authentication errors (401-403), ensure your endpoint is properly configured
  • For temporary failures, return 5xx status codes to trigger retries

4. Security

  • Use HTTPS for your webhook endpoint
  • Implement authentication/authorization (API keys, tokens, etc.)
  • Validate the X-BZ-Delivery header for additional security

5. Monitoring

  • Monitor your endpoint’s response times
  • Set up alerts for repeated failures
  • Track the X-BZ-Delivery header to identify delivery attempts

6. Data Type Handling

  • Check the kind field to determine the data type
  • Parse the content object based on the data type structure
  • Handle different action formats (capitalized vs lowercase) if supporting legacy keys

Example Webhook Handler

Python (Flask)

Node.js (Express)

Go

Troubleshooting

Common Issues

  1. No webhooks received
    • Verify your webhook URL is correctly configured
    • Check that your endpoint is publicly accessible
    • Ensure your API key is valid and active
    • Verify filters aren’t excluding all data types
    • Check that your geographic filters match the data you expect
  2. Duplicate deliveries
    • Implement idempotency using the id field
    • Check your endpoint’s response times (slow responses may cause retries)
  3. Authentication errors (401-403)
    • Verify your endpoint’s authentication configuration
    • Check API keys and tokens
    • Note: Authentication errors halt retries immediately
  4. Timeout errors
    • Ensure your endpoint responds within 30 seconds
    • Process data asynchronously if needed
    • Return success immediately and process later
  5. Unexpected action format
    • Check if you’re using a legacy webhook key (lowercase actions)
    • Update to a new webhook key to receive capitalized actions
    • Handle both formats if supporting multiple clients
  6. Missing data types
    • Verify your webhook configuration includes the desired data types
    • Check geographic filters (US/Canada/India settings)
    • Ensure date filters aren’t excluding recent data

Support

For questions or issues with webhook delivery:
  • Check the Benzinga API Documentation
  • Contact your Benzinga account representative
  • Review webhook configuration with your integration team

Version History

  • v1.0.0: Initial data webhook service release
  • Current: Enhanced filtering, transformation, and retry mechanisms