DEV Community: botsense seo

Meta Business Agent needs two webhook fields WhatsApp does not list

botsense seo — Sat, 05 Sep 2026 07:39:52 +0000

Meta Business Agent will not deliver you a usable record of its conversations unless your app subscribes to the standby webhook and to messaging_handovers.

Neither field appears in WhatsApp's own webhook field reference, which lists nineteen fields and was last updated on 29 April 2026.

Both are documented, but under Messenger Platform, in Messenger vocabulary: page objects, Page IDs, PSIDs and postbacks. None of those exist on WhatsApp.

Meta's WhatsApp changelog records Standby Webhooks documentation being added on 4 August 2026. The field list was not updated to match.

The failure is silent. The agent still answers your customer. You simply stop receiving the conversation.

Meta Business Agent lets a business run an AI agent that answers WhatsApp conversations autonomously. Meta names thread control among its capabilities, describing it as managing handoffs between the AI agent and human agents.

What the standby webhook does, and why you need it

The standby webhook field receives traffic for conversations the Meta Business Agent is handling. When the agent becomes the primary responder for a conversation, that conversation's messages stop arriving on the messages field your existing integration subscribes to. They arrive on standby instead. Without that subscription, the conversation happens and no record of it reaches your application.

If you have not subscribed to that field, nothing errors. Your endpoint stays healthy, your existing messages subscription keeps working for everything else, and the agent keeps answering your customers correctly. What you lose is the record. The conversation happens and you receive none of it.

That is the shape worth naming: not a crash, not a rejected request, just an absence that looks exactly like a quiet day.

Where the standby webhook is actually documented

Meta's WhatsApp webhook reference has a Fields table listing nineteen fields, from account_alerts through user_preferences. standby is not one of them. Neither is messaging_handovers.

WhatsApp's webhook field reference lists nineteen fields: account_alerts, account_review_update, account_update, business_capability_update, flows, message_template_quality_update, message_template_status_update, messages, phone_number_name_update, phone_number_quality_update, security, template_category_update, user_preferences, and others through to the full nineteen. standby and messaging_handovers are not among them. The list was last updated 29 April 2026.

Both fields do have reference documentation. It sits under Messenger Platform.

Field	Where documented	Last updated
`standby`	Messenger Platform webhook events	25 September 2024
`messaging_handovers`	Messenger Platform webhook events	14 September 2021
WhatsApp webhook Fields table	WhatsApp Business Platform	29 April 2026

The dates are the interesting part. WhatsApp's field list is the most recently maintained of the three, and it is the one that omits them.

The documentation you are sent to is about something else

The standby webhook reference sits under Messenger Platform, not WhatsApp Business Platform. It describes a callback that fires when a message is sent to a page while your application is not the current thread owner. The example payload opens with "object":"page" and carries a PAGE_ID. Postbacks, PSIDs, and page objects appear throughout. None of those exist on WhatsApp, which uses "object":"whatsapp_business_account" and routes on a phone number ID. You are expected to read a Messenger reference and translate it into WhatsApp terms.

The messaging_handovers reference is older still, dating to 2021, and documents pass_thread_control and take_thread_control events carrying previous_owner_app_id and new_owner_app_id.

This is not a claim that standby is undocumented or that Meta Business Agent is broken. The feature works, Meta added Standby Webhooks documentation for WhatsApp on 4 August 2026, and providers who have implemented it handle these fields on your behalf. The gap is narrower: the canonical WhatsApp field list does not name either field, and the reference documentation they are pointed to was written for a different product.

Why the documentation lives where it does

The handover protocol Meta Business Agent uses is not specific to WhatsApp. It is the thread control mechanism Messenger has used since 2021 for two applications sharing a conversation: one holds the thread, the other watches on standby, and pass_thread_control and take_thread_control transfer ownership between them. Meta reused that protocol rather than building a new one. The documentation predates the WhatsApp feature.

The consequence for a reader: if you are implementing against WhatsApp, the authoritative description of two fields you need is written in terms of a product you are not using, and the field list for the product you are using does not mention them.

What messaging_handovers carries, and why you need it separately

messaging_handovers is the webhook field that fires when thread control changes — when the Meta Business Agent takes over a conversation or when your application takes it back. It carries the application that previously owned the thread and the one that owns it now. Without it, you can reconstruct a transcript but not the custody chain — which application was responsible at which moment.

Treat the two as a pair. One is the content, the other is the timeline.

What to check before you enable the agent

Confirm your app is subscribed to standby and messaging_handovers, not only messages. The App Dashboard configuration panel is where subscriptions are managed, and the absence of a field from the published list does not mean it cannot be selected.

Test the failure rather than assuming it. Enable the agent, have a colleague message the number, and confirm the exchange actually arrives at your endpoint.

The pattern, not just this instance

We have documented several gaps of this kind in Meta's platform documentation, and they share a shape. A mechanism is specified completely somewhere, and the one page a reader would consult does not point at it.

When a feature depends on something you cannot find in the obvious place, assume the obvious place is incomplete rather than assuming the thing does not exist.

Sources

Webhooks, WhatsApp Business Platform — Fields table, 19 fields, updated 29 April 2026
standby Webhook Event Reference, Messenger Platform — updated 25 September 2024
messaging_handovers Webhook Event Reference, Messenger Platform — updated 14 September 2021
About the WhatsApp Business Platform — Meta Business Agent capabilities

Originally published at botsense.io

Meta's Embedded Signup notice names v2. The table retires v3 too.

botsense seo — Fri, 04 Sep 2026 08:13:21 +0000

Meta's deprecation banner on every embedded signup page names one version: v2, ending 15 October 2026.
The versions table on the same site retires four: v2, v3, v2-public-preview and v3-public-preview, all in October 2026.
A partner who reads the banner and confirms they are on v3 will conclude they are safe. They are not.
Moving to v4 is not a version string change. The extras object becomes empty and product configuration moves into a new Facebook Login for Business configuration.
Only v4 supports Click to WhatsApp Ads, Marketing Messages API and Conversions API through login config. On v3 and v2 those read "Not supported".

If you onboard WhatsApp customers through a partner platform, someone in that chain runs Embedded Signup. It is the flow where a business logs in with Facebook, picks or creates a WhatsApp Business Account, and grants your app access to it.

Meta has put a deprecation notice at the top of every page in that section. It reads the same everywhere: v2 will be deprecated on 15 October 2026, migrate to v4.

The notice is accurate. It is also narrower than what the versions table says, and the gap between the two is the kind that gets discovered in October.

What the embedded signup versions table actually says

The versions page lists each release with the date it arrived and the date it stops being available. Four rows carry the same end date.

VERSION	INTRODUCED	AVAILABLE UNTIL
v4-public-preview	12 May 2026	TBD
v4	8 October 2025	TBD
v3-public-preview	14 August 2025	October 2026
v2-public-preview	14 August 2025	October 2026
v3	29 May 2025	October 2026
v2	January 2023	October 2026

v3 was introduced in May 2025 and ends in October 2026, seventeen months later. It is not named in the banner.

That matters because of how a partner would check. You read the warning, you look up which version your integration sets, you see v3, and you close the tab. The banner told you the affected version and yours was not it.

Migrating embedded signup is not a version string change

This is the part that decides how much time you need.

On v2 and v3, the version lives in your code. The implementation passes an extras object that names the version alongside feature flags:

// v3 example
extras: {
  version: "v3",
  sessionInfoVersion: 2,
  featureType: "marketing_messages_lite"
}

On v4, Meta's own documentation says the extras object is purposely empty. There is no version to set. Instead you create a new Facebook Login for Business configuration and select the products you want, and selecting them sets you to v4 automatically.

So configuration moves from your front-end code into a dashboard object. That is a different task from editing a string. It needs a new login configuration created, tested against a real onboarding, and rolled out, and if anything downstream reads the session payload the shape of what comes back changes with it.

The one piece of good news is in the same document: versions are not exclusive, and Meta says partners can roll out a new version gradually to reduce risk. You do not have to switch everyone at once.

How to tell which version you are actually running

The version is not stored anywhere you can query. It is whatever your onboarding page passes at the moment the flow launches, so the only reliable answer comes from reading the code that launches it.

Find the page that opens the signup window and look for the extras object handed to the Facebook login call. What you see there tells you where you stand.

If it contains version: "v2" or version: "v3", you are on a version that ends in October 2026.

If it contains a sessionInfoVersion key, that is a v2 signature specifically. Only v2 requires it, and its presence usually means the integration has not been touched since before May 2025.

If it contains featureType or a features array naming app_only_install or marketing_messages_lite, those are v2 and v3 configuration shapes. On v4 the same capabilities are selected in the login configuration instead.

If the extras object is empty, you are already on v4 and this deadline does not apply to you.

One nuance worth knowing if you inherited the integration: app_only_install lets a partner reach WABAs through a granular business integration system user token rather than creating a system user access token. If your platform relies on that behaviour, confirm it is selected in the new login configuration rather than assuming it carries across, because it moves from a code flag to a dashboard product.

Meta also notes that the versioning cadence follows Graph API. If you already have a process for tracking Graph API version changes, this belongs in it rather than in a separate reminder somebody has to remember.

What you gain, and what you cannot have on v3

The feature table draws a line that has nothing to do with deprecation dates.

CAPABILITY	V4	V3	V2
Products via login config	Marketing Messages API, Click to WhatsApp Ads, Conversions API	Not supported	Not supported
Session info logging	Sent back for all flows	Sent back for all flows	Requires an explicit sessionInfoVersion
Completion state	Verified, unverified, or no phone number	Verified, unverified, or no phone number	Must finish with a verified number

Read the first row again if you run Click to WhatsApp ads. Onboarding customers with CTWA and the Conversions API attached through login config is a v4 capability. On v3 it is not available at all.

That reframes the migration. It is not only a deadline to survive, it is the version where three onboarding products become reachable.

The session info row is the one most likely to bite quietly. On v2 the callback that returns the customer's WABA ID and phone number ID only arrives if you explicitly set sessionInfoVersion. On v3 and v4 it is sent for every flow. If your integration was built against v2 and someone assumed the callback was automatic, it was not.

Dates in this post were read from Meta's documentation on 3 September 2026. Meta moves deprecation dates, and the versions page carries an "Updated" stamp from December 2025 while describing a release from May 2026, so its own metadata is behind its content. Check the live page before you plan around any date here.

There is a UI change landing separately

Buried under the version list is a note that the refreshed interface currently in public preview will roll out to all versions of Embedded Signup in early September.

That is now, and it is independent of which version you run. If your onboarding documentation contains screenshots, or your support team walks customers through the flow screen by screen, that material is about to be wrong regardless of whether you have migrated.

What to do in the next six weeks

Find out which version you are actually on. Not which version you think you specified. Grep your onboarding page for the extras object and read the value.

If it says v2 or v3, or if the object exists at all, you have work to do. An empty extras object is the v4 signature.

Create the new Facebook Login for Business configuration and select the products you want, including Click to WhatsApp Ads if you use it. This is where the migration effort actually sits.

Test a real onboarding end to end, and confirm the session callback still delivers the WABA ID and phone number ID your system stores. Do not assume the payload is unchanged.

Roll out gradually rather than switching everyone at once, which Meta explicitly supports.

Then update your onboarding screenshots, because the interface is changing this month whatever you decide about versions.

The pattern worth carrying forward

A deprecation banner is a summary, and summaries drop things. The banner named the oldest version, which is reasonable, because v2 dates from January 2023 and is presumably where most legacy integrations sit.

But the authoritative statement of what ends and when is the table, not the banner. Anyone who checked the prominent warning and stopped there has now confirmed the wrong thing.

We have written before about a Meta capability restricted to Select and Premier Solution Partner tiers that Meta's partner comparison never defines. This is the same category of problem read from the other end. There, the detail existed and the summary omitted it. Here, the summary is correct about one version and silent about three more.

Originally published at botsense.io

The 72-Hour Free Window on Click-to-WhatsApp Ads Has a Condition Nobody Mentions

botsense seo — Wed, 19 Aug 2026 07:22:22 +0000

The two windows, and why people confuse them

There are two separate timers in WhatsApp Business, and treating them as one is the root of most CTWA budgeting mistakes.

	Customer service window	Free entry point window
What opens it	Any customer message, by any route	A CTWA ad or Facebook Page CTA click, Android/iOS only
How long	24 hours from the customer's message	72 hours from your reply
What you can send	Any free-form message	Any message, including marketing templates
What it costs	Free-form replies are free	Everything is free while open
Opens automatically	Yes	No: only if you reply within 24 hours

According to Meta's documentation: "If you respond within 24 hours using any type of message, the message will be free, and a Free Entry Point window will be opened, starting from the time when you responded."

A free entry point conversation requires two conditions: (1) the customer messages from a CTWA ad or Facebook Page CTA button on Android or iOS — desktop and web are not supported; (2) you respond within 24 hours. The 72 hours starts from the moment you reply, not from when the customer messaged.

What this means for how you run the campaign

Match your ad delivery hours to when someone can actually reply
Set an automated first response to secure the window
Treat your reply capacity as a hard limit on ad spend
Plan the follow-up sequence across three days, not one

Why the ad gets rejected before it ever runs

WhatsApp-side rejections are the surprising ones. The ad account is fine, the creative is fine, and the campaign still cannot launch because something is wrong with the WhatsApp Business Account behind it.

The display name problem

Rejection ground	What Meta rejects
Identity mismatch	Name does not correspond to verified business identity
Promotional words	Official, Best, No.1, Cheap, Free
Meta product names	WhatsApp, Facebook, Messenger
Generic names	Customer Service, Support Team, Info Desk
Formatting	Emojis, excessive punctuation, slogans

Identity mismatch is the single most common cause. The fix is completing business verification first, linking the website, and making sure the Facebook Page name and the requested display name tell the same story.

What Click-to-WhatsApp Ads cannot do

It cannot push, only pull. CTWA starts conversations when someone chooses to click. You cannot use it to reach people who have not engaged.

A click is not a conversation. The ad opens WhatsApp with a pre-filled message the user can edit or delete. Plenty of people open it and never press send. You pay for the click either way, and no window opens.

Desktop and web do not count. The free entry point requires Android or iOS.

Attribution is harder than a landing page. Without a platform connecting ad click to conversation to outcome, you lose the thread between spend and revenue.

The short version

Click-to-WhatsApp Ads work well when three things are true: you have a genuine reason for someone to start a conversation, you can reply inside 24 hours, and you treat the following 72 hours as the actual campaign.

Most of the value people describe as "the 72-hour free window" is really the reward for answering quickly.

COD Verification and RTO: Why the Numbers in This Market Do Not Add Up

botsense seo — Wed, 19 Aug 2026 07:20:30 +0000

What COD verification claims to do

The mechanism is straightforward. A cash-on-delivery order carries no payment commitment, so nothing at checkout confirms buyer intent, address accuracy, or phone number validity. An automated call placed shortly after checkout tests all three before the parcel enters fulfillment.

That much is sound. The disagreement starts at the number attached to it.

Vendor claim	RTO reduction	Cost per RTO	Source given
Vendor A	30–45%	—	None
Vendor B	—	₹400–600	None
Vendor C	—	₹180–240	None
Vendor D	30–40%	₹200–500	None at the time of writing

Cost per RTO varies by more than three times between vendors describing the same operation in the same market. The reduction percentages sit in a band wide enough to be unfalsifiable.

The base rate is contested, not settled

To claim a reduction you need a starting point, and the starting point is not agreed.

According to GoKwik: "COD orders in Indian e-commerce see RTO rates of nearly 26%, compared to less than 2% for prepaid orders."

Unicommerce reports differently. Based on 410 million tracked shipments across more than 6,000 D2C brands, during the festive quarter "COD orders returned at 58%", against prepaid "under 15%."

Both are first-party platform data. Neither is citing a blog. And they disagree by more than double at the peak.

If your baseline could be 21% or 58% depending on the month, a vendor promising to cut it by "30 to 40%" has told you nothing you can hold them to.

The most repeated fact has no source

Almost every article on this subject opens with a version of the same line: roughly 60% of Indian e-commerce orders are cash on delivery.

That figure traces back to ET Prime Research in 2024 through secondary write-ups, yet the original remains unreachable. Bain & Company's How India Shops Online contains no absolute COD share figure. Unicommerce publishes return rates but explicitly not the COD share of orders.

That does not make the figure wrong. It makes it uncheckable — which is a different problem and in some ways a worse one.

What is actually sourced is the timing, not the reduction

One figure in this space comes with a named source: GoKwik states "Send confirmation within 5 minutes of order placement (response rates drop 40% after 30 minutes)."

This is still the most actionable thing published on the subject, because it describes a window rather than an outcome. The typical manual process misses it entirely — the calling team works through the queue the following morning, by which time the window has been closed for approximately fourteen hours.

What COD verification should be measured on

Since reduction figures are not checkable, measure the things that are:

Time from order placement to first call attempt (minutes, not hours)
Connect rate: what proportion of calls are answered
Confirmation rate: of those answered, how many confirm the order
RTO rate on confirmed orders versus unconfirmed orders in the same period and category
Your own fully loaded cost per RTO: forward shipping, reverse shipping, packaging, handling

The fourth metric settles it. Comparing confirmed against unconfirmed orders in your own data, in the same weeks and same categories, tells you what verification is worth to you. No industry average can do that.

Run it for one month before signing anything longer than a month.

Including our own numbers

Botsense sells AI calling, including COD verification. Our own pages carried RTO reduction percentages with no source attached, in the same shape as the table above.

We are correcting them. A post arguing that unsourced percentages are worthless would be worth nothing if it quietly exempted the company publishing it.

What we can tell you honestly: we do not know what COD verification will do to your RTO rate, because it depends on your categories, your pin codes, your season, and your current process. If a vendor gives you a percentage instead, ask where it came from. The answer is the useful part.

The WhatsApp Green Tick Is Now Blue: What Meta's API Actually Asks For

botsense seo — Wed, 19 Aug 2026 07:18:56 +0000

Is the WhatsApp green tick actually green?

The terminology everyone searches for is "green tick," but Meta's current documentation uses different language. An Official Business Account (OBA) is described as having "a blue checkmark beside their name in the contacts view."

The color changed between July 2024 and February 2025, when archived snapshots show the transition from "green checkmark badge" to "blue checkmark badge." However, Meta's approval notification system hasn't caught up — it still tells newly approved businesses they received a green badge, creating confusion when users see a blue checkmark instead.

The practical answer: The badge is currently blue, though Meta and the broader community frequently still refer to it as green.

What the Official Business Account page tells you

Meta's official OBA eligibility page lists five criteria, all procedural in nature:

Criterion	What it means
Policy compliance	Complies with WhatsApp Business Messaging Policy
Thirty days	Registered on WhatsApp Business Platform for at least 30 days
Business verification	Business portfolio verified through Business Verification
Two-step verification	Enabled on the phone number
Display name	Approved

Notably absent from this documentation is any mention of notability, fame, or press coverage. A business reviewing this page would reasonably assume that meeting these five procedural conditions is sufficient.

What Meta's API actually asks for

The requirement exists but lives in documentation most businesses never consult. Meta's OBA Status API reference includes a field called supporting_links — described as "Supporting links that demonstrate business notability (minimum 5, maximum 10)."

Meta's Business Help Center further clarifies notability as "a well-known business that has a substantial presence in news articles from publications with sizable audiences."

This represents a significant gap: the requirement for five to ten editorial links demonstrating business notability appears in the API schema and help documentation but not on the main eligibility criteria page. Most guides to obtaining the badge quote Facebook's verification standards instead, which ask for coverage in "multiple news sources" without specifying a minimum number.

Why the WhatsApp green tick usually goes through a provider

Meta documents a self-serve application path through WhatsApp Manager, but for most accounts, the Submit Request button doesn't appear. When this occurs, Meta directs businesses to "reach out to your Meta point-of-contact, Solution Provider support, or Meta Support."

This explains why most applications go through providers — not because Meta forbids self-serve submission, but because the option isn't exposed to most accounts.

What to have ready before applying

At least five links to editorial coverage in publications with genuine audiences (not paid placements)
Business portfolio verified through Business Verification
Two-step verification enabled on the number
Display name approved and directly associated with the business
Thirty days elapsed since registration on the platform

If rejected, businesses must wait 30 days before resubmitting. Meta states that denials currently cannot be appealed, though display name rejections follow a separate process with their own appeal route.

The key principle

The badge follows genuine editorial coverage. If a business lacks five pieces of authentic news coverage, waiting is preferable to submitting an application that will fail and trigger another 30-day waiting period before resubmission.

WhatsApp Multiple Providers: Meta Is Removing the Switching Barrier It Built

botsense seo — Wed, 19 Aug 2026 07:17:16 +0000

What Meta is actually changing

The WhatsApp Business account structure is evolving into two separate components: one managing phone numbers and business profiles, the other handling templates and billing. This enables businesses to operate multiple providers on a single phone number with isolated billing.

Component	WhatsApp Business Account	Messaging Account
Holds	Phone numbers, usernames, profile, catalogs	Templates, billing, webhook subscriptions
Owned by	Always the business	Business or provider (one per provider)
Identifier	New, unavailable until Phase 2	Keeps existing WABA ID

Critically, the account holding your phone number remains yours. Partner accounts handling templates and billing may belong to service providers.

Why WhatsApp multiple providers becomes possible

Currently, a number belongs to one WhatsApp Business Account containing all components. Switching providers requires migrating the number, creating substantial friction that discourages changes.

Meta's documentation directly addresses this shift: "The phone number migration process that previously acted as a natural switching barrier no longer applies." This friction was structural, not technical — a competitive moat that Meta has now dismantled.

What WhatsApp multiple providers share

Adding a second provider does not increase capacity:

Throughput remains at the phone number level
Messaging limits remain at the business portfolio level (unique users per 24-hour period)

When multiple providers operate a single number, they share throughput and daily user limits. Billing separates by which application sends the message, but messaging capacity does not multiply.

What does not change

Deregistration processes, pricing models, and customer-facing experience remain unchanged. WhatsApp users see one trusted contact regardless of provider count.

The timeline

Phase	Timeline	Details
Phase 1	H2 2026	Automatic migration, backward compatible, parallel providers enabled
Phase 2	H1 2027	New account identifiers become available
Phase 3	H1 2028	Mandatory transition to new identifiers

No action is required from businesses during migration. The change shifts market dynamics: the structural cost of switching providers drops to near zero, and provider relationships become genuinely competitive.

AI Collections Calls in India: RBI's Rules Are Not the Ones You Have Been Quoted

botsense seo — Wed, 19 Aug 2026 07:16:03 +0000

There are two calling windows, not one

The widely circulated recovery calling window of 8:00 a.m. to 7:00 p.m. applies to general lending. However, microfinance loans operate under a distinctly different timeframe. According to RBI's Responsible Business Conduct Directions, microfinance borrowers can only be contacted between 9:00 a.m. and 6:00 p.m.

Calling a microfinance borrower at 6:30 p.m. isn't merely outside operating hours — it's officially classified as a harsh practice.

Where the rules differ by lender type

Requirements presented as universal across the industry actually vary considerably:

Requirement	Banks	NBFCs
IIBF certification for recovery agents	Mandatory	Not in the Directions
Call recording	Required	No equivalent requirement
Calling window	8:00–19:00 (microfinance excluded)	8:00–19:00 (microfinance excluded)
Microfinance window	9:00–18:00	9:00–18:00

Banks must ensure recovery agents complete the Indian Institute of Banking and Finance certificate course, while NBFC Directions specify only due diligence and police verification. Banks require call recordings with borrower notification; NBFCs face no such mandate.

What RBI says about AI collections calls

RBI's Responsible Business Conduct Directions contain no reference to artificial intelligence, automated calling, voice bots, or synthetic voices. The regulatory framework addresses human agents exclusively and hasn't been updated for automation technology.

The absence of specific guidance means automated calls inherit all requirements written for people: calling windows, prohibitions against persistent contact, and other behavioral standards.

One potential distinction exists around the prohibition against "making threatening and/or anonymous calls." Whether a synthetic voice call qualifies as anonymous remains judicially unresolved.

AI collections calls do not move liability

Outsourcing recovery functions doesn't transfer regulatory responsibility. Banks and NBFCs remain liable for their service providers' actions regardless of whether contact is human or automated.

Under the Reserve Bank–Integrated Ombudsman Scheme 2026, RBI can award compensation up to ₹30 lakh for consequential losses, plus up to ₹3 lakh for "loss of the complainant's time, expenses incurred, harassment/mental anguish suffered."

What to establish before you buy

Which regulatory instrument governs your portfolio
Whether any portion qualifies as microfinance requiring the 9:00–18:00 window
Whether platforms can enforce different windows for different segments
How your organization defines "persistent calling"
Recording and borrower notification requirements
Internal authorization for meeting anonymity prohibitions

The segment-level calling window represents the most critical verification point. A platform unable to enforce 9:00–18:00 for microfinance while running 8:00–19:00 elsewhere cannot serve mixed portfolios.

Where we stand

RBI has not published guidance confirming automated recovery calling compliance. Vendors cannot represent automation as compliant on RBI's authority. Compliance obligations depend on individual licenses and portfolio composition.

WhatsApp Max Price: What Meta Documented, and the Three Things It Did Not

botsense seo — Wed, 19 Aug 2026 07:14:48 +0000

The WhatsApp max price timeline, as Meta dates it

Meta's pricing page states the position plainly: "The max price feature is available in Limited Beta as of May 15 and will be optional throughout 2026. Meta plans to make max price generally available in Q2 2027."

Phase	Date	Who can use it
Limited Beta	15 May 2026	Any partner and any directly integrated business
Open Beta	October 2026	Any partner can enable for all clients
General Availability	Q2 2027	Required in "eligible geographies"

Nothing about billing changes in the meantime. Meta is explicit that "there is no change to how Meta charges on the WhatsApp Business Platform." If you never set optimization_spec on a template, nothing happens to you at all.

What GA actually means if you are not on Cloud API

This is the line worth reading twice:

"General Availability (GA) as of Q2 2027 — The max price feature will become required in eligible geographies and fixed, published rates for marketing messages will only apply on the Cloud API."

Two commitments in one sentence. The WhatsApp max price stops being optional somewhere, and the familiar per-category rate card survives somewhere else — on Cloud API.

The word doing the most work is "eligible". Meta does not define it. The phrase "eligible geographies" occurs exactly once across all five documents — in the GA sentence above. No list, no link, no table. India is not named in any published restriction group, but "India is eligible to use the Marketing Messages API" and "India is in scope for the GA requirement" are two different statements about two different lists — and only one of those lists has been published.

What Meta never says about undelivered messages

Meta does not say what happens to messages that fall below the max price threshold.

I searched nineteen terms across eight public documents: auction, clearing price, market rate, demand, competing, bid against, not sent, undelivered, dropped, skipped. Zero occurrences, all nineteen, in all eight.

That absence carries weight, because Meta plainly knows how to describe undelivered messages. Error 131049 reads "This message was not delivered to maintain healthy ecosystem engagement." Error 130472 reads "Message was not sent as part of an experiment." Both describe a marketing message Meta decided not to deliver — both get a number, a published description, and a row in the error code reference.

Meta issues a numbered, published error code when it declines to deliver a marketing message. It has not issued one for max price.

What the market claims instead

The top-ranking guide on this feature presents three specific savings percentages and attributes them to "Meta's examples" with no link to any Meta page. Those figures do not appear in any of the five documents above.

More consequential is the auction framing that runs through wider commentary — the idea that your bid competes against other advertisers. It is a reasonable inference. It is not something Meta has written down about this product.

The distinction matters when a client asks what happens to their undelivered messages. "Meta has not documented that" is a defensible answer. "They lost the auction" is a claim you cannot source.

The Solution Partner controls nobody is reading

Meta shipped a partner-facing control for the beta that has gone almost entirely uncovered. The allowlist cap moved twice — from 5 to 15 on 17 June, then to 100 on 31 July.

On 5 August, Meta added a visibility switch: whatsapp_manager_marketing_messages_max_price_enroll_status takes OPT_IN or OPT_OUT. But:

"This setting controls only the visibility of the max price experience in WhatsApp Manager. It doesn't change a WABA's eligibility for max price, and it doesn't affect max price settings configured through the API."

It hides a UI. It does not gate the capability.

Practical steps

Decide whether your marketing volume runs through Marketing Messages API or Cloud API, because Q2 2027 treats them differently.
If you are a Solution Partner, check your allowlist headroom against the 100 cap before Open Beta in October.
Read whatsapp_manager_marketing_messages_max_price_enroll_status as a UI switch, not an access control.
Do not commit to a max price strategy on savings percentages that carry no link to Meta.

The honest summary: Meta has committed to a date and a consequence, and has not published the list of places the consequence applies to. If you sell or buy WhatsApp marketing in India, you are entitled to know whether Q2 2027 changes your rate card. As of today, Meta's public documentation does not tell you.

Meta Business Agent: Meta Documented the Costs for One Path and Not the Other

botsense seo — Wed, 19 Aug 2026 07:12:39 +0000

What Meta Business Agent costs you on the WhatsApp Business app

Meta has published specific consequences for WhatsApp Business app users who enable the Meta Business Agent. According to their Help Center, customer conversations are collected to improve Meta's AI systems, and this collection continues even when businesses mute the agent:

"Messages sent or received in chats that have connected Meta Business Agent will still be collected by Meta to improve AI at Meta, even when you mute Meta Business Agent."

Deletion is the only documented control that stops data collection. Muting merely pauses agent responses without halting the data-gathering process.

Meta also documents operational feature losses for app-path users:

Broadcast lists, disappearing messages, greeting and away messages become unavailable
The inability to pause or delete the agent using WhatsApp Web

What the Cloud API documentation says instead

For businesses using Meta's Cloud API—the path most Indian companies take through Solution Partners—the documentation differs significantly. Cloud API developer documentation meticulously describes mechanics: standby webhooks, handoff procedures, thread control endpoints, and control-release mechanisms.

However, across nine developer documents reviewed, there are zero mentions of data collection practices, feature restrictions, or messaging capability changes equivalent to those published for app users.

The nine documents, and what is not in them

A systematic search across Meta's developer documentation for the agent yielded striking gaps:

Term Category	Search Terms	Results Found
Feature loss	disable, unavailable, cannot use, lose access (22 terms)	0
Data use	improve AI, train, retention, privacy, consent (17 terms)	0
Messaging capability	messaging limit, throughput, rate limit (11 terms)	0

What this does not prove

This documentation gap does not necessarily indicate Meta is concealing unfavorable terms. Cloud API deployments have fundamentally different architectures than phone-based WhatsApp Business apps. Broadcast lists and linked devices are app-specific concepts that don't exist in Cloud API environments, so feature losses wouldn't apply.

The core problem is simpler: Solution Partners cannot answer clients' basic questions about costs because Meta hasn't published the answers in either direction.

Where Meta Business Agent is available

The WhatsApp Help Center clearly states: "This feature is currently only available in limited countries to select businesses. It might not be available to you yet."

The developer documentation merely requires businesses be "based in a country authorized for Meta Business Agent" without naming any specific countries. No published country list exists, and India is neither explicitly included nor excluded in any official documentation.

One defect you can check yourself

The thread control endpoint appears at three different URLs across Meta's documentation:

Get Started guide: https://graph.facebook.com/v21.0/<PHONE_NUMBER_ID>/thread_control
Thread Control reference: https://api.facebook.com/business/whatsapp/phone_numbers/{phone_number_id}/thread_control
Changelog: POST /business/whatsapp/phone_numbers/{phone_number_id}/thread_control

The reference and changelog align; the walkthrough diverges. Developers following the Get Started guide would call a different endpoint than the official reference specifies.

Actionable recommendations

Verify deployment path first: Cloud API and WhatsApp Business app paths are documented entirely separately with different consequences
Read the mute clause carefully: For Business app users, muting doesn't stop Meta's data collection
Check eligibility individually: Use the eligibility endpoint rather than assuming global availability based on third-party claims
Test both endpoints: If implementing thread control, verify both documented URLs in your testing environment

The asymmetry remains: one deployment path has published costs; the other has published mechanics only.

WhatsApp bid multiplier: Meta documents the lever, never the reason

botsense seo — Wed, 19 Aug 2026 07:11:10 +0000

How the WhatsApp bid multiplier actually works

The field is bid_country_multiplier_overrides, a map that lives inside optimization_spec alongside bid_amount and bid_strategy, documented on Meta's Set a max price for marketing messages page.

When a message is sent, Meta determines the recipient's country from their phone number and applies the matching multiplier to the template's bid_amount to produce the effective bid for that message:

Effective bid = bid_amount x country_multiplier

Three constraints are stated: "Up to 50 entries." — "Each multiplier must be greater than 0 and at most 10." — "Keys must be valid ISO 3166-1 alpha-2 country codes."

Two details matter more than they look. The country is derived from the recipient's phone number, not from anything the business declares. And an unlisted country is not an error: "If the recipient's country is not listed in the map, the multiplier is 1.0, so the template's bid_amount is used unchanged."

One asymmetry for developers. You send the map as an object and get it back as an array. A create call takes {"IN": 1.2, "MX": 0.8}; querying optimization_spec returns [{"key": "IN", "value": 1.2}, ...]. Anything round-tripping template configuration must handle both shapes.

Meta's own worked example is three rows

The documentation gives one example, built on a template with bid_amount of 1000 and the map {"IN": 1.2, "MX": 0.8}:

Recipient country	Multiplier applied	Effective bid (per 1,000 delivered)
India (IN)	1.2	1000 × 1.2 = 1,200
Mexico (MX)	0.8	1000 × 0.8 = 800
Brazil (BR) — not listed	1.0 (default)	1000 × 1.0 = 1,000

That is the whole of it. No second example, no regional grouping, and no table of countries anywhere on the page.

The four-arm test, and where India appears

The only place where Meta names specific countries with specific numbers is a testing recommendation: run a four-arm test (10,000 send requests per arm) including Arm C at "1.5x rate card, but 1.2x for India and Saudi Arabia." Four arms at 10,000 send requests each is 40,000 marketing message deliveries to complete one test.

Meta gives no reason for the carve-out. A comprehensive search across eight documents found this parenthesis is the only sentence on the pricing page that names countries for different max-price treatment.

The silence, scoped exactly

Meta is not silent about countries in general. The Marketing Messages API changelog records upcoming rates for Argentina, Australia, Chile, Colombia, India, Indonesia, Malaysia, Mexico, Peru, Saudi Arabia, Singapore, UAE, UK, and US — fourteen named countries. So Meta tracks country-level economics closely enough to publish a per-country rate card. It simply never joins that to the multiplier.

A search across eight documents for words explaining why a country's number should differ found zero occurrences of: competition, demand, market rate, supply, auction, expensive/cheaper, and why. Meta documents the lever and not the reason.

What the market says instead

Into that gap, vendors have supplied a story. The most widely circulated guide headlines "How Meta's New Bidding Model Can Cut Your Marketing Message Costs by 25%" — attributing the 25% to Meta. A comprehensive search found "25%" appears zero times across all eight of Meta's HTML documents. The word auction appears zero times.

This repeats a pattern: a mechanically complete specification, a missing rationale, and third parties filling the gap with numbers attributed to examples that are not in the docs.

What an Indian advertiser can actually conclude

The WhatsApp bid multiplier is a number you set. It is not a rate Meta charges India. Nothing in the documentation says Indian deliveries cost more or less than anywhere else.

What is genuinely established: 1.2 appears for India in Meta's testing recommendation as the upper test arm, and "IN": 1.2 appears in the code samples as the illustrative map. Meta does not call 1.2 recommended, does not call it a starting point, and does not repeat it outside those two contexts.

Practically:

Decide whether you are running marketing volume through the Marketing Messages API at all — the multiplier exists only there.
If you set a multiplier, write down why you chose the number. Meta's documentation will not supply the reasoning later.
Treat 1.2 for India as an example that appeared in a test design, not as a rate.
Budget the test honestly: Meta's own design needs 40,000 deliveries.

The feature is real, complete, and usable. Meta shipped a per-country pricing control into a market where it already publishes per-country rates, and left the question of what any country's number should be entirely to the advertiser.

The WhatsApp user_id_update webhook Meta told you to subscribe to doesn't exist

botsense seo — Mon, 17 Aug 2026 07:37:32 +0000

Meta's July 2026 WhatsApp documentation told developers to subscribe to a user_id_update webhook field to detect BSUID changes. On 11 August 2026, Meta corrected the page. The field doesn't exist, was never subscribable, and never appeared in the App Dashboard.

If you found this after spending hours trying to locate user_id_update in the App Dashboard — you were following the docs correctly. The docs were wrong.

What is a BSUID?

A BSUID (business-scoped user ID) is a privacy layer in the WhatsApp Business Platform. Instead of exposing a user's phone number directly, WhatsApp assigns a unique identifier per business-user pair.

Format: CC.<up_to_128_chars> — for example 91.abc123xyz

Key property: BSUIDs can change without the user changing their phone number. This is why BSUID change events exist in the first place.

How BSUID changes are actually delivered

BSUID change events are delivered on your existing messages webhook subscription as a system message — not on any new field. The webhook payload looks like this:

{
  "object": "whatsapp_business_account",
  "entry": [{
    "changes": [{
      "value": {
        "messages": [{
          "type": "system",
          "system": {
            "type": "user_changed_user_id",
            "identity": "new_bsuid_value",
            "wa_id": "phone_number"
          }
        }]
      },
      "field": "messages"
    }]
  }]
}

The silent enum change you also need to know about

There's a breaking enum value change that happened silently:

Before (July 2026 docs): user_changed_user_id meant the user's phone number changed
After (August 2026 correction): user_changed_user_id means the user's BSUID changed (phone number unchanged)
Current enum for phone changes: user_changed_number

If your integration was checking system.type === "user_changed_user_id" to detect phone number changes, you were using the wrong trigger even when the docs said otherwise. That logic now means BSUID change.

What you need to do

Audit your webhook handler — find any code checking system.type values
Map existing logic: rename user_changed_user_id handlers to BSUID change handlers
Phone number changes: use user_changed_number going forward
No new webhook subscription needed — BSUID change events come through your existing messages subscription as system messages
Delete any user_id_update subscription logic — the field does not exist, was never valid

The full breakdown

The complete technical write-up — including the exact payload format, enum reference table, migration checklist, and what Meta's correction actually says — is on the BotSense blog:

WhatsApp BSUID webhook: the user_id_update field that doesn't exist

If you hit this while building a WhatsApp integration, drop a comment — curious how many teams were blocked by this.

What Actually Happens to Your WhatsApp Number When You Change API Providers

botsense seo — Thu, 13 Aug 2026 13:20:38 +0000

Most of the guides on switching WhatsApp Business API providers focus on what you need to do before you sign with a new provider. This one focuses on what happens after — to your phone number, your templates, and your throughput — because that part is almost never explained clearly.

Update — August 2026: Meta is restructuring its WhatsApp Business Account model. Some of the steps below (particularly around account migration) may change once the new account architecture is fully rolled out. Check your provider's documentation for the latest migration flow.

There are three different exits

When you leave a WhatsApp API provider, there isn't one universal process. There are three distinct paths, and which one applies to you depends on what you agreed to when you onboarded:

Exit type	What it means	Who controls it
Migrate	Your phone number moves to a new BSP while staying connected to the same WABA	You (with both BSPs cooperating)
Deregister	Your number is detached from the API entirely; you keep the number	Your current BSP initiates
Delete	Your WABA and number are removed from the WhatsApp Business platform	Meta or BSP on your request

Most legitimate provider switches use the migrate path. The deregister path is used when a BSP is offboarding a client and the client hasn't arranged a destination. The delete path is irreversible and should only happen intentionally.

The 30-day lock

Once you initiate a number migration or deregistration, Meta enforces a 30-day re-registration lock on that phone number.

This is commonly misunderstood. The 30 days starts from the date of the last paid message sent through the API — not from the date you submit the migration request. If you sent a message yesterday, the clock started yesterday.

During those 30 days, the number cannot be registered with a new provider through the standard API flow. This is a platform-level restriction, not a BSP policy.

Practical implication: If you need zero downtime, you have to plan the cutover carefully — typically by keeping the old provider active until the new provider's setup is fully tested, then migrating in a maintenance window.

What happens to your templates

Templates are tied to your WhatsApp Business Account (WABA), not to your provider. When you migrate your phone number to a new BSP, your templates follow the WABA.

However, there's an important nuance around template quality ratings:

Template status before migration	Status after migration
APPROVED + GREEN quality rating	Duplicated to new WABA; quality resets to UNKNOWN
APPROVED + YELLOW or RED	Duplicated; quality resets to UNKNOWN
PENDING or REJECTED	Not carried over

"Quality resets to UNKNOWN" means the new BSP's system has no quality history for that template. The template is live and usable, but it will go through Meta's quality monitoring cycle again based on user feedback signals.

In practice, if your templates have been performing well (low block rates, high read rates), they should re-establish GREEN quality quickly. If you have templates with history of poor engagement, migration is a good time to revise them.

Coexistence, and what it costs

During a migration window, some BSPs support a coexistence period where both the old and new providers are technically active on the same WABA simultaneously.

If this is the case, your messaging throughput is split:

Standard throughput: 80 messages per second (mps)
During coexistence with two active BSPs: 20 mps per BSP

This is not a temporary technical limitation — it's how Meta allocates throughput across concurrent API connections. If you're sending high-volume campaigns during a migration window, you need to account for this throughput reduction in your sending schedule.

Once the migration is complete and the old BSP connection is closed, throughput returns to the standard 80 mps.

One thing you cannot do through the API

You cannot delete a WhatsApp Business Account or phone number through the API. This action is only available through WhatsApp Manager (the web interface at business.facebook.com/wa/manage).

This matters because some clients, after migrating to a new provider, want to cleanly remove their old WABA entry. That requires logging into WhatsApp Manager directly — neither your old nor your new provider can do this on your behalf through API calls alone.

Five questions to ask before you sign

Before committing to a new provider, get clear answers to these:

Do you support direct number migration, or does the old number need to be deregistered first? (Deregistration triggers the 30-day lock; migration may not, depending on the flow)
What is your coexistence window policy? (Some providers require the old connection to be terminated before they can activate; this creates a gap)
Who is responsible for template integrity during migration? (Get this in writing — templates getting stuck in PENDING after a migration is a known failure point)
What throughput can I expect during the transition period?
How do you handle the 30-day lock if it applies to my number? (A good provider will have a documented answer; "we'll figure it out" is not acceptable)

The short version

There are three exit paths from a WhatsApp API provider: migrate, deregister, or delete — and they're not interchangeable
The 30-day lock starts from your last paid message, not from your migration request date
Your templates follow the WABA and survive the migration, but quality ratings reset to UNKNOWN
If two BSPs are simultaneously active on your WABA, throughput drops from 80 mps to 20 mps per BSP
Account deletion can only be done through WhatsApp Manager, not through any API call

Sources

Original post: What Actually Happens to Your WhatsApp Number When You Change Providers on Botsense.io