n8n Integration Guide
Integration overview
Sentinel meets n8n at both ends of a workflow. Outbound, every incident and recovery is posted to an n8n Webhook node as JSON, so an outage can start any automation you can build in n8n. Inbound, an HTTP Request node with an API token reaches the whole REST API: list and create monitors, pause one around a deploy, read incidents, or pull the team roster for an access review.
There is no Sentinel node to install. Both workflows below use nodes that ship with n8n, so they import into n8n Cloud and self-hosted n8n alike.
Requirements
- In n8n: any instance Sentinel can reach over HTTPS. A self-hosted n8n on a private network needs a reverse proxy with TLS or a tunnel in front of its webhook URL.
- For the incident trigger: a team on the Pro plan or above (outbound webhooks), and a team owner or admin to add the webhook.
- For API pulls: an API token from User Settings → API Tokens, with the permissions the workflow needs. Read-only is enough for reports. Available on every plan, including Free.
Workflow 1: incident to Slack
Nodes: Webhook → IF → Slack (two branches). Download sentinel-incident-to-slack.json.
- In n8n, open the workflow menu (the three dots at the top right) and choose Import from File. Pick the downloaded file.
- Open the Webhook node. Its authentication is set to Header Auth. Create a Header Auth credential with a name such as
X-Sentinel-Tokenand a long random value. Keep the value for step 5. - Open each Slack node, pick your Slack credential and the channel to post in.
- Activate the workflow and copy the Webhook node's Production URL.
- In Sentinel, open your team's Integrations page, scroll to Webhooks and add one. Paste the production URL, choose the Custom header auth type, enter the same header name and value as the n8n credential, and pick the severities this workflow should hear about.
- Press Test on the new webhook. A test event appears in Slack within a few seconds. If it does not, check the n8n execution list for a rejected request.
The IF node sorts events by name: anything ending in down, failed,
missed, missing or found is an outage and
takes the true branch, everything else (up, recovered,
resolved) is a recovery. Replace the Slack nodes with whatever you run: a Jira node to open
and close a ticket, an HTTP Request to your own API, an SMS.
Workflow 2: weekly access review
Nodes: Schedule Trigger → HTTP Request → Code → Slack. Download sentinel-access-review.json.
- In Sentinel, create an API token under User Settings → API Tokens. Read permission is all this workflow needs.
- Import the file into n8n as above.
- Open the HTTP Request node. It authenticates with a generic Bearer Auth credential. Create one and paste the token.
- Open the Slack node and pick your credential and channel.
- Run the workflow once with Test workflow to see the message, then activate it. The Schedule Trigger fires Monday at 08:00 in your n8n instance's timezone. Change it to daily if your auditor wants nightly evidence.
The Code node reads the GET /api/v1/users response, which lists every member with
role, status, mfa_enabled,
added_at and last_login_at, and flags anyone without MFA,
anyone disabled, and anyone who has not signed in for 90 days. Edit the thresholds in the node to match your policy.
What the Webhook node receives
The body is the standard Sentinel webhook payload: event, a monitor
object with its dashboard link, a status object with the root cause, the diagnosis and the
confirming regions, and an incident object with its own link. In n8n it is available as
{{ $json.body.event }}, {{ $json.body.monitor.name }} and so on.
The full shape and the list of event names are on the webhooks page.
If you add a signing secret to the webhook in Sentinel, every request also carries an
X-Webhook-Signature header with an HMAC-SHA256 of the body. Header auth is simpler in n8n and
is what the imported workflow uses, but a Code node can verify the signature instead if your policy prefers it.
Useful endpoints for HTTP Request nodes
GET /api/v1/monitorsandGET /api/v1/monitors/{id}: monitors with their current statusPOST /api/v1/monitors: create a monitor, for example when a client is onboardedPOST /api/v1/monitors/{id}/pauseand/resume: around a deployPOST /api/v1/monitors/{id}/check: run a check now, from every regionGET /api/v1/incidents: incidents, open and resolvedGET /api/v1/users: team members for access reviewsGET /api/v1/webhook-endpoints/{id}/deliveries: what Sentinel sent to n8n and what n8n answered
Every request takes Authorization: Bearer YOUR_API_TOKEN. The
API Access page covers tokens and permissions and the
API reference lists every field.
FAQ and troubleshooting
- Test says the endpoint returned 403. The header name or value in Sentinel does not match the Header Auth credential in n8n. Header names are matched exactly.
- Test says the endpoint returned 404. The workflow is not active, or the Test URL was pasted instead of the Production URL. Test URLs only work while the node's listening panel is open.
- The IF node sends recoveries down the outage branch. Check the event is read as
{{ $json.body.event }}. In the Webhook node's v1 the body sits at the top level instead of underbody. - HTTP Request returns 401. The token was pasted with a trailing space, or it was revoked. Create a new one under User Settings → API Tokens.
- HTTP Request returns 403 on a write. The token lacks the create, update or delete permission the endpoint needs. The response names the missing one.
How to uninstall
Delete the webhook from Sentinel's Integrations page, which stops deliveries at once, and deactivate or delete the workflow in n8n. For the API half, revoke the token under User Settings → API Tokens.
Support
For help with this integration, email [email protected] or use the contact form. Include the webhook's name from the Integrations page and, for a delivery problem, the time of the alert.