How to Send Make.com Workflow Results to a PingRoom Room

To send a Make.com scenario result to a PingRoom Room, add HTTP V4 → Make a request after the module that produces the useful result. Send a short JSON body to the Room's incoming webhook, and map one stable source-event ID into both correlation_id and the Idempotency-Key header.

This is an outbound HTTP recipe, not a native PingRoom app in Make. Make decides when the scenario result is ready; PingRoom carries the selected update to a Room.

Choose the destination before adding HTTP

Make already has modules that send a push directly to a configured Apple iOS or Android device. Its mobile tutorial shows the device, title, and body fields. Use that simpler route when only one Make-connected phone needs the result.

Use a PingRoom Room when the same short result belongs in a shared destination with Room history. A dedicated service such as Pushover is another option when your workflow already uses its accounts, devices, and application token.

The Room owner needs active PingRoom Pro to create an incoming webhook. Room members need PingRoom with notifications allowed if they want native phone alerts.

Create the PingRoom destination

Open the Room, then go to Settings → Connections → From another app. Add a webhook named Make, keep Quick Ping on Custom message, save it, and copy the generated URL. The incoming webhook walkthrough covers the complete Room setup.

The URL's final path segment is the secret. Treat the full URL as a credential: do not place it in a public template, screenshot, scenario note, or shared run log. Limit access to the Make scenario that stores it.

Choose one result worth interrupting people for

Put the HTTP module after a filter or final state that a person can act on. A review becoming ready is useful. Every intermediate update usually is not.

This illustrative source bundle is intentionally small:

{
  "source_event_id": "review-1842",
  "status": "Ready for review"
}

Use an immutable ID from the source system. Do not generate a new timestamp-based ID every time Make retries the same bundle; that would turn one event into several identities.

Configure HTTP V4

After the useful result, add HTTP → Make a request. Make's current HTTP app reference calls this HTTP V4 and supports a JSON body, custom headers, parsed responses, and errors for unsuccessful status codes.

Use these settings:

Create three body fields in the data structure:

For the example bundle, the request body is equivalent to:

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

Using Make's data-structure input keeps mapped values as JSON fields instead of asking you to hand-escape a raw JSON string. The title and message can appear in Room history and on a lock screen, so do not map credentials, private form answers, full records, or the entire incoming bundle.

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 Make scenario, webhook secret, or Room.

Pingo's illustrated job is to look unimpressed by the excess tokens. The real filter belongs in the scenario, and the source system remains responsible for deciding that the result is ready.

Keep retries from creating duplicate Pings

Map the same immutable source-event ID into Idempotency-Key and keep the body unchanged when Make retries that event. PingRoom can return the completed response for that key instead of creating another Ping.

Use a new key when the event changes. If the same key arrives with a different body, PingRoom returns an idempotency conflict instead of guessing which request is correct.

The practical rule is:

• same source event and same body → same key;
• changed event or changed body → new key.

Keep this identity separate from Make's scenario execution ID. The same source event may appear in another execution during a retry or replay.

Test one harmless result

Run the module once with sample data that contains no secrets or personal records. A successful custom Ping returns HTTP 200 with a response shaped like this:

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

Check four things before turning the scenario on:

1. Make parsed a successful response and did not hide a 4xx or 5xx error.
2. Room history contains one Ping with the expected title and message.
3. The intended phone reveals only information you would accept on its 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 device alert: operating-system settings, Focus modes, connectivity, and Room mutes still affect display. The source application and Make execution history remain the records of what the workflow did.

If a scenario can emit many bundles at once, filter or aggregate before HTTP. Make's aggregator guidance describes combining several bundles into one. PingRoom incoming webhooks allow one new Ping every 5 seconds by default, so a burst of individual requests can receive HTTP 429. The full limits and errors are in the webhook reference.

Send the first controlled result

Use this pattern when Make has already selected an outcome and a person or small group needs the short result. Keep sensitive records, detailed logs, and critical escalation in their proper systems.

Create or choose the destination Room, test one harmless bundle, inspect Room history and the phone, then activate the scenario only after its filter and duplicate check behave as intended.