# How to Send n8n Workflow Results to Your Phone

> Add one HTTP Request node, map a useful result, and keep retries from creating duplicate PingRoom alerts.

- Published: 2026-10-14
- Author: PingRoom
- Category: Developers
- Topics: n8n push notification, n8n workflow phone alert, send automation result to phone
- Canonical: https://pingroom.io/blog/n8n-push-notifications
- Cover image: https://pingroom.io/blog/n8n-push-notifications-cover.webp
- Cover description: Two PingRoom avatars arrange wooden workflow blocks while Pingo stands beside the single red result token and a face-down phone.

To send an n8n workflow result to your phone, add an **HTTP Request** node after the result you care about and POST a short JSON body to a PingRoom incoming webhook. Give the source event a stable idempotency key, and make sure only one summary item reaches the node when you want one alert.

This is a webhook recipe you configure, not a native n8n integration. n8n remains the source of the workflow result; PingRoom carries the selected update to a Room.

## Prepare the Room and protect its URL

The destination Room's owner needs active **PingRoom Pro** to use incoming webhooks. Room members need PingRoom with notifications allowed if they want native phone alerts.

Follow the [incoming webhook setup](/blog/webhook-to-push-notification): open the Room, go to **Settings → Connections → From another app**, add a connection named **n8n**, leave **Quick Ping** on **Custom message**, and copy the generated URL. The [incoming webhook feature overview](/features/incoming-webhook) explains when this Room connection is a better fit than sending the update manually.

The full URL contains the webhook secret. Do not put it in a public workflow template, screenshot, support message, or execution log.

If your n8n tier supports [custom variables](https://docs.n8n.io/code/cookbook/builtin/vars/), create `PINGROOM_WEBHOOK_URL` and use this expression in the node's URL field:

```text
{{ $vars.PINGROOM_WEBHOOK_URL }}
```

n8n documents variables for Cloud Pro and Enterprise, and self-hosted Business and Enterprise. If variables are unavailable, paste the URL only into a private workflow, restrict who can edit or export it, and rotate the webhook secret in PingRoom if the workflow is exposed.

## Choose one result worth interrupting someone for

Do not attach a phone alert to every step. Place it after the workflow has reached a state a person can act on: a batch finished, records need review, a report is ready, or a run stopped with a useful error summary.

This illustrative inventory workflow produces one item:

```json
{
  "run_id": "inventory-sync-2026-10-14-1800",
  "processed": 42,
  "failed": 2
}
```

`run_id` identifies this source event. Keep it unchanged when the HTTP node retries the same result. Use a new value when the source event or body changes.

## Configure the HTTP Request node

Add an **HTTP Request** node after the summary step. n8n's current [HTTP Request documentation](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/) uses these fields:

| Field             | Value                                                     |
| ----------------- | --------------------------------------------------------- |
| Method            | `POST`                                                    |
| URL               | the protected PingRoom webhook URL or variable expression |
| Authentication    | `None` — the secret is already in the URL                 |
| Send Headers      | on                                                        |
| Header            | `Accept: application/json`                                |
| Header            | `Idempotency-Key: {{ $json.run_id }}`                     |
| Send Body         | on                                                        |
| Body Content Type | `JSON`                                                    |
| Specify Body      | `Using JSON`                                              |

Use one expression for the JSON body so numbers remain numbers:

```javascript
{{
  {
    action: null,
    title: "Inventory sync finished",
    message: $json.processed + " updated; " + $json.failed + " need review",
    data: {
      workflow: "Inventory sync",
      run_id: $json.run_id,
      processed: $json.processed,
      failed: $json.failed
    },
    correlation_id: $json.run_id
  }
}}
```

The title and message are the short human-facing update. `data` preserves bounded structured context for connected systems, while `correlation_id` lets you relate later Pings to the same run. Do not send credentials, full logs, customer records, or anything that should not appear in Room history or on a lock screen.

## Make many workflow items become one alert

n8n normally processes each input item. If 40 items reach an HTTP Request node, it can send 40 requests. The official [looping guide](https://docs.n8n.io/flow-logic/looping/) also explains that **Execute Once** uses only the first input item; it does not summarize the rest.

Choose the behavior deliberately:

| Upstream output                             | What to do                                                                                  | Result                                |
| ------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------- |
| One item already contains the final summary | Turn on **Execute Once** as a guard                                                         | One request using that item           |
| Many records must contribute to one update  | Add an **Aggregate** or **Code** summary step first, then send its one item                 | One request with complete totals      |
| Every item genuinely needs its own Ping     | Leave **Execute Once** off, give each event its own idempotency key, and space the requests | One request per item, 6 seconds apart |

Each incoming webhook accepts one new Ping per 5 seconds by default and answers a faster request with HTTP 429 and a `retry_after` value. To send one Ping per item, add the HTTP Request node's **Batching** option with **Items per Batch** set to 1 and **Batch Interval** set to 6000 ms, which leaves a little headroom over the cooldown.

![A PingRoom avatar gathers many gray tokens into one tray while another places one red result token beside a phone, with Pingo guarding a small brass gate.](/blog/n8n-push-notifications-1.webp)

_AI-generated editorial illustration. The scene is an example, not a product screen. Pingo is PingRoom's fictional CMO and has no access to the workflow, webhook secret, or Room._

Pingo's illustrated job is to watch the stray duplicate token. The real control is less theatrical: send one summary item and keep the idempotency key stable.

## Retry without creating a second Ping

In the HTTP Request node's **Settings** tab, turn on **Retry On Fail**. Three tries with a short wait is a reasonable starting example for a non-urgent workflow; adjust it to the source, PingRoom's response, and your own latency budget.

Use the same `Idempotency-Key` and the same body on every retry of one event. PingRoom can return the completed response for that key instead of creating another Ping. If the body changes, use a new key; reusing a key with different content returns an idempotency conflict.

Do not turn on **Never Error** for this recipe. A rejected request should remain visible to the workflow. For more control, route an exhausted request into an n8n [error workflow](https://docs.n8n.io/flow-logic/error-handling/) rather than hiding the failure.

## Test the small result before publishing the workflow

Execute the HTTP Request node once with harmless sample data. A successful custom Ping returns HTTP 200 with a response shaped like this:

```json
{
  "success": true,
  "notification_id": "<notification-id>",
  "notification_title": "Inventory sync finished",
  "notification_message": "42 updated; 2 need review",
  "action": null,
  "action_state": null
}
```

Check four places before relying on the workflow:

1. The HTTP node output shows `success: true`.
2. Room history contains one Ping with the expected title and message.
3. The intended phone shows the amount of information you are comfortable placing on a lock screen.
4. Repeating the exact request with the same key does not create a second event.

A successful response confirms that PingRoom accepted and queued the Ping. Connectivity, operating-system notification policy, Focus, and Room mutes can still affect what a phone displays. The n8n execution remains the record of what the workflow actually did.

The complete PingRoom field limits, cooldowns, errors, and response contract live in the [webhook reference](/documents/webhooks).

## Send the first controlled result

Use this pattern when n8n has already decided what happened and a person or small group needs the short result. Keep dashboards, full logs, durable records, and critical escalation in their existing systems.

Start with a harmless workflow and [create or choose the destination Room](/app/rooms). Send one result, inspect the Room history and phone, then publish the workflow only after the duplicate test passes.