Book Demo Start Free Trial

Product

Network Pulse Incident Operations Asset Lifecycle Engineer & SLA Inventory & Spares Operations Wallboard

Solutions

Manufacturing Healthcare Education Corporate & Multi-location IT

More

Pricing Blog Help Centre FAQ
Start Free Trial Book a Live Demo Sign in to your workspace

Help Center › Visibility and reporting

Forward any monitoring tool with a signed webhook

Send device events to InfraCue Network Pulse from any monitoring tool that can make a signed HTTP POST: headers, HMAC signing, payload fields and a working example.

Updated 28 Sep 2026

Network Pulse has ready-made handlers for Zabbix and Nagios. Anything else — PRTG, SolarWinds, ManageEngine, Datadog, a Grafana alert, a Python script watching something only you care about — can forward events too, as long as it can send a signed HTTP POST.

You map the fields yourself, which takes about ten minutes and is worth doing properly once.

Step 1 — Create the connection

  1. Open the Integrations tabNetwork Pulse → Integrations.
  2. Name the integrationName it after the tool that will send the events.
  3. Choose Generic signed webhook as the sourceThen select Create signed endpoint.
  4. Copy the credentials before you leave the pageThe endpoint, the integration key and the signing secret. The secret is shown once and is never displayed again.

That screen also gives you a working command with your own credentials filled in. Run it before you write any integration code — if it returns "success":true and a device appears, the endpoint and credentials are proven and everything after that is your own mapping.

Step 2 — Sign each request

Send three headers with every POST:

Header Value
X-InfraCue-Integration-Key the integration key
X-InfraCue-Timestamp Unix seconds, accepted within five minutes of our clock
X-InfraCue-Signature sha256= followed by the HMAC below

The signature is an HMAC-SHA256, in lowercase hex, over the timestamp, a literal full stop, and the exact raw request body:

signature = HMAC_SHA256(timestamp + "." + raw_body, signing_secret)

Sign the bytes you actually send. If you build the JSON, sign it, then re-serialise it before sending, the signature will not match.

Step 3 — Send the event

A complete, working example in shell:

TS=$(date +%s)
BODY='{"events":[{"device_id":"sw-core-01","name":"Core switch, Mumbai BKC","host":"10.20.0.1","status":"down","severity":"critical","title":"ICMP unreachable","message":"3 consecutive probes failed"}]}'
SIG=$(printf '%s.%s' "$TS" "$BODY" | openssl dgst -sha256 -hmac 'YOUR_SIGNING_SECRET' -r | cut -d' ' -f1)

curl -sS -X POST 'https://YOUR-WORKSPACE/api/network-pulse/ingest.php?company=YOUR-SLUG' \
  -H 'Content-Type: application/json' \
  -H 'X-InfraCue-Integration-Key: YOUR_INTEGRATION_KEY' \
  -H "X-InfraCue-Timestamp: $TS" \
  -H "X-InfraCue-Signature: sha256=$SIG" \
  -d "$BODY"

The fields that matter

Field Notes
device_id Required. Your stable identifier for the device. This is the key we match on, so keep it constant across restarts — an identifier that changes creates a new device every time and burns through your plan's device count.
status One of up, down, degraded, maintenance, unknown. Anything else becomes unknown rather than being rejected.
severity info, warning or critical. Alert rules compare against this.
name What people should see on the wallboard. Defaults to device_id.
occurred_at When it happened, not when you sent it. Include the timezone — ISO 8601 is safest.
event_id Your own id for the event. Supply it and retries are deduplicated properly.
affects_state Send false for an event worth recording that says nothing about device health. See below.

The full reference, including every optional field, the response shapes and the rate limit, is on the Network Pulse Ingest API page.

Send a recovery, or the device stays down

Device status is whatever the most recent event said. If your tool sends you the problem but never tells you it cleared, the device stays down in InfraCue forever and any ticket it raised stays open. Wire up the resolved or recovered path at the same time as the alert path, not afterwards.

Use affects_state for events that are not health signals

Plenty of monitoring events are worth recording without being a statement about whether the device is healthy: a configuration change, an agent restart, a backup job finishing. Send those with "affects_state": false. We store them on the device's timeline and leave its status, severity and last-changed time exactly as they were, and no ticket is raised.

Use this rather than sending a status you do not mean. Because status is last-write-wins, an informational event sent as up will clear a real outage from your wallboard.

Before you rely on it

  • Run the test command from the Integrations screen first, so you know the credentials work.
  • Check the clock on whatever is sending. Requests more than five minutes out are rejected.
  • Send a recovery for every problem, and confirm the device goes back up.
  • Keep device_id stable across restarts and re-deploys.
  • Store the signing secret wherever you keep other credentials, not in the script itself.

If the request is rejected

Response Usually means
401 The signature did not match, the timestamp is outside the five-minute window, or the integration key is wrong or revoked. Check you signed the exact bytes you sent.
400 A header is missing, or the body is not a JSON object.
422 The workspace slug in the URL is wrong, or Network Pulse is not enabled for that workspace.
429 You are sending faster than the rate limit. Batch events into a single request — up to 100 per POST.