Conversation identifier in the WhatsApp API

The conversation identifier (conversation ID) is a unique alphanumeric code that Meta's WhatsApp API assigns to each thread of messages between a business and a customer. It works like the "ID card" of a conversation: it lets the platform know which messages belong to the same exchange, apply 24-hour window rules, and bill correctly. If you're integrating WhatsApp Business API, understanding this concept saves you headaches with history, templates, and costs.

Why does it matter to an SME?

For an SME using WhatsApp to sell or serve customers, the conversation identifier is not a minor technical detail. It defines concrete things: whether a message falls within an open conversation or starts a new one, whether you can reply freely or need to use an approved template, and how much Meta will charge you for that conversation. Understanding it helps you avoid surprises on your bill and configure your management tool properly, like Wando, which uses Meta's official API.

How is it used in practice?

In practice, when a customer writes to you for the first time or after more than 24 hours of silence, the WhatsApp API opens a new conversation and assigns it a conversation ID. That ID travels in the webhooks of each incoming message and in the API responses when you send a message. Management tools (like a CRM or inbox software) use it to group messages, display history, and calculate metrics. If you develop your own integration, you'll receive the 'conversation' field in the webhook payload, with its ID and conversation type (for example, 'customer_initiated' or 'business_initiated').

Concrete and complete example

Imagine you have a clothing store and a customer writes to you on Monday at 10:00: "Do you have the black t-shirt in size M?". The WhatsApp API creates a conversation with an ID like 'wamid.ABC123...'. That ID remains associated with all messages in that thread. You reply at 10:05, and at 14:00 the customer asks about shipping. All of that is the same conversation. If the customer doesn't write anything until Wednesday at 09:00, that new message no longer belongs to the previous conversation: the API opens a new conversation, with a different ID, because more than 24 hours have passed. For your bill, that's two conversations (two billable units), even though it's the same customer.

What it's confused with and how it differs

The conversation identifier is often confused with the message ID and with the client's WhatsApp ID (phone number). The message ID identifies a specific message (each message has its own, which starts with 'wamid.'). The conversation ID groups several messages into a thread. The phone number is the contact identifier, which can have many conversations over time. Another common confusion is thinking that the conversation ID is a sequential number or that you choose it: it is an opaque identifier, generated by Meta, that has no meaning other than grouping.

Common errors when handling it

• Assuming that a conversation lasts forever: the 24-hour window is key; if you don't respond in time, you lose the conversation and your next response opens a new one (and may require a template).
• Using the conversation ID as a primary key for a client: a client can have several conversations; if you use the ID as a unique identifier, you will duplicate contacts.
• Forgetting that the conversation ID changes between messages if time passes: saving the ID in a database without updating it can lead you to respond out of context.
• Not distinguishing between conversations initiated by the client and by the business: this affects cost and template rules.

What happens if you don't take it into account?

If you don't take the conversation identifier into account, your integration can mix messages from different threads, show incomplete histories, send responses outside the 24-hour window (which Meta rejects or forces you to use templates) and, at the end of the month, receive an invoice from Meta with charges you don't understand. Tools that use the official API, like Wando, handle these IDs for you, but if you develop something of your own, it's a basic requirement.

How does it relate to Meta's official API?

Meta's WhatsApp API (WhatsApp Cloud API) uses the conversation identifier for two main things: controlling the 24-hour window and billing. Each incoming or outgoing message within the same conversation shares the same ID. When the conversation is closed (due to time or because it is resolved), the ID is no longer useful for new messages. The webhooks that Meta sends include the 'conversation' object with the ID and type. To know Meta's exact limits and conversation prices (which vary by country), you must consult Meta's official documentation, because they change frequently.

When does it NOT apply?

The conversation identifier does not apply if you use regular WhatsApp (the mobile app) without API, because there is no concept of a billable conversation: it's all one chat. It also does not apply if you use a tool that is not connected to Meta's official API (for example, a bot that uses unofficial WhatsApp Web), because it does not generate conversation IDs. And note: even if you use the API, there are cases where there is no conversation ID, such as when you send a message to a number that has never responded to you: the conversation still exists, but the ID may not be present in the webhook until the customer responds.

How to configure it in Wando step by step

Configuring Wando to handle conversation identifiers for you does not require touching anything technical. When you create your account, you connect your WhatsApp number through Meta's official API. The process is guided: you scan a QR code or enter your number, and Wando handles the verification.

In the panel, go to the 'Settings' section and then to 'Connection'. There you see the status of your number: if it is 'Connected', the API is already active and Wando starts receiving webhooks with conversation IDs. If it shows 'Disconnected' or 'Action required', tap 'Reconnect' and repeat the QR step.

There is no field where you see the conversation ID in the Wando interface. You don't need it: the platform uses it internally to group messages and bill. What you can configure are the auto-replies by schedule and templates, which depend on the 24-hour window defined by the ID.

If you want to verify that everything is set up correctly, send a message to your own number from another phone. In the Wando inbox, it should appear as a new conversation with the full history. If it doesn't appear, check that the number is connected and that the webhook is active.

How to tell that it worked and what to check first if it fails

A well-configured integration shows in two things: messages go in and out without delay, and in your statistics you see conversations separated by customer and by day. If you open a chat in Wando, the history shows all messages from that current conversation, not mixed with those from previous days.

When something doesn't work, the first place to look is the connection status in 'Settings > Connection'. If it says 'Connected', the problem is elsewhere. The second thing is to test with a real message: if it goes in but no response comes out, check the auto-responses and templates.

A common error is that the response goes out as a template when it shouldn't. That happens if more than 24 hours have passed since the customer's last message and the conversation was closed. Wando notifies you in the inbox with an icon, and suggests using an approved template to reopen the conversation.

If after testing everything it still fails, check Meta's developer documentation: webhook and authentication errors appear there. But in 99% of cases, the problem is that the number is not connected or the template is not approved. Wando shows both statuses in the panel.

What changes depending on business size

For a one-person business, the conversation identifier is transparent: you don't see it, you don't touch it, and it only affects you when Meta's invoice arrives. With Wando, one person can manage the inbox without worrying about IDs, because the platform groups everything automatically.

In a fifteen-person business, the conversation ID becomes relevant to avoid agents stepping on each other. Wando uses the ID to know which messages belong to which customer, so two agents don't respond to the same thread at the same time. It also allows assigning conversations to specific people, something a small business doesn't need.

Size also changes how templates are managed. A small business uses one or two generic templates (greeting, confirmation). A large one needs several per campaign, and there the conversation ID is key to measure how many conversations each template opened and how much it cost.

Meta's invoice also scales differently: a one-person business can have 50 conversations per month; one with fifteen people, thousands. Wando shows conversation statistics per day, so you know how many billable units you generated and the cost doesn't surprise you.

What is written in Meta's official documentation and what is not

Meta's official documentation defines the conversation ID as a unique identifier that groups messages within a 24-hour window. It is specified that the ID appears in webhooks and that prices are calculated per conversation, with rates varying by country.

What Meta does not document is how to use that ID in a user interface. That's where each platform comes in: Wando decides whether to show it or not, how to group chats, and how to handle edge cases. It also doesn't specify what to do when a conversation closes and the customer writes again: that's the tool's criteria.

Meta also doesn't set template approval times beyond 'up to 48 hours'. If a template takes longer, that's not something the documentation promises. Each platform handles that in its own way, and Wando notifies you when a template is approved.

When you read Meta's documentation, you'll see terms like 'conversation category' and 'conversation pricing'. That's all you need to understand the invoice. The rest, like reopening logic or handling multiple agents, is the responsibility of the tool you use.

Second-order questions that remain after understanding the concept

Once you understand what the conversation ID is, more nuanced questions arise. For example: what happens if a customer writes to you, you don't respond, and they write again three days later? Meta opens a new conversation, and the previous history stays in another one. Wando shows you both in the same chat, but counts them as two conversations.

Another question is whether you can force close a conversation. The answer is no: the 24-hour window is controlled by Meta, not by you or the tool. What you can do is not respond and wait for it to close, but that is not good for your service.

There is also the question of whether the ID is reused. No: each conversation has a unique ID, and it is not repeated. If a customer writes to you every day, you will have a different ID each day, even if it is the same contact.

Finally, how does the ID affect statistics? Wando uses the ID to count unique conversations per day, not individual messages. This gives you a more realistic metric of how many people wrote to you, and helps you plan how much you will pay on the Meta bill.