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
Top comments (0)