ctwa_clid Explained: Meta's Click-to-WhatsApp Click ID

Click-to-WhatsApp is the only Meta messaging destination that hands the advertiser a genuine click identifier. That single fact shapes everything about how WhatsApp funnels are measured, and it is repeatedly described wrongly in secondary sources. This page quotes Meta's own documentation for each claim, and says plainly where Meta documents nothing at all.

What is ctwa_clid?

ctwa_clid is a per-click identifier that Meta exposes to the business when a WhatsApp conversation starts from a click-to-WhatsApp ad. Meta's Conversions API guide defines it directly:

Two words in that sentence carry weight. Unique per click means it identifies a click event, not a person and not a conversation. And personal identifier is Meta's own classification, which is worth remembering when you decide where to store it and how long to keep it.

Where does ctwa_clid appear?

Inside the referral object on the inbound message webhook, and only when the message came from a click-to-WhatsApp ad. Meta's schema reference is unambiguous about the condition.

The per-message-type references carry the same condition as an inline comment in the payload syntax. On the text message webhook reference, Meta annotates the block with <!-- only included if message sent via a Click to WhatsApp ad -->, and describes the trigger as "A WhatsApp user sends a text message to a business via a Click to WhatsApp ad (an ad with a WhatsApp message destination)."

The full referral object

The referral object is worth reading in full, because ctwa_clid is only one of eleven fields and several of the others are useful for reporting without any Conversions API work at all.

Notice source_id, which Meta describes simply as "Ad ID." That gives you creative-level reporting inside your own inbox with no Conversions API integration whatsoever. If all you want is to know which creative produced which conversation, the referral object alone is enough. ctwa_clid is what you need additionally when you want Meta itself to learn from the outcome.

How do you send ctwa_clid back to Meta?

As an unhashed field inside user_data, on an event with action_source set to business_messaging and messaging_channel set to whatsapp. Meta's documented WhatsApp payload has this shape:

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1675999999,
      "action_source": "business_messaging",
      "messaging_channel": "whatsapp",
      "user_data": {
        "whatsapp_business_account_id": <WHATSAPP_BUSINESS_ACCOUNT_ID>,
        "ctwa_clid": "<CLICK_TO_WHATSAPP_CLICK_ID>"
      },
      "custom_data": {
        "currency": "USD",
        "value": 123
      }
    }
  ],
  "partner_agent": "<PARTNER_NAME>"
}

Two details trip people up. First, ctwa_clid belongs in user_data, not in custom_data, and there is no page_id on the WhatsApp path. Second, it must not be hashed. Meta's customer information parameters reference lists it alongside the other pass-through identifiers:

SHA-256 hashing a ctwa_clid out of caution is a common and silent failure. The request is accepted, the event is recorded, and it matches nothing. If you are unsure whether a payload is shaped correctly, our free Conversions API payload validator checks this exact class of mistake in the browser.

Which events can you send from a WhatsApp conversation?

Fourteen, and Meta lists them explicitly: Purchase, LeadSubmitted, InitiateCheckout, AddToCart, ViewContent, OrderCreated, OrderShipped, OrderDelivered, OrderCanceled, OrderReturned, CartAbandoned, QualifiedLead, RatingProvided and ReviewProvided.

Meta also constrains what those events are allowed to represent:

That is a real design constraint, not a formality. If a WhatsApp conversation ends with the customer buying on your website, the purchase is a website event with a website action_source, and the messaging channel gets the in-thread milestone instead, typically QualifiedLead or LeadSubmitted. Sending the website purchase as a business messaging event misrepresents where it happened.

How long is ctwa_clid valid?

Meta does not publish a validity period for ctwa_clid. We looked, and we are not going to invent one. What Meta does document is a hard limit on the Conversions API itself, and in practice that limit governs.

Across the Conversions API for Business Messaging guide, the customer information parameters reference, the WhatsApp webhook references, the incoming webhook payload schema and the ads that click to WhatsApp guide, Meta states no expiry, no lookback and no attribution window for ctwa_clid. The nearest thing to guidance is an instruction to persist it yourself:

The binding constraint is elsewhere, and it is documented precisely. Meta's server event parameters reference states:

So the practical rule is not "how old can the click be" but "how old can the event be". You may hold a ctwa_clid for months; you may not send an event whose event_time is more than seven days old, and if you try, the entire batch is rejected rather than the offending row. How that compares with Google Ads and TikTok is covered in conversion upload windows compared.

When is ctwa_clid missing?

In four documented situations, and treating each as a bug rather than an expected state wastes a great deal of debugging time.

• WhatsApp Status ad placements. Meta is explicit: the ctwa_clid property "is omitted entirely for messages originating from an ad in WhatsApp Status (WhatsApp Status ad placements)." The referral object still arrives; the click identifier does not.
• Organic conversations. The whole referral object is "Only included if message via a Click to WhatsApp ad." Someone who saves your number and messages you produces no referral object at all.
• Older On-Premises API versions. Meta states that ctwa_clid, "which is a required field for sending events over the Conversions API, is only available in the messages webhook on Biz API versions 2.45.1 and beyond."
• Later messages in the same thread. See the note above. Persist on first sight rather than expecting it again.

Does Messenger or Instagram have a ctwa_clid?

No. WhatsApp is the only Meta messaging surface with a click identifier. Messenger and Instagram both deliver a referral object carrying ref and ad_id instead, and the Conversions API identifies the person by a scoped user ID rather than by a click.

Field names as documented in Meta's Conversions API for Business Messaging guide and customer information parameters reference, checked 14 August 2026.

The consequences of that asymmetry are larger than they look, and they are worked through in click to WhatsApp, Messenger and Instagram: which identifier you actually get.

What ctwa_clid does not cover

It is a click identifier, not an attribution system. Three limits are worth stating before you build reporting on top of it.

• Deduplication is your job. Meta states: "Meta does not assist with deduplicating events for Conversions API for Business Messaging so we highly encourage advertisers to perform deduplication before sending them over Conversions API for Business Messaging." Unlike the web pixel path, there is no event_id handshake doing this for you.
• Automatic event identification is regionally limited. Meta's Automatic Events API, which infers events from message text, states that "Automatic event identification is not available to business customers in the European Union, United Kingdom, or Japan." If your funnel is European, you are sending your own events or you are sending nothing.
• It says nothing about anything outside WhatsApp. A conversation that migrates to email, to a phone call or to a broker back office leaves the identifier behind. Carrying the outcome forward is your system's responsibility, which is what FlowTracker's attribution layer and broker postbacks exist to do.

Used within those limits, ctwa_clid is the cleanest identifier in messaging advertising: a documented, per-click, first-party value that Meta hands you and then accepts back. It is the reason WhatsApp ad tracking is technically easier than Telegram ad tracking, where no platform-issued identifier crosses the boundary at all.

Sources

Every link below was fetched and read on 14 August 2026. Where a vendor does not document something, this article says so rather than filling the gap with an estimate.

Last reviewed 14 August 2026