Genesys Casual

Hi Mario,

We are currently working on the same use case to estimate the impact of Meta's new per-message pricing model.

What we are doing is not relying on the messages or messages turns metrics, since they do not directly represent the number of messages sent by the business.

Instead, we are retrieving the conversation/message detail through the Genesys Cloud APIs and analyzing the individual messages within each WhatsApp interaction. From there, we identify the direction/sender of each message and count only the messages sent from the business side (agent, bot, or flow), excluding messages sent by the customer.

For example:

Total messages: 28
Customer → Business: 10
Business → Customer: 18
Potential billable messages: 18

We are currently testing this approach with individual conversations, and the next step is to extract the information in bulk for a larger period. This would allow us to calculate the average number of business-sent messages per WhatsApp interaction and use it to estimate the potential Meta costs.

We are also validating which message events should actually be considered billable under Meta's new model, rather than assuming that every outbound message recorded in Genesys represents a Meta charge.

If useful, I can also share the API approach/endpoints we are testing to extract and count the messages.

Hi Mario,

We are currently working on the same use case to estimate the impact of Meta's new per-message pricing model.

What we are doing is not relying on the messages or messages turns metrics, since they do not directly represent the number of messages sent by the business.

Instead, we are retrieving the conversation/message detail through the Genesys Cloud APIs and analyzing the individual messages within each WhatsApp interaction. From there, we identify the direction/sender of each message and count only the messages sent from the business side (agent, bot, or flow), excluding messages sent by the customer.

For example:

Total messages: 28
Customer → Business: 10
Business → Customer: 18
Potential billable messages: 18

We are currently testing this approach with individual conversations, and the next step is to extract the information in bulk for a larger period. This would allow us to calculate the average number of business-sent messages per WhatsApp interaction and use it to estimate the potential Meta costs.

We are also validating which message events should actually be considered billable under Meta's new model, rather than assuming that every outbound message recorded in Genesys represents a Meta charge.

If useful, I can also share the API approach/endpoints we are testing to extract and count the messages.

Hi Akhil,

Thanks for the feedback.

We were able to retrieve the information through the Genesys Cloud API. Our approach was to first obtain the WhatsApp conversations for the period and then query the individual message details for each conversation.

This allowed us to identify, at message level, the sender/participant, message direction (inbound/outbound), timestamp, and associated conversation, and we also added the Genesys queue associated with the interaction so we can allocate the traffic to the corresponding business operation.

With this approach, we can now count the actual outbound messages generated by agents/bots/flows, rather than estimating the number of messages based only on the number of conversations.

I completely agree with your point regarding billing. At this stage, we are treating the outbound message count as the upper-bound estimate. The next step is to determine, where possible, which messages fall under Meta's billing exceptions (FEP, free service messages, etc.) so we can move from message volume to a more accurate billable-message estimate.

I can also share the API endpoints and the extraction logic we used if that would be helpful.

Hi Mario,

We are currently working on the same use case to estimate the impact of Meta's new per-message pricing model.

What we are doing is not relying on the messages or messages turns metrics, since they do not directly represent the number of messages sent by the business.

Instead, we are retrieving the conversation/message detail through the Genesys Cloud APIs and analyzing the individual messages within each WhatsApp interaction. From there, we identify the direction/sender of each message and count only the messages sent from the business side (agent, bot, or flow), excluding messages sent by the customer.

For example:

Total messages: 28
Customer → Business: 10
Business → Customer: 18
Potential billable messages: 18

We are currently testing this approach with individual conversations, and the next step is to extract the information in bulk for a larger period. This would allow us to calculate the average number of business-sent messages per WhatsApp interaction and use it to estimate the potential Meta costs.

We are also validating which message events should actually be considered billable under Meta's new model, rather than assuming that every outbound message recorded in Genesys represents a Meta charge.

If useful, I can also share the API approach/endpoints we are testing to extract and count the messages.

Hi Luis,

Hi Akhil,

Thanks for the feedback.

We were able to retrieve the information through the Genesys Cloud API. Our approach was to first obtain the WhatsApp conversations for the period and then query the individual message details for each conversation.

This allowed us to identify, at message level, the sender/participant, message direction (inbound/outbound), timestamp, and associated conversation, and we also added the Genesys queue associated with the interaction so we can allocate the traffic to the corresponding business operation.

With this approach, we can now count the actual outbound messages generated by agents/bots/flows, rather than estimating the number of messages based only on the number of conversations.

I completely agree with your point regarding billing. At this stage, we are treating the outbound message count as the upper-bound estimate. The next step is to determine, where possible, which messages fall under Meta's billing exceptions (FEP, free service messages, etc.) so we can move from message volume to a more accurate billable-message estimate.

I can also share the API endpoints and the extraction logic we used if that would be helpful.

Hi Mario,

We are currently working on the same use case to estimate the impact of Meta's new per-message pricing model.

What we are doing is not relying on the messages or messages turns metrics, since they do not directly represent the number of messages sent by the business.

Instead, we are retrieving the conversation/message detail through the Genesys Cloud APIs and analyzing the individual messages within each WhatsApp interaction. From there, we identify the direction/sender of each message and count only the messages sent from the business side (agent, bot, or flow), excluding messages sent by the customer.

For example:

Total messages: 28
Customer → Business: 10
Business → Customer: 18
Potential billable messages: 18

We are currently testing this approach with individual conversations, and the next step is to extract the information in bulk for a larger period. This would allow us to calculate the average number of business-sent messages per WhatsApp interaction and use it to estimate the potential Meta costs.

We are also validating which message events should actually be considered billable under Meta's new model, rather than assuming that every outbound message recorded in Genesys represents a Meta charge.

If useful, I can also share the API approach/endpoints we are testing to extract and count the messages.

Hi Akhil,

Absolutely. We actually automated the extraction using a PowerShell script connected directly to the Genesys Cloud APIs.

The main endpoint we used to retrieve the WhatsApp conversations for the selected period was:

POST /api/v2/analytics/conversations/details/query

We filtered the Analytics query for mediaType = message and then processed the returned conversations in PowerShell.

For validation and message-level analysis, we also used:

GET /api/v2/conversations/messages/{conversationId}

This allowed us to compare the individual messages against the information available in the Analytics response and validate the message counts.

In the PowerShell extraction, we use the participant information and oMessageCount to classify the traffic by participant purpose:

customer = inbound messages from the customer

workflow = outbound messages generated by the flow/bot

agent = outbound messages sent by an agent

For our outbound volume, we therefore calculate workflow + agent, while keeping customer messages separate.

We later enriched the same extraction with the Genesys queue associated with each conversation. When we have the queueId, we resolve the queue name using:

GET /api/v2/routing/queues/{queueId}

PowerShell then exports the consolidated information to CSV, including the conversation ID, customer messages, workflow messages, agent messages, total outbound messages and associated queue.

This has been particularly useful because the queue allows us to break down the WhatsApp consumption by business operation, instead of only having a global message count.

At this stage, we are using the resulting outbound volume as the basis for our Meta cost analysis, while we continue working on identifying which messages would actually be billable under Meta's new pricing rules and exceptions.

Hi Luis,

Hi Akhil,

Thanks for the feedback.

We were able to retrieve the information through the Genesys Cloud API. Our approach was to first obtain the WhatsApp conversations for the period and then query the individual message details for each conversation.

This allowed us to identify, at message level, the sender/participant, message direction (inbound/outbound), timestamp, and associated conversation, and we also added the Genesys queue associated with the interaction so we can allocate the traffic to the corresponding business operation.

With this approach, we can now count the actual outbound messages generated by agents/bots/flows, rather than estimating the number of messages based only on the number of conversations.

I completely agree with your point regarding billing. At this stage, we are treating the outbound message count as the upper-bound estimate. The next step is to determine, where possible, which messages fall under Meta's billing exceptions (FEP, free service messages, etc.) so we can move from message volume to a more accurate billable-message estimate.

I can also share the API endpoints and the extraction logic we used if that would be helpful.

Hi Mario,

We are currently working on the same use case to estimate the impact of Meta's new per-message pricing model.

What we are doing is not relying on the messages or messages turns metrics, since they do not directly represent the number of messages sent by the business.

Instead, we are retrieving the conversation/message detail through the Genesys Cloud APIs and analyzing the individual messages within each WhatsApp interaction. From there, we identify the direction/sender of each message and count only the messages sent from the business side (agent, bot, or flow), excluding messages sent by the customer.

For example:

Total messages: 28
Customer → Business: 10
Business → Customer: 18
Potential billable messages: 18

We are currently testing this approach with individual conversations, and the next step is to extract the information in bulk for a larger period. This would allow us to calculate the average number of business-sent messages per WhatsApp interaction and use it to estimate the potential Meta costs.

We are also validating which message events should actually be considered billable under Meta's new model, rather than assuming that every outbound message recorded in Genesys represents a Meta charge.

If useful, I can also share the API approach/endpoints we are testing to extract and count the messages.

Hi Akhil,

Absolutely. We actually automated the extraction using a PowerShell script connected directly to the Genesys Cloud APIs.

The main endpoint we used to retrieve the WhatsApp conversations for the selected period was:

POST /api/v2/analytics/conversations/details/query

We filtered the Analytics query for mediaType = message and then processed the returned conversations in PowerShell.

For validation and message-level analysis, we also used:

GET /api/v2/conversations/messages/{conversationId}

This allowed us to compare the individual messages against the information available in the Analytics response and validate the message counts.

In the PowerShell extraction, we use the participant information and oMessageCount to classify the traffic by participant purpose:

customer = inbound messages from the customer

workflow = outbound messages generated by the flow/bot

agent = outbound messages sent by an agent

For our outbound volume, we therefore calculate workflow + agent, while keeping customer messages separate.

We later enriched the same extraction with the Genesys queue associated with each conversation. When we have the queueId, we resolve the queue name using:

GET /api/v2/routing/queues/{queueId}

PowerShell then exports the consolidated information to CSV, including the conversation ID, customer messages, workflow messages, agent messages, total outbound messages and associated queue.

This has been particularly useful because the queue allows us to break down the WhatsApp consumption by business operation, instead of only having a global message count.

At this stage, we are using the resulting outbound volume as the basis for our Meta cost analysis, while we continue working on identifying which messages would actually be billable under Meta's new pricing rules and exceptions.

Hi Luis,

Hi Akhil,

Thanks for the feedback.

We were able to retrieve the information through the Genesys Cloud API. Our approach was to first obtain the WhatsApp conversations for the period and then query the individual message details for each conversation.

This allowed us to identify, at message level, the sender/participant, message direction (inbound/outbound), timestamp, and associated conversation, and we also added the Genesys queue associated with the interaction so we can allocate the traffic to the corresponding business operation.

With this approach, we can now count the actual outbound messages generated by agents/bots/flows, rather than estimating the number of messages based only on the number of conversations.

I completely agree with your point regarding billing. At this stage, we are treating the outbound message count as the upper-bound estimate. The next step is to determine, where possible, which messages fall under Meta's billing exceptions (FEP, free service messages, etc.) so we can move from message volume to a more accurate billable-message estimate.

I can also share the API endpoints and the extraction logic we used if that would be helpful.

Hi Mario,

We are currently working on the same use case to estimate the impact of Meta's new per-message pricing model.

What we are doing is not relying on the messages or messages turns metrics, since they do not directly represent the number of messages sent by the business.

Instead, we are retrieving the conversation/message detail through the Genesys Cloud APIs and analyzing the individual messages within each WhatsApp interaction. From there, we identify the direction/sender of each message and count only the messages sent from the business side (agent, bot, or flow), excluding messages sent by the customer.

For example:

Total messages: 28
Customer → Business: 10
Business → Customer: 18
Potential billable messages: 18

We are currently testing this approach with individual conversations, and the next step is to extract the information in bulk for a larger period. This would allow us to calculate the average number of business-sent messages per WhatsApp interaction and use it to estimate the potential Meta costs.

We are also validating which message events should actually be considered billable under Meta's new model, rather than assuming that every outbound message recorded in Genesys represents a Meta charge.

If useful, I can also share the API approach/endpoints we are testing to extract and count the messages.