Documentation Index
Fetch the complete documentation index at: https://docs.promptguard.co/llms.txt
Use this file to discover all available pages before exploring further.
Webhooks let your application receive real-time notifications when PromptGuard detects security events — threats blocked, PII redacted, usage thresholds crossed, and more.
Overview
When you configure a webhook for a project, PromptGuard sends HTTP POST requests to your endpoint whenever specific security events occur. This lets you:- Log security events to your own systems
- Trigger alerts in Slack, PagerDuty, or other tools
- Build custom dashboards and analytics
- Audit AI interactions in real-time
Setup
Via Dashboard
- Go to app.promptguard.co
- Select your project
- Navigate to Settings or Project Overview
- Enter your Webhook URL
- Save
Delivery Monitoring
Track webhook delivery status in the dashboard:- Navigate to your project → Webhooks
- View delivery history with status, attempts, and errors
- Manually retry failed deliveries
- Status: Pending, delivered, or failed
- Attempts: Number of delivery attempts (auto-retries with exponential backoff)
- Response Status: HTTP status code from your endpoint
- Error Details: Last error message for failed deliveries
Via API
Event Types
| Event | Triggered When |
|---|---|
threat.blocked | A request is blocked by security policy |
threat.detected | A threat is detected (even if allowed) |
pii.redacted | PII is detected and redacted from content |
usage.threshold | Usage crosses 80% or 100% of monthly quota |
usage.overage | Usage exceeds monthly quota (Scale plan) |
Payload Format
All webhook events follow this structure:Threat Blocked
PII Redacted
Usage Threshold
Handling Webhooks
Example Server (Node.js)
Example Server (Python)
Webhook Signing (Enterprise)
PromptGuard signs webhook payloads with HMAC-SHA256 using your project’s webhook secret. Verify the signature to ensure payloads are authentic:X-PromptGuard-Signature header with format sha256=<hex_digest>.
Best Practices
- Respond quickly — Return a
200status within 5 seconds. Process events asynchronously if needed. - Handle duplicates — Use
event_idto deduplicate events in case of retries. - Verify signatures — Always verify the
X-PromptGuard-Signatureheader to ensure webhook authenticity. - Use HTTPS — Always use HTTPS endpoints for webhook delivery.
- Log everything — Store raw webhook payloads for debugging and audit trails.
- Monitor failures — Track webhook delivery failures in your monitoring system.
Retry Policy
If your endpoint returns a non-2xx status code or times out, PromptGuard will retry delivery:| Attempt | Delay |
|---|---|
| 1st retry | 30 seconds |
| 2nd retry | 2 minutes |
| 3rd retry | 10 minutes |
webhook_deliveries table with error details.
Custom Policy Webhooks
In addition to receiving event notifications, you can use webhooks as custom policy hooks in the PromptGuard guard pipeline. This lets you run your own verdict logic on every scan without modifying the detection engine. When a custom policy webhook is configured, PromptGuard calls your endpoint during the scan pipeline and uses your response to decide whether to allow, block, or redact the content.How It Works
- PromptGuard runs its built-in threat detectors on the content.
- Before returning a final decision, it sends a POST request to your custom policy webhook with the scan context and any threats already detected.
- Your endpoint evaluates the content and returns a verdict.
- PromptGuard incorporates your verdict into the final decision.
Request Format
Your endpoint receives a POST request with this JSON body:| Field | Type | Description |
|---|---|---|
content | string | The text being scanned |
direction | string | "input" (user → model) or "output" (model → user) |
model | string | The AI model being used |
event_id | string | Unique identifier for this scan event |
threats_detected | array | Threats already found by built-in detectors |
Response Format
Your endpoint must return a JSON response:| Field | Type | Required | Description |
|---|---|---|---|
verdict | string | Yes | "allow", "block", or "redact" |
reason | string | No | Human-readable explanation for the verdict |
redacted_content | string | No | Required when verdict is "redact" — the sanitized content |
Example: Custom Compliance Server
Failure Behavior
Custom policy webhooks have a 3-second timeout by default. If your endpoint is unreachable or returns an error:- Fail open (default): The request is allowed through. The webhook error is logged but does not block the user.
- Fail closed: The request is blocked. Enable this for high-security environments where you require your custom policy to run on every request.
Best Practices for Policy Webhooks
- Keep it fast — Your endpoint is in the hot path of every scan. Aim for sub-100ms response times.
- Return valid verdicts — Only
"allow","block", and"redact"are accepted. Invalid values default to"allow". - Use fail-closed sparingly — Only enable fail-closed mode when your policy check is mandatory for compliance.
- Log decisions — Record your webhook’s verdicts for auditing and debugging.
- Handle all fields — Your endpoint should gracefully handle any combination of threat types in
threats_detected.
Next Steps
Monitoring Dashboard
View security events and analytics
Usage Tracking
Monitor your API usage