Overview
Webhooks enable your application to receive real-time notifications when events occur in InstaView. Instead of polling the API, webhooks push data to your endpoint immediately when interviews complete, analyses finish, or other events happen.How Webhooks Work
1
Configure Endpoint
Register your webhook URL and specify which events to receive
2
Event Occurs
An interview completes, analysis finishes, or other tracked event happens
3
Receive Notification
InstaView sends an HTTP POST request to your endpoint with event details
4
Process & Respond
Your server processes the event and returns a 2xx status code
Event Types
InstaView supports the following webhook event types:- Interview Events
- Analysis Events
- System Events
| Event | Description |
|---|---|
interview.started | Interview session began |
interview.completed | Interview finished with analysis available |
interview.failed | Technical failure occurred during interview |
Event Type Strings
When configuring webhooks, use these event type strings:"analysis.completed"- Analysis finished successfully"analysis.failed"- Analysis processing failed"ping"- Test event for connectivity"interview.completed"- Interview finished with analysis"interview.failed"- Technical failure during interview"interview.started"- Interview session began
Payload Structure
All webhook payloads follow this structure:Interview Events Payload
Analysis Events Payload
Failed Event Payloads
Failed events include an error message:Ping Event Payload
Webhook payloads contain minimal data (IDs and status). For full details like
analysis results or transcripts, use the Interview
API to fetch the complete resource.
Per-Company Webhooks
For ATS integrations managing multiple companies, you can register webhooks per company by specifying thecompanyId parameter when creating a webhook. This enables:
- Company-specific endpoints: Each company can have its own webhook URL (e.g., different subdomains)
- Selective event delivery: Webhooks with
companyIdonly receive events for that specific company - Global webhooks: Webhooks without
companyIdreceive events for all companies accessible by the API key
Example: Per-Company Setup
Filtering by Company
When listing webhooks, you can filter by company:companyId, only company-specific webhooks are returned. Global webhooks (those without a companyId) are excluded from filtered results. To see all webhooks including global ones, omit the companyId parameter.
Required Scopes
| Operation | Required Scope |
|---|---|
| List webhooks | read:webhooks |
| Get webhook by ID | read:webhooks |
| Create webhook | write:webhooks |
| Update webhook | write:webhooks |
| Delete webhook | write:webhooks |
| Test webhook | write:webhooks |
| Reset circuit breaker | write:webhooks |
Security
Signature Verification
Every webhook request includes an HMAC-SHA256 signature in theX-Webhook-Signature header. Always verify this signature to ensure requests are from InstaView.
The signature format is: sha256=<hex-encoded-signature>
Request Headers
Every webhook request includes these headers:| Header | Description |
|---|---|
Content-Type | Always application/json |
X-Webhook-Signature | HMAC-SHA256 signature for payload verification |
X-Webhook-Delivery-Id | Unique ID for this delivery (for idempotency) |
X-Webhook-Event | Event type (e.g., interview.completed) |
User-Agent | InstaView-Webhook/1.0 |
Secret Management
Best practices for secret management:- Store secrets in environment variables or a secrets manager
- Never commit secrets to version control
- Rotate secrets periodically by creating new webhooks
- Use different secrets for development and production
Retry Logic
If your endpoint fails to respond with a 2xx status code, InstaView automatically retries delivery with exponential backoff:1
Immediate Attempt
First delivery attempt immediately when event occurs
2
Retry 1
After a short delay if first attempt fails
3
Retry 2
After a longer delay if second attempt fails
4
Retry 3
Final attempt with maximum delay
Circuit Breaker
To protect both your system and ours, InstaView implements a circuit breaker pattern:- If a webhook consistently fails, it will be automatically disabled
- You can monitor the
consecutiveFailurescount in the webhook configuration - When disabled, the
circuitOpenedAttimestamp indicates when the circuit opened - Use the Reset Circuit Breaker endpoint to re-enable the webhook after fixing issues
Endpoint Requirements
Your webhook endpoint must:Respond Quickly
Respond Quickly
Return a 2xx response within 30 seconds. For long-running tasks, acknowledge
receipt immediately and process asynchronously.
Be Idempotent
Be Idempotent
Handle duplicate deliveries gracefully using the
deliveryId:Use HTTPS
Use HTTPS
Production webhook URLs must use HTTPS. HTTP is only allowed for localhost
during development.
Return 2xx for Success
Return 2xx for Success
Any 2xx status code indicates successful receipt. Retry behavior depends on the status code:
| Status | Meaning |
|---|---|
| 200, 201, 202 | Success - no retry |
| 429 | Rate limit - will retry |
| 4xx (except 429) | Client error - no retry (permanent errors like 401, 404) |
| 5xx | Server error - will retry |
Managing Webhooks
Create a Webhook
Per-Company Webhooks: For ATS integrations managing multiple companies, you can specify
companyId when creating a webhook. This allows you to register separate webhooks per company (e.g., different subdomains). If omitted, the webhook will receive events for all companies accessible by the API key (global webhook).List Webhooks
Update a Webhook
Delete a Webhook
Test a Webhook
Send a test ping to verify connectivity:To test a webhook using the test endpoint above, it must be subscribed to the
ping event.Test Interview Events with Test Interviews
For more comprehensive testing of interview-related webhook events (interview.completed, analysis.completed), you can create test interviews using the isTest flag:
- Testing your webhook handler’s processing logic for interview completion
- Verifying that analysis data is correctly parsed and stored
- End-to-end testing of your integration without waiting for real interviews
- Development and debugging without consuming billing minutes
Reset Circuit Breaker
If your webhook was disabled due to consecutive failures:Custom Headers
You can configure custom headers to authenticate with your endpoint:Security: Sensitive headers (Authorization, X-API-Key, X-Secret, API-Key)
are automatically encrypted at rest. When listing webhooks, these header
values are masked for security.
Best Practices
Verify Signatures
Always verify the
X-Webhook-Signature header to ensure requests are
authenticRespond Fast
Return 200 immediately and process asynchronously for long-running tasks
Handle Duplicates
Use
deliveryId for idempotency - you may receive the same event multiple
timesMonitor Health
Check
consecutiveFailures and circuitOpenedAt to catch issues earlyTroubleshooting
Webhook not receiving events
Webhook not receiving events
Possible causes: - Webhook is not subscribed to the event type - Webhook
is disabled (
isActive: false) - Circuit breaker is open (check
circuitOpenedAt) Solutions: - Verify event subscriptions in webhook
configuration - Check if webhook is active - Reset circuit breaker if neededSignature verification failing
Signature verification failing
Possible causes: - Using wrong signing secret - Modifying payload before
verification - Encoding issues Solutions: - Verify you’re using the
original signing secret - Verify the raw request body, not parsed JSON -
Ensure UTF-8 encoding
Webhook disabled automatically
Webhook disabled automatically
Cause: Too many consecutive failures triggered the circuit breaker
Solutions: 1. Fix the underlying issue (endpoint availability,
authentication, etc.) 2. Use the test endpoint to verify connectivity 3. Reset
the circuit breaker
Missing events
Missing events
Possible causes: - Event occurred before webhook was configured - Event
type not in subscription list Note: Webhooks only deliver events that
occur after configuration. For historical data, use the API to poll for past
events.