# How to Send Zapier Workflow Results to Your Phone

> Add a Webhooks by Zapier POST step, map one useful result, and keep retries from creating duplicate PingRoom alerts.

- Published: 2026-10-15
- Author: PingRoom
- Category: Developers
- Topics: Zapier push notification, Zapier webhook phone alert, send workflow result to phone
- Canonical: https://pingroom.io/blog/zapier-push-notifications
- Cover image: https://pingroom.io/blog/zapier-push-notifications-cover.webp
- Cover description: Two PingRoom avatars arrange a short line of plain workflow cards while Pingo watches one red result token reach a face-down phone.

To send a Zapier workflow result to your phone, add a **Webhooks by Zapier** action after the step that produces the result. Choose **POST**, send a short JSON body to a PingRoom incoming webhook, and map one stable source-record ID into the `Idempotency-Key` header.

This is a webhook recipe, not a native PingRoom app in Zapier. Zapier decides when the workflow is ready; PingRoom carries the selected update to a Room.

## Check the two plan requirements

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

Zapier's current [webhook setup guide](https://help.zapier.com/hc/en-us/articles/8496326446989-Send-webhooks-in-Zap-workflows) lists Webhooks by Zapier for Professional, Team, and Enterprise plans, not Free. Check the current plan table before building around it.

Create the destination in PingRoom first: open the Room, go to **Settings → Connections → From another app**, add a connection named **Zapier**, and keep **Quick Ping** on **Custom message**. The [incoming webhook walkthrough](/blog/webhook-to-push-notification) shows the complete PingRoom setup.

Copy the generated webhook URL. Its final path segment is a secret. Treat the full URL like a password: do not publish it in a template, screenshot, support message, or shared documentation. Zapier's [API request guide](https://help.zapier.com/hc/en-us/articles/44391646192397-Ways-to-make-API-requests-in-Zapier) notes that credentials placed in a webhook URL are stored in the Zap step, so restrict who can view or edit the Zap.

## Choose one result worth a phone alert

Put the POST action after the workflow reaches a state someone can act on. A review becoming ready is useful. Every field change on the way there usually is not.

This illustrative trigger record is intentionally small:

```json
{
  "record_id": "review-1842",
  "status": "Ready for review"
}
```

Use an immutable ID from the trigger or source system. Do not build the identity from the current time: a retry would get a new value and could create a second Ping.

| Workflow output                             | Better alert choice                                                |
| ------------------------------------------- | ------------------------------------------------------------------ |
| One record reached a human decision point   | Send its short result                                              |
| Several records finished together           | Summarize them before the webhook step                             |
| A record changed repeatedly                 | Filter for the final useful state                                  |
| A full log or sensitive record is available | Keep it in the source system; send only the minimum useful context |

## Add the Webhooks by Zapier POST action

Add an action after the result step and choose **Webhooks by Zapier → POST**. Zapier's official guide uses these fields:

| Zapier field              | Value                                        |
| ------------------------- | -------------------------------------------- |
| URL                       | the protected PingRoom webhook URL           |
| Payload Type              | `json`                                       |
| Data: `title`             | `Review ready`                               |
| Data: `message`           | map the useful status from the previous step |
| Data: `correlation_id`    | map the trigger's stable `record_id`         |
| Header: `Accept`          | `application/json`                           |
| Header: `Idempotency-Key` | map the same stable `record_id`              |

Leave optional fields out unless the workflow needs them. For this example, the JSON sent to PingRoom is equivalent to:

```json
{
  "title": "Review ready",
  "message": "Ready for review",
  "correlation_id": "review-1842"
}
```

The title and message are human-facing. They can appear in Room history and on a lock screen, so do not map credentials, customer records, private form answers, or the entire previous-step payload.

![Two PingRoom avatars guide one red result token through a small brass gate while Pingo keeps a duplicate gray token aside.](/blog/zapier-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 Zap, webhook secret, or Room._

Pingo's illustrated role is to give the duplicate token a skeptical look. The real control is the stable source ID: one event keeps one key and one body across retries.

## Keep retries from creating duplicate Pings

Send the same `Idempotency-Key` and the same body whenever Zapier retries one source event. PingRoom can return the completed response for that key instead of creating another Ping.

Use a new key when the source event changes. If you reuse a key with a different body, PingRoom returns an idempotency conflict rather than guessing which request you meant.

The safe rule is:

- same source event, same body → same key;
- changed event or changed body → new key.

Zapier can run a step again during testing or after a failed execution. Mapping the trigger record's immutable ID into the header keeps that behavior tied to the source event, rather than to a particular Zap run.

## Test with harmless sample data

In the action step, use Zapier's test control to send one harmless sample. A successful custom Ping returns HTTP 200 with a response shaped like this:

```json
{
  "success": true,
  "notification_id": "<notification-id>",
  "notification_title": "Review ready",
  "notification_message": "Ready for review",
  "action": null,
  "action_state": null
}
```

Check the result in four places:

1. Zapier shows a successful action response.
2. Room history contains one Ping with the expected title and message.
3. The intended phone shows only information you are comfortable placing on a lock screen.
4. Repeating the exact request with the same key does not create another Ping.

HTTP 200 means PingRoom accepted and queued the Ping. It does not guarantee a visible phone alert: operating-system notification settings, Focus modes, connectivity, and Room mutes can still affect display. The source system and Zap history remain the records of what the workflow did.

If many records can finish at once, filter or summarize before the POST action. A PingRoom incoming webhook accepts one new Ping every 5 seconds by default, so a burst of individual requests can receive HTTP 429. The full field limits, cooldown, and error contract are in the [webhook reference](/documents/webhooks).

## Send the first controlled result

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

Start with a harmless Zap and [create or choose the destination Room](/app/rooms). Test one result, inspect Room history and the phone, then turn the Zap on only after the duplicate check passes.