What is your goal?
Restore our existing WhatsApp Business Cloud connection so our daily template-message scenarios (student lesson reminders) run again, without re-registering or migrating our live phone number or losing approved templates.
What is the problem & what have you tried?
Since 19 Oct 2026 our WhatsApp Business Cloud connection fails every run, and Verify on the connection gives the same error. All scenarios using it are down.
Checked in Meta Business Settings: business verified, WhatsApp account approved, phone number Connected (quality High), “Make for Business Messaging” still listed under Connected apps with WhatsApp permissions, Make is a partner with Full access on the WhatsApp account, our admin is assigned with Full access, nothing removed or expired.
Reauthorize > Continue jumps straight to “Add your WhatsApp phone number” offering only “Enter a new phone number”. It never shows business portfolio or WhatsApp account selection, and Back returns to the start screen. Connected apps shows two WhatsApp account IDs with the same name, so it may be picking the wrong one.
Has anyone fixed this without creating a new connection? Is creating a brand-new connection (+ Connection) safe for an already-registered number, or will it try to register it again? A support ticket is open but we need this working within 24 hours. Thanks!
Error messages or input/output bundles
AccountValidationError: Failed to verify connection ‘’. [400]
Cannot initialize the scenario because of the reason ‘Failed to verify connection … [400]’
On cancelling reauthorize: {“code”:“SC424”,“suberrors”:[{“message”:“[access_denied] Permissions error”,“name”:“InvalidConfigurationError”}]}
That “Enter a new phone number” screen you’re seeing is the add number path, so I would avoid completing it with your live number. Meta might treat that as a registration or a migration. I would also hold off on a new connection until you know which of the two same name WABA IDs holds your number and templates. The phone numbers listed in WhatsApp Manager will show you. Here is a thing worth trying: reauthorize in a clean incognito session as someone who is the portfolio admin (not only assigned on the WABA). The skipped portfolio selection and the access_denied error both point to a permissions or grant mismatch. Add the WABA ID and phone number ID and the 19 Oct failure time to your support ticket. That helps them check on their side.
For a 24 hr stopgap, you could send the approved templates with an HTTP module that calls the Graph API (/{phone_number_id}/messages) using a Meta system user token. It will bypass the broken connection and not touch the registration.
Thank you, this is really helpful. To answer your points: WhatsApp Manager shows our live number and approved templates on the WABA ending …7461, so that is the one the connection should use. I am the business portfolio admin (Full access, Everything), not just assigned on the WABA. The WABA ID, phone number ID and the 19 Oct failure time are already on our support ticket.
I’ll try Reauthorize in a clean incognito window today, stopping if it shows “Enter a new phone number” again, and will report back here.
Update: tried Reauthorize in a clean incognito window, logged in to Facebook as the business portfolio admin. Same result: it skips portfolio and WhatsApp account selection and goes straight to “Add your WhatsApp phone number” with only “Enter a new phone number”. I cancelled there. So it is not a cached session.
We are holding off on any new connection and sending reminders manually until Make support (ticket #2338179) responds. If anyone from Make staff can look at why embedded signup skips account selection for an existing, already-shared WABA, that would be much appreciated.
Quickest way around it is skipping the app connection. In Meta Business Settings make a system user, assign it your WhatsApp account, generate a permanent token with the messaging permission, then send the template through Make’s HTTP module to the Graph API messages endpoint. Your number and approved templates stay as they are.
If you use the HTTP workaround while support investigates, I’d keep one shared send log for both paths, keyed by the student, reminder type, and scheduled lesson
That way, when the original Make connection is restored, the regular scenario can check which reminders were already sent through the temporary route before sending again. Otherwise the recovery itself could create duplicate messages
While the ticket is open, one thing worth checking: in Meta Business Settings (Accounts → WhatsApp accounts), see whether Make's app still has access to the WABA ending …7461. A common reason for Reauthorize jumping straight to "add a new number" is that the app can no longer see the existing account. If access is missing, granting it again there may bring the old connection back without touching your number.
Thanks for the suggestion. We’ve already checked this: in Meta Business Settings, “Make for Business Messaging” is still listed under Connected apps with access to the WABA ending …7461, and Make is a partner with Full access on that WhatsApp account. So the access is there. Make support has confirmed Meta’s Embedded Signup isn’t returning the account to Make and has reported it to Meta.
It’s good that Make confirmed it’s on Meta’s side. Something to clarify on the HTTP route, in case it got lumped in with the permissions check: it doesn’t depend on Make’s Connected apps entry or partner access at all. You would create a system user in your portfolio, assign it the WABA ending …7461, generate a token with whatsapp_business_messaging, and call the messages endpoint from an HTTP module. Embedded Signup isn’t involved at all, so it should work even while the connection is broken. Just store the token securely and match the template name and language code exactly.