Give each webhook its own Ping

Your weekend market has one Room for the crew. Its Quick Pings are the signals people repeat all day: Need a hand, At the gate, Break time, and Packed up.

The vendor form also needs to alert the organizers when a new application arrives. That event belongs in the same Room, but it does not need to borrow one of the crew’s four reusable buttons.

An incoming webhook can now send its own Ping without a Quick Ping preset. Give it a saved title and message, or let each request supply the details for that event. The Room keeps its familiar human shortcuts while the form, build, sensor, or automation speaks in its own words.

This independent mode is live in PingRoom’s browser app and incoming-webhook API. Incoming webhooks are a Pro feature, and a Room can hold up to four of them. The resulting Ping still reaches the Room through PingRoom’s normal delivery path.

On the cover: Pingo the Pigeon™, our official mascot and fictional Chief Marketing Officer, watches one fresh card arrive beside four fixed bell pulls. It is an editorial metaphor, not a product screen, customer scene, or claim that Pingo can inspect webhook data. AI-generated artwork using approved Pingo references.

Keep the repeated signals repeatable

A Quick Ping works best when the Room reuses the same meaning. The market crew can learn that At the gate means someone needs access without reading a new instruction every time.

A webhook often carries a different fact on every request:

Those are illustrative setups, not customer stories. The source system decides when an event is real. PingRoom gives that event an attention path into the Room.

The same pattern is why webhook systems are useful in the first place: a service sends an HTTP request when a selected event happens instead of making you keep checking for it. GitHub’s webhook guide describes that event-subscription model for repository activity.

Create a webhook with a custom message

Open the Room in PingRoom on the web, then open Settings, Connections, and Incoming webhooks.

1. Select New webhook and give the connection a name that identifies its source, such as Vendor form.
2. Add a default title and message if you want an empty request to remain useful.
3. Under Quick Ping (optional), keep Custom message selected.
4. Choose the icon, color, and sound that should identify this source, then create the webhook.
5. Copy the generated URL into the service that will send the event, and use PingRoom’s test action before connecting real traffic.

The generated URL contains the webhook secret. Treat the entire URL like a password: keep it in protected configuration, leave it out of screenshots and public recipes, and rotate it if it is exposed. The current incoming-webhook reference documents the request fields, limits, errors, and secret-handling rules.

Let the request supply the event

An independent webhook uses its saved title, message, icon, color, and sound when the request does not override them. A request can replace the title or message for one event:

curl -X POST "$PINGROOM_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: application-1842" \
  -d '{
    "title": "New stall application",
    "message": "Ceramics · Saturday",
    "correlation_id": "application-1842"
  }'

Keep PINGROOM_WEBHOOK_URL in a secret manager or protected environment variable. Do not put it in browser-side code.

The title can contain up to 40 characters. The message can contain up to 120 characters in a private Room or 160 in a public Room. Keep lock-screen copy short, and leave private form answers, access tokens, payment details, and other sensitive data in the source system.

If a webhook is connected to a Quick Ping for another workflow, a request can send "action": null to use the webhook’s own content for that call. For a new independent webhook, leave the Quick Ping selector on Custom message and omit action from ordinary requests.

Pingo’s print workshop is a restrained aside: the blank card can carry the next event, while the Room’s fixed cues stay where people expect them. Pingo cannot read the card, operate your connection, or send a Ping.

Make retries boring

Event sources retry. Use an Idempotency-Key based on the source event and keep the body identical when retrying that event. PingRoom replays the original response for a completed matching key instead of creating another Ping. A different body with the same key is rejected.

Each incoming webhook has a cooldown, set to five seconds by default and configurable up to 60 seconds. PingRoom also limits each Room and secret to 60 calls per minute. These controls help with accidental bursts, but the source should still filter noisy events before sending them.

For the market form, one accepted submission should produce one event. A field autosave, validation check, or repeated delivery attempt should not become another alert. The webhook is the last attention step, not the place to decide whether the source event matters.

One Room, two kinds of signal

Keep Quick Pings for the moments people repeat. Use an independent webhook for events whose title or message comes from another system.

The crew still sees the four buttons it knows. The organizer gets the application alert without checking the form. One Room can hold both kinds of signal without making either pretend to be the other.

Start with the incoming webhook feature guide, then use the webhook reference for the live request contract.