Which placeholders are available for the Webhooks integration?

Placeholders allow you to customize webhook payloads with specific data from Holm Security. When you receive a webhook notification, placeholders are replaced with actual values from assets, tickets, and vulnerabilities. This article lists all available placeholders and shows you how to use them in your webhook payload.

What are placeholders?

A placeholder is a variable that you use in your webhook payload to dynamically insert data from Holm Security. For example, instead of hardcoding an asset name, you use {asset.name}, which is replaced with the actual asset name when the webhook is sent.

Placeholders allow you to:

Create dynamic webhook messages that include relevant security data
Route notifications to the correct systems using asset or severity information
Build custom workflows based on vulnerability details

Available placeholders by category

Placeholders are organized into three main categories: assets, tickets, and vulnerabilities. Choose the placeholders that match the data you need in your external system.

Asset placeholders

Use these placeholders for asset information

Asset placeholders provide details about the scanned systems:

{asset.name} — Asset name or identifier
{asset.hostname} — Hostname of the asset
{asset.ipv4} — IPv4 address
{asset.ipv6} — IPv6 address
{asset.os} — Operating system
{asset.type} — Asset type (server, workstation, appliance, etc.)
{asset.tags} — Tags assigned to the asset
{asset.owner} — Asset owner name
{asset.url} — Link to the asset in Security Center
{asset.business_risk} — Business risk rating
{asset.first_scanned} — Date of first scan
{asset.last_scanned} — Date of last scan
{asset.details} — Additional asset details

Ticket placeholders

Use these placeholders for ticket information

Ticket placeholders provide details about remediation tickets:

{ticket.number} — Ticket identifier
{ticket.name} — Ticket name or title
{ticket.status} — Current ticket status
{ticket.severity} — Ticket severity level
{ticket.due_date} — Due date for remediation
{ticket.url} — Link to the ticket in Security Center
{ticket.new_ticket_subject} — Subject line for new tickets
{ticket.owner.name} — Full name of ticket owner
{ticket.owner.first_name} — First name of ticket owner
{ticket.owner.last_name} — Last name of ticket owner
{ticket.owner.email} — Email address of ticket owner

Vulnerability placeholders

Use these placeholders for vulnerability information

Vulnerability placeholders provide details about security findings:

{vuln.name} — Vulnerability name
{vuln.severity} — Severity level (Critical, High, Medium, Low)
{vuln.summary} — Short summary of the vulnerability
{vuln.solution} — Remediation steps or patch information
{vuln.impact} — Potential business impact
{vuln.detection} — How the vulnerability was detected
{vuln.insight} — Additional technical insights
{vuln.cvss2} — CVSS v2.0 score
{vuln.cvss3} — CVSS v3.0 score
{vuln.cves} — Related CVE identifiers
{vuln.hid} — Holm Security internal HID code
{vuln.exploits} — Known exploit information
{vuln.patches} — Available patches or updates
{vuln.ransomware} — Ransomware-related information
{vuln.url} — Link to the vulnerability in Security Center

Using placeholders in your webhook payload

Include placeholders in the JSON payload that your webhook endpoint receives. When Holm Security sends the webhook, each placeholder is replaced with the actual data.

Example: Custom webhook payload

Here's an example of how to use placeholders in a webhook payload for a custom integration:

{ "asset": { "name": "{asset.name}", "hostname": "{asset.hostname}", "ipv4": "{asset.ipv4}", "os": "{asset.os}", "owner": "{asset.owner}", "url": "{asset.url}" }, "ticket": { "number": "{ticket.number}", "status": "{ticket.status}", "severity": "{ticket.severity}", "due_date": "{ticket.due_date}", "owner_email": "{ticket.owner.email}", "url": "{ticket.url}" }, "vulnerability": { "name": "{vuln.name}", "severity": "{vuln.severity}", "cvss3_score": "{vuln.cvss3}", "solution": "{vuln.solution}", "url": "{vuln.url}" } }

Actual payload after webhook is sent

When the webhook is sent, placeholders are replaced with real data. Here's what it looks like:

{ "asset": { "name": "WebServer-01", "hostname": "web01.example.com", "ipv4": "192.168.1.50", "os": "Ubuntu 20.04", "owner": "Engineering Team", "url": "https://sc.holmsecurity.com/assets/12345" }, "ticket": { "number": "TK-2024-001", "status": "Open", "severity": "Critical", "due_date": "2024-03-15", "owner_email": "[email protected]", "url": "https://sc.holmsecurity.com/tickets/TK-2024-001" }, "vulnerability": { "name": "OpenSSL Vulnerability", "severity": "Critical", "cvss3_score": "9.8", "solution": "Update OpenSSL to version 1.1.1k or later", "url": "https://sc.holmsecurity.com/vulnerabilities/CVE-2021-3449" } }

💡 Tip: You don't need to use all available placeholders. Include only the data you need in your external system. This keeps your payload lean and focused on what matters for your integration.

Complete payload structure reference

This is the complete structure of the webhook payload with all available fields:

{ "asset": { "name": ..., "hostname": ..., "ipv4": ..., "ipv6": ..., "os": ..., "type": ..., "tags": [...], "owner": ..., "url": ..., "business_risk": ..., "first_scanned": ..., "last_scanned": ..., "details": ... }, "ticket": { "number": ..., "name": ..., "status": ..., "severity": ..., "due_date": ..., "url": ..., "new_ticket_subject": ..., "owner": { "name": ..., "first_name": ..., "last_name": ..., "email": ... } }, "vulnerability": { "name": ..., "severity": ..., "summary": ..., "solution": ..., "impact": ..., "detection": ..., "insight": ..., "cvss2": ..., "cvss3": ..., "cves": ..., "hid": ..., "exploits": ..., "patches": ..., "ransomware": ..., "url": ... } }

Best practices for using placeholders

Test your payload: Verify the placeholder names are spelled correctly and match your use case.
Use meaningful field names: Map placeholders to field names that make sense in your external system (e.g., owner_email instead of a generic field name).
Handle missing data: Some placeholders may be empty depending on the event type. Plan for this in your external system.
Keep payloads simple: Include only the placeholders you actually need rather than all available fields.
Document your custom fields: If you're building a custom integration, document which fields you're using so others on your team understand the webhook structure.

Related information

For guidance on setting up webhooks, see the following article:

How do I integrate with Webhooks?

For more information, please contact our customer support.