How to Require Human Approval Before Restarting a Production Service via API

Catch a remediation alert with a webhook, pause for an on-call engineer to approve, then call your platform's REST control API to restart the service and confirm the result to Slack and email, all in one Spojit workflow.

What This Integration Does

Automated alerting is fast, but blindly restarting a production service on every alert is risky. This workflow puts a human in the loop: when your monitoring system fires a remediation webhook, Spojit pauses on a Human node and waits for an on-call engineer to approve or reject the restart. Only after an explicit approval does Spojit call your platform's control API to bounce the service, and it then reports the outcome to a Slack channel and to a wider distribution list by email. A rejection or a timeout stops the workflow cleanly, so nothing happens to production without a person signing off.

The run starts from a Webhook trigger verified with a Custom HMAC signing connection, so only your alerting system can start it. The alert payload (service name, environment, reason) flows through every step as variables. The Human node leaves the run paused in the Approvals inbox until someone acts; on approval the workflow resumes and the http connector issues the restart, capturing the API response. Re-runs are independent: each incoming alert is its own execution with its own approval, so an approval for yesterday's alert never authorizes today's restart.

Prerequisites

A Webhook signing connection using the Custom HMAC scheme, so your alerting system can sign requests. See the connections guide if you have not set one up yet.
Your platform's REST control API reachable over HTTPS, plus an API token or key you can send in an Authorization header. No native connector is needed; you call it through the http connector.
A Slack connection with permission to post to your operations channel, and the target channel ID (for example C0123456789).
The email addresses of your on-call approvers, and your wider notification recipients added to Settings > General > Email recipients so the Send Email node can reach them.
At least one user, role, or team in your workspace to assign as an approval slot.

Step 1: Catch the alert with a Webhook trigger

Add a Trigger node and set its type to Webhook. Under the signing connection, choose your Custom HMAC connection so Spojit verifies the signature on every inbound POST and rejects anything unsigned. Copy the generated webhook URL into your monitoring or alerting tool. When an alert fires, your system posts a JSON body that Spojit parses into {{ input }}. Design your payload to carry exactly what the restart needs:

{
  "service": "checkout-api",
  "environment": "production",
  "reason": "p95 latency over 2000ms for 5m",
  "requestedBy": "pagerduty"
}

The trigger immediately returns 202 with an executionId to your alerting system, then the run continues asynchronously through the rest of the nodes.

Step 2: Pause for on-call approval with a Human node

Add a Human node right after the trigger. This is the safety gate: the workflow will not touch production until a person approves. Configure it:

Label: Approve production restart
Message: a clear summary the approver sees, for example Restart {{ input.service }} in {{ input.environment }}? Reason: {{ input.reason }}
Urgency: set to High so it stands out in the Approvals inbox and notifications.
Timeout (minutes): a value such as 30. If no one acts in time, the node times out and the workflow halts (a timeout is treated as a rejection).
Email approvers: turn this on so your on-call engineers are emailed the moment the request lands.
Approval slots: add one slot and assign your on-call user, role, or team as an atom. Any atom in the slot can satisfy it; if you add more than one slot, every slot must be satisfied before the run resumes.

Approvers act in the Approvals inbox at /approvals, via the dashboard widget, or the menu badge. On approval the node outputs { approved: true, approvalId, outcome: "APPROVED" } and the run continues. On rejection or timeout the run stops here and the restart never happens.

Step 3: Restart the service with the http connector in Direct mode

Add a Connector node on the http connector and keep it in Direct mode so the call is deterministic and costs no AI credits. Choose the http-post tool and point it at your platform's restart endpoint. Map the fields:

URL: https://api.yourplatform.com/v1/services/{{ input.service }}/restart
Headers: an Authorization header carrying your API token, for example Bearer YOUR_TOKEN, plus Content-Type: application/json.
Body: the restart parameters your control API expects.

{
  "environment": "{{ input.environment }}",
  "reason": "{{ input.reason }}",
  "approvalId": "{{ approval.approvalId }}"
}

Save the response to an output variable such as restart. Because this node only runs after the Human node resumes the workflow, the API is never called without a recorded approval. If your control API uses a different verb, swap to http-put or http-patch as appropriate.

Step 4: Confirm the outcome from the API response

Your control API typically returns a status you can read to confirm the restart actually took. Add a Condition node that checks the response, for example whether {{ restart.status }} equals restarting or ok. Route the true branch to the success notifications in the next steps. On the false branch, send a clearly worded failure message so the on-call engineer knows the API accepted the request but the service did not come back healthy. Keeping this check explicit means a green Slack message always reflects a real, confirmed restart rather than just a successful HTTP call.

Step 5: Post the result to Slack

On the success branch, add a Connector node on the slack connector in Direct mode and choose the send-message tool. Set the channel to your operations channel ID and build a message from the variables you have collected:

:white_check_mark: {{ input.service }} restarted in {{ input.environment }}
Reason: {{ input.reason }}
Approved via Spojit (approval {{ approval.approvalId }})
API status: {{ restart.status }}

This gives the whole on-call channel an instant, auditable record of who approved the action and what the platform reported back. On the failure branch, send a separate send-message call with an alert prefix so the team can escalate.

Step 6: Email the wider distribution list

Add a Send Email node so stakeholders who do not watch Slack still get the outcome. This uses Spojit's built-in mail service, so no connection is required. Configure:

Recipients: a comma-separated list such as ops-leads@yourcompany.com, sre@yourcompany.com. Remember external recipients must be on the org allowlist under Settings > General > Email recipients.
Subject: {{ input.service }} restarted in {{ input.environment }}
Body: a plain-text summary that includes the reason, the approval ID, and the API status from {{ restart.status }}.
If sending fails: choose Continue anyway so a mail hiccup does not mask a successful restart.

If you need the email to come from your own domain instead of Spojit's mail service, swap this for a Connector node on the resend or smtp connector using its send-email tool.

Tips

Use the approval ID. Passing {{ approval.approvalId }} into the restart payload and the notifications creates a clean audit trail linking the action back to who approved it.
Set the timeout to match your on-call SLA. A 30-minute timeout means a forgotten alert fails safe rather than leaving the run paused forever.
Use High urgency only for genuinely production-impacting actions so approvers learn to trust the signal.
Keep the http node in Direct mode. The restart is a single predictable call, so you do not want an AI agent deciding when or whether to fire it.

Common Pitfalls

Forgetting the signing connection. Without a Custom HMAC signing connection on the Webhook trigger, anyone who learns the URL could start a restart request. Always verify the signature.
Expecting an on-reject branch. A rejection or timeout halts the workflow; there is no downstream "on reject do X" path. If you need a rejection to notify someone, that has to be handled outside this run.
Trusting a 200 as proof. A successful http-post means the API accepted the request, not that the service is healthy. Keep the Condition check on the real status field.
Recipients not allowlisted. The Send Email node silently cannot reach addresses that are not on the org allowlist, so add your distribution list under Settings > General > Email recipients first.

Testing

Validate against a non-production target before you wire it to real alerts. Point the http-post URL at a staging service, then send a signed test POST to the webhook URL with a sample payload. Approve the resulting request in the Approvals inbox and confirm the staging service restarts, the Slack message posts, and the email arrives. Then run the negative path: trigger a second request and reject it (or let it time out) to confirm the workflow halts and no restart fires. Only once both paths behave should you switch the URL to production and enable the workflow.