How to Send Klaviyo List-Join Alerts to a Shared Room

To send a shared phone alert when a profile first joins one selected Klaviyo list, start a list-triggered flow, POST a fixed event marker and the opaque Klaviyo profile ID to a guarded relay, then let the relay hash that ID into PingRoom’s replay key and forward fixed copy. Contact details stay in Klaviyo. The Room receives only Klaviyo list entry and Open Klaviyo to review the selected list.

This is a webhook recipe, not a native Klaviyo integration. Klaviyo remains the record for profiles, list membership, and marketing consent. PingRoom gives a small, stable group one short signal that something worth reviewing happened.

First decide whether the shared Room helps

Klaviyo already supports internal alerts inside flows. Use that route when email is the right destination. Add PingRoom when the same low-volume event should reach a deliberately chosen Room of people who may not spend the day in Klaviyo or the same inbox.

The Room should not become a shadow customer database. A useful shared alert says what happened and where to review it. It does not repeat the person’s name, email, phone number, location, consent state, campaign history, purchases, or profile URL.

A list entry is not always a new consent

Klaviyo explains that a profile can enter a list through a sign-up form, integration, API, manual action, or CSV import. List membership is separate from marketing consent. That is why the Room copy says list entry, not new subscriber.

If your real question is whether someone granted email or SMS marketing consent, review Klaviyo’s consent record and its Subscribed to List metric. Do not infer consent from this Ping.

This recipe also chooses a deliberate replay boundary: one signal per profile and flow. If the same profile later leaves and re-enters the list, the hashed replay key remains the same and PingRoom treats the request as a replay. That makes the alert mean “this profile first entered this selected workflow,” not “every resubscription or re-import.” Use a different source event with its own stable event ID if repeat entry is the task you need to track.

What you need

• A Klaviyo list that represents one useful review queue.
• A Klaviyo Manager, Admin, or Owner account with multi-factor authentication. Klaviyo requires those permissions and MFA to add a flow webhook.
• A small HTTPS relay that can keep three server-side secrets: the expected Klaviyo flow ID, a dedicated route token, and a replay-hashing secret.
• A private PingRoom Room whose owner has PingRoom Pro. Incoming webhooks are Pro connections.
• A dedicated test profile that contains no real customer data.

The relay is important because Klaviyo documents X-Klaviyo-Flow-ID as an identifier, not as proof that the request came from Klaviyo. The separate high-entropy route token is the authentication check. The relay also prevents the opaque Klaviyo profile ID from reaching PingRoom.

Prepare the PingRoom destination

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

1. Add an incoming webhook and name it after the selected Klaviyo list.
2. Keep Quick Ping on Custom message.
3. Save and test it once.
4. Copy the complete webhook URL into the relay’s protected server configuration.

The URL contains the webhook secret. Do not put it in the Klaviyo payload, source code, screenshots, or logs. The relay should be the only system that knows both the Klaviyo route token and the PingRoom URL. The incoming-webhook reference documents the current request fields, limits, cooldown behavior, and response shape.

Create one list-triggered Klaviyo flow

Create a new flow, choose a list trigger, and select exactly one list. Klaviyo recommends a list-triggered flow when the task is to act on entry into a specific list.

Add a webhook data action immediately after the trigger. Do not put a delay, split, or another action before it unless that delay or filter is part of the meaning you intend. A flow webhook sends when a profile reaches the action, which may be later than the original list entry.

Set the destination to your relay, not the PingRoom webhook URL. Add this private header:

X-Klaviyo-Route-Token: <a long random secret stored by the relay>

Use this two-field JSON payload:

{
  "event": "profile_joined_selected_list",
  "profile_id": "{{ person.KlaviyoID }}"
}

Klaviyo adds X-Klaviyo-Flow-ID to flow-webhook requests. The profile ID is an opaque source identifier: current profiles use a 26-character ID, while some older profiles have a six-character ID. It is not notification copy.

Do not add email, phone_number, first_name, last_name, consent properties, location, campaign fields, event history, or commerce data. The relay does not need them.

Turn the opaque ID into a replay key

The relay accepts only the expected marker, flow, route token, and profile-ID shape. It then derives a non-reversible identifier with HMAC-SHA256:

const digest = createHmac("sha256", KLAVIYO_REPLAY_SECRET)
  .update(`${EXPECTED_FLOW_ID}:${profileId}`)
  .digest("hex");

const replayKey = `klaviyo-list-${digest}`;

Use that value for both PingRoom fields that describe identity:

{
  "action": null,
  "title": "Klaviyo list entry",
  "message": "Open Klaviyo to review the selected list.",
  "correlation_id": "klaviyo-list-<hmac-digest>"
}

Send the same replay key in the Idempotency-Key request header. The relay should discard the raw profile ID after deriving the HMAC and avoid logging the incoming body. HMAC is used here because a plain hash of a short legacy ID would be easier to guess.

The tested fixture for this article checks the route token with a constant-time comparison, requires the expected X-Klaviyo-Flow-ID, accepts the documented legacy and current ID lengths, rejects extra fields, and verifies first acceptance, exact replay, changed-body conflict, and a second profile. The checks use representative data and a local PingRoom contract mock; no live Klaviyo profile or PingRoom delivery was used.

Rehearse the boundary before going live

Use a dedicated test list or a clearly labeled test profile. Then work through this sequence:

1. Keep the Klaviyo webhook action in draft while you verify the relay URL, route token, and expected flow ID.
2. Add the test profile to the selected list.
3. Confirm the relay accepted exactly the two expected JSON fields.
4. Confirm PingRoom received the fixed title and message with no contact or consent fields.
5. Replay the identical request and confirm it returns the original PingRoom result instead of creating another Ping.
6. Change the visible body while reusing the same replay key and confirm PingRoom rejects the conflict.
7. Send the same shape with the wrong flow ID and route token; both must stop at the relay.
8. Only then set the Klaviyo webhook action to Live.

Klaviyo treats a 2xx response as success and retries eligible failures. Return 2xx only after your relay has durably recorded the replay key or PingRoom has accepted the request. A process-local map is useful for a fixture, not for production deduplication.

Pingo the Pigeon, PingRoom’s fictional CMO, watched the duplicate reach the gate and stop. His contribution was to look as though this outcome had been obvious. The human team still owns the flow, secrets, privacy choices, and product claims; Pingo has no access to the list or the Room.

Read the result correctly

A successful Ping means the configured Klaviyo profile reached the webhook action and PingRoom accepted the fixed event. It does not prove:

• that this was the person’s first marketing consent;
• that an email or SMS campaign was sent or received;
• that the profile is still in the list now;
• that the contact is valid, engaged, or eligible for a campaign;
• or that every phone displayed a notification.

Klaviyo remains the place to review the profile, list entry, and consent history. PingRoom records the short shared signal and sends it through its normal delivery path. Network conditions, operating-system settings, Room mutes, and notification permissions can still affect device display.

If that boundary fits your team, create or choose the private Room, add its incoming webhook, and rehearse the test profile before making the Klaviyo action live.