Webhooks
Real-time event-driven notifications for any system. Bullseye sends an HTTP POST to your endpoint when visitors are identified, so you can integrate with internal tools, custom CRMs, or any system that accepts webhooks.
Plan Requirement
Webhooks are available on Scale plans and above. If you're on Starter, Growth, or Free Trial, upgrade to Scale to enable webhooks.
Overview
HTTP POST to your endpoint when visitors are identified
HMAC-SHA256 signature verification for security
Full visitor, company, and session data in the payload
Configurable per organization
Setup
Log in to the Bullseye dashboard and navigate to Settings > Integrations > Webhooks
Click Add Webhook
Enter your endpoint URL (must be HTTPS)
Optionally configure a secret for HMAC-SHA256 signature verification
Select the events you want to receive (e.g.,
visitor.identified)Save the webhook
Your endpoint must respond with a 2xx status code within 30 seconds. Non-2xx responses or timeouts trigger retries (see Retry Behavior below).
Payload Structure
Each webhook delivery includes a JSON payload with the following structure.
Event Type
The event field indicates the type of event. For visitor identification, the event is visitor.identified.
Payload Fields
event
Event type (e.g., visitor.identified)
timestamp
ISO 8601 timestamp when the event occurred
organization_id
Your Bullseye organization ID
session_id
Unique identifier for the visitor session
visitor
Identified visitor profile data
company
Company data associated with the visitor
session
Session metadata (pages, UTM, referrer, device)
Example Payload
HMAC-SHA256 Verification
To verify that webhook deliveries come from Bullseye, use the X-Bullseye-Signature header. The header contains an HMAC-SHA256 signature of the raw request body using your webhook secret.
Verification Steps
Read the raw request body (before any JSON parsing)
Compute
HMAC-SHA256(raw_body, your_webhook_secret)Encode the result as hexadecimal
Compare with the value in
X-Bullseye-Signature
If the values match, the webhook is authentic. Reject requests where the signature does not match.
Example (Pseudocode)
Retry Behavior
If your endpoint returns a non-2xx status code or does not respond within 30 seconds, Bullseye retries the delivery:
Retry schedule — Retries occur at increasing intervals (e.g., 1 minute, 5 minutes, 30 minutes)
Maximum retries — Up to 3 retries per delivery
Idempotency — The same payload may be delivered more than once; design your endpoint to handle duplicate events (e.g., using
session_idas a deduplication key)
Best Practices
Use HTTPS — Webhook endpoints must use HTTPS
Verify the signature — Always validate
X-Bullseye-Signaturebefore processingRespond quickly — Return 200 immediately and process the payload asynchronously if needed
Handle duplicates — Use
session_idor a combination of fields to deduplicate eventsLog failures — Monitor for 4xx/5xx responses and fix endpoint issues promptly
Last updated