Wire AuditWard into your dev loop
Outbound webhooks, scheduled scans, Slack and Teams alerts, and Jira and GitHub Issues ticketing. Webhooks, chat alerts, and issue trackers are managed in the dashboard under Workspace settings, Integrations. This page is the setup reference for the API behind them.
Every request below is authenticated with your dashboard token as a bearer token: Authorization: Bearer YOUR_TOKEN. It's the same token issued when you sign in, so logging in again from another device replaces it. If you're wiring up automation that needs a token that doesn't rotate on login, use an MCP token instead (Settings → API & MCP), which the API also accepts.
Get notified the moment something changes.
Register an endpoint per project and choose which events it receives. AuditWard posts a signed JSON body on every match, with retries on failure.
Create an endpoint
curl -X POST https://platform-api.auditward.com/api/organizations/YOUR_ORG/webhooks/ \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"project": "PROJECT_ID",
"url": "https://example.com/hooks/auditward",
"event_types": ["finding.created", "scan.completed"]
}'The response includes secret once. Store it; it's not shown again and it's what you use to verify the signature below.
Event catalog
finding.createdA new finding was confirmed on a project.
scan.completedA scan session finished, with its finding and severity counts.
cloud_scan.completedA scan of a connected AWS account opened or resolved issues, with counts of each by severity. The first scan of a newly connected account, and scans that change nothing, send no event.
threat.detectedA new threat turned up in a connected AWS account, or a resolved one came back with new activity. Threats already there when detection starts on an account send no event. The payload is the issue, in the same shape as finding.created.
Verify the signature
Every delivery carries an X-AuditWard-Signature header shaped t=<timestamp>,v1=<hmac>. The HMAC is SHA-256 over the string "{timestamp}.{raw body}", keyed with your endpoint's secret.
import hashlib, hmac
def verify(secret: str, timestamp: str, raw_body: bytes, header: str) -> bool:
expected = hmac.new(
secret.encode(),
f"{timestamp}.{raw_body.decode()}".encode(),
hashlib.sha256,
).hexdigest()
_, v1 = header.split(",")
return hmac.compare_digest(f"v1={expected}", v1) Each delivery's body is a JSON envelope: id, event, endpoint_id, created_at, and data (the event-specific payload). Failed deliveries retry up to 3 times with backoff, and only on a 5xx response or a connection/timeout error; a 4xx is treated as permanent and not retried.
Turn a one-off audit into continuous monitoring.
A schedule re-runs the same scan on a cadence and reuses your webhook and chat alert setup, so you hear about new findings instead of re-checking the dashboard.
curl -X POST https://platform-api.auditward.com/api/organizations/YOUR_ORG/projects/PROJECT_ID/schedules/ \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"url": "https://staging.example.com",
"frequency": "weekly"
}'frequency accepts daily, weekly, or monthly. Scheduled scans count against your plan's usual scan quota.
Slack and Teams, filtered by severity.
Point AuditWard at an incoming webhook URL from Slack or Teams. You choose which events ping the channel and the minimum severity for new-finding alerts. On Team and Corporate, cloud scan digests and threat alerts for connected AWS accounts are on by default, and you can turn either off.
curl -X POST https://platform-api.auditward.com/api/organizations/YOUR_ORG/chat-integrations/ \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"provider": "slack",
"webhook_url": "https://hooks.slack.com/services/...",
"min_severity": "high",
"notify_finding_created": true,
"notify_scan_completed": true,
"notify_cloud_scan": true,
"notify_threat": true
}'provider is slack or teams; min_severity is low, medium, or high.
New findings become Jira issues or GitHub Issues automatically.
Set a severity threshold per project. A finding at or above it opens a ticket in your tracker, tagged back to the finding so status stays in sync.
Jira
curl -X POST .../projects/PROJECT_ID/integrations/ \
-H "Authorization: Bearer YOUR_TOKEN" \
-d '{
"provider": "jira",
"jira_base_url": "https://you.atlassian.net",
"jira_project_key": "SEC",
"jira_account_email": "you@example.com",
"api_token": "YOUR_JIRA_API_TOKEN",
"severity_threshold": "high",
"enabled": true
}'GitHub Issues
curl -X POST .../projects/PROJECT_ID/integrations/ \
-H "Authorization: Bearer YOUR_TOKEN" \
-d '{
"provider": "github",
"github_repo_full_name": "you/repo",
"api_token": "YOUR_GITHUB_TOKEN",
"severity_threshold": "high",
"enabled": true
}'api_token is encrypted at rest and never returned by the API after creation.
Fail a pull request on a real vulnerability.
The AuditWard GitHub App posts a commit status and a PR comment, and can upload results as native Code Scanning alerts. Install it once, then add the scan step to any workflow.
PR gating is in private beta and the app is not open for self-serve installation yet. Email contact@platform.auditward.com if you want it switched on for your repository.
We install the AuditWard GitHub App on your repository during onboarding while PR gating is in private beta.
Create an AuditWard API token and add it as a repository secret, then add the workflow step below.
name: Security
on:
pull_request:
jobs:
auditward:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: auditward/scan-action@v1
with:
api_token: ${{ secrets.AUDITWARD_TOKEN }}
target_url: https://staging.example.com
severity_threshold: hightarget_url must be a verified target on your AuditWard project. severity_threshold (high, medium, or low) sets the bar for failing the check.
Integration questions.
Which plans include these integrations?
Chat alerts, CI gating, and scheduled scans are on Starter and above. Webhooks and issue ticketing are on Team and above. Check your plan in Settings, or see the pricing page.
Do webhooks and chat alerts fire for the same events?
They are independent. Webhooks are for your own systems and carry the full event payload; chat alerts post a formatted summary to Slack or Teams and are filtered by a minimum severity you set. Cloud scan digests ignore the minimum severity and are sent only when a scan after the first one opens or resolves issues. Threat alerts also ignore it: every new threat is sent.
What happens if my webhook endpoint is down?
AuditWard retries up to 3 times with backoff on a 5xx response or a connection or timeout error. A 4xx response is treated as permanent and is not retried.
Can I scope a token to just these endpoints?
Not yet. Both the dashboard token and MCP tokens currently grant full account access for the org they belong to. Treat any token you put in a CI secret store as sensitive as your login.