Turn a Webhook Into a Push Notification with PingRoom

To turn a webhook into a push notification with PingRoom, create an incoming webhook in a Room, then POST a short JSON event to its secret URL. PingRoom creates one Room Ping and sends it to eligible members through the normal delivery path.

Updated October 11, 2026 with the current Pro requirement, browser setup, request contract, response shape, and recipient outcome.

This is an incoming webhook: another app sends an event into PingRoom. An outgoing webhook moves in the other direction, forwarding selected Room events to your system.

What you need before you send

• The Room owner needs an active PingRoom Pro plan. Incoming and outgoing webhooks are Pro connections.
• Create or choose the Room whose members should receive the Ping.
• The source must be able to send an HTTPS POST request with JSON. If it sends a fixed payload that PingRoom does not accept, map the fields in an automation tool or a small server-side relay first.
• Room members who want a native alert need PingRoom on their device with notifications allowed. A successful API response confirms that PingRoom created and queued the event; it does not guarantee what a particular phone displays under every network, Focus, or notification setting.

PingRoom can store up to four incoming webhooks in one Room. Each webhook may use a Quick Ping preset, or send its own title and message without consuming a preset. The incoming webhook feature overview explains where this connection fits before you work through the request contract below.

Create the incoming webhook

Open your Rooms in the PingRoom browser app, choose the destination Room, then open Settings → Connections → From another app.

1. Select Add Webhook, open the new Webhook, choose Edit, and rename it after its source, such as Release pipeline.
2. Leave Quick Ping on Custom message for events that supply their own copy.
3. Add an optional default title and message for requests that omit them.
4. Choose an icon, color, and sound that make the source recognizable.
5. Select Save, use Test once, then copy its URL into protected configuration.

The generated URL contains the webhook secret. It is the credential: keep the whole URL out of source control, browser-side code, screenshots, and logs. If it leaks, use the circular-arrow Regenerate secret button beside Webhook URL and replace the old URL at the source.

Send one useful event

This illustrative deployment event uses fields from the current PingRoom request contract. The URL remains in an environment variable, so the example contains no live secret.

curl --fail-with-body --silent --show-error \
  -X POST "$PINGROOM_WEBHOOK_URL" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: release-4821" \
  -d '{
    "title": "Deploy finished",
    "message": "Production is live",
    "data": {"environment":"production","release":"8f31c2"},
    "correlation_id": "deploy-4821"
  }'

The title is the lock-screen headline. The message is the short fact a person needs. data carries bounded machine-readable context for connected systems; do not use it as a place to hide credentials or private logs. correlation_id gives related events a stable identity without claiming that PingRoom owns the deployment state.

The incoming-webhook reference lists every accepted field, current text and data limits, error codes, cooldown behavior, and optional acknowledgement controls.

Read the response correctly

A successful request returns HTTP 200. The exact IDs and timestamp vary. This trimmed response shows the fields that matter for a custom Ping that is not attached to a Quick Ping preset:

{
  "success": true,
  "message": "Webhook triggered successfully",
  "notification_id": "<notification-id>",
  "room": { "id": "<room-id>", "name": "Build alerts" },
  "webhook": { "id": "<webhook-id>", "name": "Release pipeline" },
  "action": null,
  "notification_title": "Deploy finished",
  "notification_message": "Production is live",
  "action_state": null,
  "triggered_at": "<ISO-8601 timestamp>"
}

success: true means PingRoom accepted the request and created the Ping. notification_id is the event identity. action: null means this call used the webhook's custom content instead of a Quick Ping preset. action_state remains null because this example does not request acknowledgement.

For Room members, the practical outcome is one new Ping titled Deploy finished with the message Production is live. It appears in Room history and enters PingRoom's delivery queue for eligible recipients. Device delivery can still be delayed or suppressed by connectivity, operating-system policy, Room mutes, or notification settings.

The deployment system remains the source of truth for whether production is actually live. A Ping reports that event; it does not perform or verify the deployment.

Choose direct POST, a relay, or an outgoing webhook

Calling a PingRoom URL from another product does not make that product a native PingRoom integration. It is a webhook recipe unless both products document a dedicated connection.

For a publication-specific GitHub example, send one release-published alert to a shared Room with a no-checkout workflow and fixed phone copy.

For concrete automation examples, send a GitHub Actions result to a Room with a final dependent job, send a Bitbucket Pipelines success to a Room from the selected final step, send an Azure DevOps build success to a Room with one filtered service hook, send an AWS CodeBuild success to a Room with a success gate and stable build ID, alert a shared review Room when a GitHub draft becomes ready with a no-checkout workflow, send a Node-RED event to a Room with a Function and HTTP Request node, send a Power Automate flow result to a Room with a protected HTTP action, send an Airtable state change to a Room with a protected Run a script action, send a Google Sheets status change to your phone with an authorized Apps Script edit trigger, send one Make.com scenario result to a Room through HTTP V4, or send one Pipedream workflow result through its HTTP POST action.

For Supabase, send one intentional database event through an authenticated Edge Function. The recipe uses a dedicated UUID-only event table and forwards no changed-row values.

For a task-board example, send one selected Trello card move to a shared Room with Trello Automation’s HTTP request action. The guide keeps the card record in Trello and documents the direct recipe’s duplicate boundary.

For a Jira workflow, send one selected work-item transition to a shared Room with Jira Cloud Automation’s Send web request action. The guide keeps work details in Jira and gives retries a stable transition identity.

For monday.com, send one selected board status to a shared Room with the workflow builder’s Send HTTP Request block. The guide also explains why monday.com’s separate challenge-response Webhook integration cannot point directly at a PingRoom incoming URL.

For Smartsheet, send one selected row status to a shared Room with a column-filtered webhook, a signed relay, and a current-row lookup. The guide keeps sheet details in Smartsheet and sends fixed privacy-minimal copy to PingRoom.

For Notion, send one selected database status to a shared Room with a database automation's Send webhook action. The direct recipe uses the PingRoom webhook's saved message and shares no task properties; dynamic task details belong behind a relay.

For ClickUp, send one selected task status to a shared Room through a privacy-minimizing relay. The relay authenticates the Automation call, discards ClickUp's broad task object, and forwards only fixed bounded copy with stable event identity.

For Linear, send one selected issue state to a shared Room through a team-scoped Issue webhook and a relay that verifies the raw-body signature, checks timestamp freshness, and forwards no issue content.

For Asana, send one selected task completion to a shared Room through a signature-verifying relay. The relay completes Asana's webhook handshake, checks the HMAC signature, reads the task's latest completion state, and keeps task details out of the phone alert.

For Docusign, send one verified envelope-completed signal to a shared Room with JSON SIM, raw-body HMAC verification, exact account and configuration gates, and fixed copy that forwards no agreement or signer details.

For Datadog, send one selected monitor transition to a shared Room with a direct privacy-minimal payload, event-level idempotency, and a clear boundary between shared awareness and native paging.

For HubSpot, send one selected deal-stage change to a shared Room through a signed, queued relay. The receiver keeps HubSpot native notifications first, filters one portal, app, property, and stage, and forwards no deal or contact data.

For Zendesk, send one selected urgent-ticket event to a shared Room through a signature-verifying relay. The receiver keeps Zendesk agent notifications first, accepts one fixed created-ticket marker, and forwards no requester or ticket content.

For Freshdesk, send one selected urgent-ticket event to a shared Room through a custom-header-authenticated relay. The receiver keeps Freshdesk mobile notifications first, accepts one fixed route and event marker, and forwards no requester or ticket content.

For Intercom, send one contact-started conversation event to a shared Room through a signature-verifying relay. The receiver keeps Intercom's Inbox and native mobile notifications first, then forwards fixed copy without contact or conversation content.

For Mailchimp Marketing, send one campaign-finished event to a shared Room through a raw-body signature-verifying relay. The receiver keeps Mailchimp mobile push first, queues only an opaque retry key, and forwards fixed copy without campaign, audience, contact, or report data.

For PostHog, send one filtered product event to a shared team phone with fixed privacy-minimal copy and the event UUID reused for exact-retry identity.

For Todoist, send one selected completed task to a shared Room through a raw-body signature-verifying relay. The receiver filters one project, discards the task object, and reuses Todoist's delivery ID for replay-safe fixed copy.

For form intake, send a privacy-minimal Google Forms response alert with a Forms-bound installable trigger, verify a signed Typeform response, verify one signed Tally response, or handle one completed SurveyMonkey response through a narrow relay. In every recipe, the submitted answers stay in the form system; the Room receives only approved copy.

For scheduling, verify a Calendly booking webhook and send one fixed Room alert. The recipe accepts one event type, keeps invitee details out of the Ping, and gives retries a stable event identity.

For commerce operations, send one paid Shopify order state to a shared Room with Shopify Flow. The direct recipe keeps customer and order details in Shopify while giving exact retries a stable event identity.

For WooCommerce, verify one order-created webhook and send a privacy-minimal shared alert. The relay verifies WooCommerce's raw-body signature, acknowledges the first-save ping, forwards no order or customer details, and does not treat order.created as paid.

For Lemon Squeezy, verify one paid order_created event and send fixed shared copy. The relay checks the raw-body signature, accepts one store, queues only a derived order identity, and forwards no customer, product, amount, currency, or receipt data.

For PayPal, verify one completed-capture event and send fixed shared copy. The relay uses PayPal's signature postback, accepts one REST app and merchant, queues only the event identity, and forwards no payer, amount, currency, order, or invoice data.

For Square, verify one completed Payment and send one fixed shared signal. The relay checks Square's raw-body HMAC against the exact notification URL, accepts one seller and location, deduplicates on payment identity, and forwards no buyer, amount, currency, receipt, order, or note data.

For Paddle, verify one completed transaction and send fixed shared copy. The relay checks Paddle's timestamped raw-body signature, accepts one product, deduplicates on event identity, and forwards no customer, amount, currency, invoice, custom-data, fee, or payout detail.

For RevenueCat, verify one production initial-purchase event and send fixed shared copy. The relay checks RevenueCat's timestamped raw-body HMAC, accepts one app, product, and entitlement, deduplicates on event identity, and forwards no customer, transaction, store, price, revenue, or currency detail.

For subscription billing, verify a Stripe invoice-payment failure and send fixed team copy through a small server-side relay. The relay verifies Stripe's raw-body signature, forwards no customer or invoice details, and uses the Stripe event ID for replay safety.

For a Vercel release, verify one production-promotion webhook and send fixed shared copy. The relay checks Vercel's raw-body signature, accepts one selected project, forwards no deployment metadata, and gives retries one event identity.

For a Netlify release, verify one production-deploy webhook and send fixed shared copy. The relay checks Netlify's signed raw-body digest, accepts one selected site's ready production deploys, and gives duplicate deliveries one event identity.

For a Buildkite pipeline, verify one finished-build webhook and send only an unblocked pass. The relay checks Buildkite's timestamped raw-body signature, accepts one pipeline UUID, and forwards none of the branch, commit, message, sender, or URL fields.

For Cloudflare Workers Builds, send one selected successful build to a shared Room. A Queue consumer filters one Worker and branch, forwards fixed copy, reuses the build UUID for replay safety, and does not treat build success as proof of deployment or health.

For Amazon S3, send one filtered object-created signal to a shared Room through a same-Region Lambda function. The recipe keeps object keys and file details in AWS, documents S3's duplicate and ordering boundary, and separates object creation from File Gateway or downstream-process completion.

For Dropbox, send one fixed shared signal when a selected folder receives a genuinely new file. The relay verifies Dropbox's raw-body HMAC, resumes a stored folder cursor, treats only an unseen file ID as new, and forwards no filename, path, account, or file content.

For Box, send one fixed shared signal when a file reaches a selected folder. The relay verifies either V2 signature, rejects stale deliveries and child-folder cascades, and reuses the stable webhook-event ID without forwarding file or collaborator details.

For Zoom, send one fixed shared signal when a selected host's cloud recording is ready. The relay verifies Zoom's timestamped raw-body signature, answers endpoint validation, queues one opaque meeting identity, and forwards no topic, participant, recording, transcript, or share details.

For Sentry, send one selected alert rule to a shared Room through a signature-verifying relay. The relay accepts one alert resource and action, forwards fixed privacy-minimal copy, and keeps issue titles, stack traces, users, tags, and event URLs in Sentry.

For Grafana, verify one selected alert group and send fixed firing or resolved copy. The relay checks Grafana's raw-body HMAC and timestamp, accepts one receiver, folder, rule, and alert instance, and forwards no labels, annotations, values, or investigation links.

For New Relic, route one selected issue transition through an authenticated relay. The relay accepts one workflow, priority, entity, and lifecycle state, forwards fixed activated or closed copy, and keeps issue titles, metrics, policies, and investigation links in New Relic.

For Prometheus Alertmanager, route one selected alert instance through a Bearer-authenticated relay. The relay accepts one receiver, alert, cluster, instance, and severity, forwards fixed firing or resolved copy, and derives retry identity from the alert fingerprint and start time.

For BugSnag, send one selected new production error through a narrow relay. The recipe accepts one project and firstException event, forwards fixed privacy-minimal copy, and documents why a secret path is a bearer credential rather than a webhook signature.

For Honeycomb, route one selected Trigger transition through a shared-secret relay. The recipe accepts one Trigger ID, environment, and TRIGGERED or OK state, maps Honeycomb's stable delivery ID to PingRoom idempotency, and keeps query and investigation detail in Honeycomb.

For Rollbar, send one selected New Item alert through a narrow relay. The recipe checks one project, environment, and error level, treats the URL token as a bearer credential, and forwards fixed copy without item or occurrence details.

For an Expo mobile build, verify one EAS Build completion and send fixed shared copy. The relay checks Expo's raw-body signature, accepts one app, build profile, platform, and finished state, and reuses the build ID for replay-safe delivery.

For a Docker Hub repository, send one fixed shared alert after an image push. The direct saved-message route keeps repository metadata out of the Room and documents when filtering, authentication, or durable duplicate control requires a relay.

For a Figma design file, send one privacy-minimal alert when someone creates a named version. The relay compares Figma's passcode, accepts one file key, and keeps the file name, version label, description, and user identity out of the Room Ping.

Make retries safe and alerts readable

Use one stable Idempotency-Key for one source event, and reuse the same body when retrying it. PingRoom can return the original completed response instead of creating a duplicate Ping. Use a new key when the event or body changes.

Keep the source selective. A webhook should fire when the human situation changes, not for every log line or state refresh. For a deployment, Started, Succeeded, Failed, and Rolled back are useful transitions; every build step usually is not. Give recovery or rollback a title that cannot be mistaken for the original failure.

Before connecting real traffic, test:

1. One expected event with safe sample data.
2. One malformed request and the source's error handling.
3. The same request twice with the same idempotency key.
4. A locked recipient phone, to check what the title and message reveal.
5. Secret rotation, so the source rejects the old URL and uses the new one.

For critical systems, keep the existing pager, escalation path, durable log, and retry controls. PingRoom is the attention path to the Room, not the only record that the event occurred.

Send your first webhook Ping

Start in PingRoom's browser app: create a private Room for the people who need the update, add an incoming webhook, and send the sample event with non-sensitive data.

If you want the webhook to keep its own saved message instead of a Quick Ping preset, read Give each webhook its own Ping. For the broader two-way model, see Webhooks Turn Rooms Into Infrastructure.