Overview
ZeroPath webhooks allow you to receive real-time HTTP notifications when important security events occur in your repositories. This enables you to build custom integrations, automate workflows, and stay informed about your security posture.Quick Setup
Configure webhooks in your Organization Settings to start receiving real-time security notifications.
How Webhooks Work
When a subscribed event occurs, ZeroPath sends an HTTP POST request to your configured endpoint with a JSON payload containing detailed information about the event. You can use this data to:- Automate Security Workflows: Trigger automated responses to security events
- Build Custom Integrations: Connect ZeroPath with your existing tools and platforms
- Monitor Security Posture: Track vulnerabilities and scan results in real-time
- Enhance Compliance: Log security events for audit trails
Supported Event Types
ZeroPath supports the following webhook event types:SCAN_STARTED
When a full repository scan begins
SCAN_COMPLETE
When a full repository scan finishes successfully
SCAN_FAILED
When a scan fails to complete
SCAN_SCHEDULED
When a scan is scheduled
PR_SCAN_STARTED
When a pull request scan begins
PR_SCAN_COMPLETE
When a pull request scan completes
NEW_VULNERABILITIES_FULL_SCAN
When new vulnerabilities are detected in a full repository scan
NEW_VULNERABILITIES_PR
When new vulnerabilities are detected in a pull request
VULNERABILITY_PATCHED
When a vulnerability is fixed
VULNERABILITY_REOPENED
When a vulnerability reappears
PR_BLOCKED
When a pull request is blocked due to vulnerabilities
PR_MERGED_WITH_ISSUES
When a pull request is merged to main branch with open vulnerabilities
REPORT_COMPLETE
When a report is generated
LONG_RUNNING_SCAN
When a scan is taking unusually long
AUDIT_LOG_EVENT
Important audit log events
Webhook Payload Structure
All webhook payloads follow a consistent structure with event-specific data:Common Fields
| Field | Type | Required | Description |
|---|---|---|---|
time | integer | Yes | Unix epoch seconds when the event was emitted |
host | string | Yes | Origin host (e.g., zeropath.com) |
source | string | Yes | Source system identifier |
sourcetype | enum | Yes | Event type. One of SCAN_STARTED, SCAN_COMPLETE, PR_SCAN_STARTED, PR_SCAN_COMPLETE, NEW_VULNERABILITIES_PR, NEW_VULNERABILITIES_FULL_SCAN, VULNERABILITY_PATCHED, VULNERABILITY_REOPENED, AUDIT_LOG_EVENT, SCAN_FAILED, SCAN_SCHEDULED, LONG_RUNNING_SCAN, PR_BLOCKED, PR_MERGED_WITH_ISSUES, REPORT_COMPLETE |
event | object | Yes | Event payload object containing details |
event object
| Field | Type | Required | Description |
|---|---|---|---|
timestamp | string (date-time) | Yes | ISO 8601 timestamp of the event |
organization | object | Yes | Organization details |
organization.id | string | Yes | Organization ID |
organization.name | string | No | Organization name |
repository | object | No | Repository details |
repository.id | string | Yes | Repository ID |
repository.name | string | Yes | Repository name |
scan | object | No | Scan details for scan-related events |
scan.id | string | Yes | Scan ID |
scan.type | string | Yes | Scan type (e.g., FullScan, PrScan) |
scan.status | string | Yes | One of started, completed, failed, scheduled, blocked, merged_with_issues, unknown |
scan.duration_minutes | integer | No | Scan duration in minutes |
scan.vulnerability_summary.total | integer | Yes | Total vulnerabilities (when present) |
scan.vulnerability_summary.by_severity | object | Yes | Counts for critical, high, medium, low, info |
scan.url | string | Yes | Link to view the scan in ZeroPath |
audit_log | object | No | Present for AUDIT_LOG_EVENT |
audit_log.id | string | Yes | Audit log ID |
audit_log.endpoint | string | Yes | API endpoint called |
audit_log.arguments | object | No | Arguments passed to the endpoint |
audit_log.caller | object | No | Caller info (id, email) |
audit_log.timestamp | string (date-time) | Yes | When the audit event occurred |
error | string | No | Error message (present in failure events) |
metadata | object | No | Additional event-specific data |
vulnerability | object | No | Detailed vulnerability information |
Event-specific requirements
SCAN_STARTED:event.scanrequiredPR_SCAN_STARTED:event.scanrequiredSCAN_COMPLETE:event.scanrequiredPR_SCAN_COMPLETE:event.scanrequiredSCAN_FAILED:event.scanandevent.errorrequiredNEW_VULNERABILITIES_PR: eitherevent.vulnerabilityorevent.scanrequiredNEW_VULNERABILITIES_FULL_SCAN: eitherevent.vulnerabilityorevent.scanrequiredLONG_RUNNING_SCAN:event.metadata.runningMinutesrequiredAUDIT_LOG_EVENT:event.audit_logrequiredSCAN_SCHEDULED:event.metadatawithscheduleId,crontab,isEnabled,actionrequiredPR_BLOCKED:event.metadata.prIdandevent.metadata.prNumberrequiredPR_MERGED_WITH_ISSUES:event.metadata.prUrlandevent.metadata.targetBranchrequiredVULNERABILITY_REOPENED/VULNERABILITY_PATCHED: eitherevent.metadataorevent.vulnerabilityrequiredREPORT_COMPLETE:event.metadata.reportIdrequired
Event Payload Examples
Configuring Webhooks
Setting Up Webhooks
Webhook configuration in ZeroPath is a two-step process that gives you granular control over which events you receive:Step 1: Add a Webhook Integration
- Navigate to zeropath.com/app/settings/integrations
- Click “Add Integration” and select “Webhook”
- Configure your webhook endpoint:
- Name: A descriptive name for this webhook
- URL: Your HTTPS endpoint that will receive webhook payloads
- Custom Headers: Add custom headers for authentication (e.g.,
Authorization: Bearer your-secret-token)
Step 2: Create Notification Settings
After adding a webhook integration, configure which events trigger notifications:- Go to zeropath.com/app/settings/notifications
- Click “Create Notification Setting”
- Configure your notification preferences:
- Notification Channel: Select “Webhook” from the available channels
- Webhook: Choose from your list of webhook integrations
- Repositories: Select specific repositories or choose “All Repositories”
- Event Types: Select which events should trigger notifications
- Vulnerability Score Threshold: For vulnerability events, set the minimum threshold (Info, Low, Medium, High, or Critical)
The vulnerability score threshold only applies to vulnerability-related events like
NEW_VULNERABILITIES_FULL_SCAN and NEW_VULNERABILITIES_PR. Other events like SCAN_COMPLETE will always be sent regardless of this setting.Example Configuration
Here’s an example of a typical webhook configuration:1
Create Webhook Integration
Add a webhook endpoint in Integrations:
- Name: “Production Security Alerts”
- URL:
https://api.example.com/webhooks/zeropath - Custom Headers:
Authorization: Bearer prod-webhook-token-123X-Environment: production
2
Configure Notifications
Create notification settings:
- Notification Channel: “Webhook”
- Webhook: “Production Security Alerts” (from your webhook list)
- Repositories: “backend-api”, “frontend-app”
- Events:
NEW_VULNERABILITIES_FULL_SCAN,NEW_VULNERABILITIES_PR,PR_BLOCKED - Vulnerability Score Threshold: High
3
Result
You’ll receive webhooks only for:
- New vulnerabilities with High or Critical scores in selected repos
- Blocked PRs in selected repos
- No notifications for vulnerabilities below High threshold
Repository Filtering
You can configure webhooks at different scopes:- All Repositories
- Specific Repositories
Select “All Repositories” to receive notifications for events across your entire organization. New repositories are automatically included.
Vulnerability Score Filtering
The vulnerability score threshold helps reduce noise by filtering out lower-priority vulnerabilities. ZeroPath uses a 0-100 scoring system categorized into five levels:| Threshold Level | Score Range | Description | Typical Use Case |
|---|---|---|---|
| Critical | 90-100 | Immediate action required | Production systems, zero-tolerance environments |
| High | 70-89 | Serious issues requiring prompt attention | Important systems, should be addressed soon |
| Medium | 40-69 | Moderate risk vulnerabilities | Standard threshold for most projects |
| Low | 10-39 | Minor issues with limited impact | Development environments, code quality |
| Info | 0-9 | Informational findings | Audit trails, compliance tracking |
When you select a threshold level (e.g., “High”), you’ll receive notifications for all vulnerabilities at that level and above. For example, selecting “High” will notify you of both High and Critical vulnerabilities.
Multiple Webhook Configurations
You can create multiple webhook integrations and notification settings to handle different scenarios. Each notification setting can use the “Webhook” channel with different webhook integrations:Critical Alerts
Use Case: Immediate notifications for critical issues
- Webhook: PagerDuty integration
- Repositories: Production repos only
- Events:
NEW_VULNERABILITIES_FULL_SCAN,PR_BLOCKED - Vulnerability Score Threshold: Critical
Team Updates
Use Case: Daily team notifications
- Webhook: Slack channel
- Repositories: All repositories
- Events:
SCAN_COMPLETE,REPORT_COMPLETE - Vulnerability Score Threshold: Medium
Audit Trail
Use Case: Compliance logging
- Webhook: SIEM system
- Repositories: All repositories
- Events: All event types
- Vulnerability Score Threshold: Info (capture everything)
PR Workflow
Use Case: Developer notifications
- Webhook: GitHub Actions
- Repositories: Active development repos
- Events:
PR_SCAN_COMPLETE,NEW_VULNERABILITIES_PR - Vulnerability Score Threshold: High
Managing Notification Settings
To manage your webhook configurations:- View All Settings: Navigate to zeropath.com/app/settings/notifications to see all active configurations
- Edit Settings: Click on any notification setting to modify repositories, events, or vulnerability score thresholds
- Enable/Disable: Temporarily disable notifications without deleting the configuration
- Test Webhooks: Use the “Test” button to send a sample payload to verify your endpoint is working
Webhook Security
Authentication with Custom Headers
ZeroPath allows you to add custom headers to webhook requests for authentication. This flexible approach lets you implement security that matches your infrastructure: Common Authentication Patterns:- Flexibility: Use any authentication scheme that fits your infrastructure
- Compatibility: Works with existing API gateways and authentication middleware
- Multiple Headers: Add multiple headers for different purposes (auth, routing, metadata)
- Standard Patterns: Use industry-standard authentication patterns like Bearer tokens
Best Practices
Implement Idempotency
Implement Idempotency
Webhooks may be delivered more than once. Use the event ID to ensure you process each event only once.
Respond Quickly
Respond Quickly
Your endpoint should return a 2xx status code within 10 seconds. Process webhook data asynchronously if needed.
Handle Retries
Handle Retries
ZeroPath will retry failed webhook deliveries with exponential backoff. Ensure your endpoint can handle duplicate events.
Monitor Webhook Health
Monitor Webhook Health
Set up monitoring for your webhook endpoints to ensure they’re receiving and processing events correctly.
Use Webhook Filtering
Use Webhook Filtering
Only subscribe to events you need to reduce noise and processing overhead.
Error Handling
ZeroPath uses the following retry policy for failed webhook deliveries:- Initial Retry: 30 seconds after first failure
- Subsequent Retries: Exponential backoff (1min, 2min, 4min, 8min, 16min)
- Max Retries: 6 attempts over ~30 minutes
- Final Action: Webhook marked as failed and notification sent
Need Help?
Contact Support
Having issues with webhooks? Our support team is here to help.