Integrations

n8n Integration

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.

  1. In n8n, open the workflow menu (the three dots at the top right) and choose Import from File. Pick the downloaded file.
  2. Open the Webhook node. Its authentication is set to Header Auth. Create a Header Auth credential with a name such as X-Sentinel-Token and a long random value. Keep the value for step 5.
  3. Open each Slack node, pick your Slack credential and the channel to post in.
  4. Activate the workflow and copy the Webhook node's Production URL.
  5. 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.
  6. 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.

  1. In Sentinel, create an API token under User Settings → API Tokens. Read permission is all this workflow needs.
  2. Import the file into n8n as above.
  3. Open the HTTP Request node. It authenticates with a generic Bearer Auth credential. Create one and paste the token.
  4. Open the Slack node and pick your credential and channel.
  5. 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/monitors and GET /api/v1/monitors/{id}: monitors with their current status
  • POST /api/v1/monitors: create a monitor, for example when a client is onboarded
  • POST /api/v1/monitors/{id}/pause and /resume: around a deploy
  • POST /api/v1/monitors/{id}/check: run a check now, from every region
  • GET /api/v1/incidents: incidents, open and resolved
  • GET /api/v1/users: team members for access reviews
  • GET /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 under body.
  • 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.