fixmation.Get my quote
Make17 min readPublished October 2026

WhatsApp says the number is connected to Make. Make cannot find it

Connecting a number that already lives in the WhatsApp Business app to Make ends on a Meta screen that says "Your account is connected to Make", and then on a Make screen that says "Resource not found". Where the credential does get created, the number can sit in "Pending" for weeks, and messages your staff send from the phone never reach the scenario. Meta's own documentation describes the gap between those two screens, and it belongs to the partner, not to you.

Two screens, one after the other

The report below was posted on Make's community on 10 September, by the author of one thread into another - the fourth thread with the same sequence since July:

This time, Meta successfully recognized and selected our existing registered WhatsApp Business number. The authorization process completed successfully and Meta explicitly displayed: "Your account is connected to Make." After clicking Finish, the callback returned to Make and immediately displayed: "Resource not found." We then checked Make → Credentials → Connections. Searching for "WhatsApp" returns "No results were found", confirming that no WhatsApp Business Cloud credential was created despite Meta completing the authorization successfully.

The setup being attempted is the one most small businesses want. The number already runs in the WhatsApp Business app on somebody's phone, customers know it, and the owner wants a scenario in Make to see the same conversations without giving the phone up. Meta's partner documentation calls that arrangement Coexistence, and Make has offered it as a "Signup Mode" when creating a WhatsApp Business Cloud connection since the spring. Between 24 July and 8 September, four people posted the "connected" then "Resource not found" sequence; one more reported the connection created but the number stuck in "Pending" for two weeks with the trigger silent; one more reported everything working except the messages his staff send from the phone. None of the three got a reply from anyone at Make. As of 12 September the fourth thread had been open four days.

What the three reports have in common is obvious only from Meta's documentation for the company on the other side of that screen.

What "connected" means on that screen

The screen the users describe is the last one in Meta's Embedded Signup flow. Meta documents exactly what happens when the button is pressed:

This screen indicates that Coexistence onboarding completed successfully. When the business customer clicks Finish, Embedded Signup triggers a message event containing the business customer's WABA ID and business phone number ID, which you must then use to onboard the business customer to the platform.

"You" in that sentence is the partner - the company that embedded the signup flow in its product. For a connection created in Make, that is Make. And the page Meta writes for partners is blunt about what the customer has at this point:

If you are a Solution Partner, a business customer who completes your implementation of the Embedded Signup flow cannot immediately use your app. They cannot access their WhatsApp assets or send and receive messages until you complete these steps.

The steps that follow on that page are the partner's, server to server: exchange the code Meta handed back for a token, subscribe the partner's app to the customer's WhatsApp Business Account, share a credit line, and register the phone number - except that for a number coming from the app, Meta's Coexistence page says to "skip the phone number registration step, as the number is already registered".

So "Your account is connected to Make" is a true statement about one thing: Meta has granted Make access to your account. Users in two of the four threads confirmed it from the other side - Make shows up in their Business Settings as a partner with access to the account. What the screen does not say is whether Make then finished its own part. "Resource not found", followed by "Failed to verify connection [400]" and no credential in the list, is what it looks like when it did not.

Make knows about this outcome. Its page for the app, updated 9 September, ends the connection steps with:

Click Next > Confirm > Finish. If you receive the Resource not found error message after completing the process, please retry. Any new Facebook Business Accounts or WhatsApp Business Accounts you created during your first attempt have been successfully created. When you retry, simply select these existing accounts from the list. It is not necessary to create them again.

"Please retry" is all the guidance the vendor gives. The user quoted at the top had retried on 7 September and again on 10 September. It is also worth reading that paragraph for what it is not about: the accounts it says were "successfully created" are the ones Make's flow creates for a new number. A Coexistence user brought an existing number and created nothing. And one of the four threads, from 24 July, is not a Coexistence case at all - the user chose "Regular mode, not Coexistence", for a brand-new number, and got the same "Resource not found" and the same 400. Whatever fails after the callback, it is not specific to the mode.

"Pending" is a status, not a queue

The second report is what happens when Make's part goes further. The connection exists, a "Get a Business Profile" module runs and returns the profile, and the "Watch Events" trigger never fires:

In Meta Business Manager → WhatsApp Accounts → Phone numbers, the phone number has remained in "Pending" status for approximately two weeks. Meta displays a message saying that the phone number must be registered using the API or by a partner. I also tried the "Register a Sender" module in Make using the same Coexistence connection. It failed with a 400 / Invalid parameter error stating that the phone number is already registered with an existing WhatsApp account and would need to be disconnected first.

Meta's page on business phone numbers is one sentence on why that trigger will stay quiet: "Business phone numbers must have a status of 'connected' in order to send and receive messages via the API." A number in "Pending" has not been registered for Cloud API. The two things a user can reach for both fail by design. Registration happens only through the API - "you cannot register a number through WhatsApp Manager (WAM) or the App Dashboard" - and the API call, which is what Make's "Register a Sender" module makes, is the one Meta told partners to skip for a Coexistence number, because the number is registered already, to the app on the phone. The error text the user got back says as much: "This phone number is registered with an existing WhatsApp account. To use this number, disconnect it from the existing account." Disconnecting it from the app is precisely the thing Coexistence exists to avoid.

Meta's interface, quoted by the July user, says to "register this phone number with the registration API or contact your technology partner to register it"; the September user paraphrases the same message. The technology partner is Make. And Make's only staff reply on the subject of Coexistence, from July, to a different user whose trigger was also silent, was this:

Watch Events - Instant trigger, currently supports only new WABA flow with Regular/Coexistence mode. It's not possible to recommend a workaround of using *Legacy connection. Might I suggest trying to use Regular mode?

Regular mode means a number that is not in the app. For the business that came here because the number is in the app, that is not a workaround; it is the alternative they already rejected.

The messages your staff send from the phone

The third report is from a setup where everything above worked. Inbound messages arrive in the scenario, delivery statuses arrive, and:

Inbound messages and delivery statuses arrive correctly through WhatsApp Business Cloud > Watch Events, but messages sent from the WhatsApp Business mobile or desktop app never reach the scenario. Meta uses the smb_message_echoes webhook field for these app-sent messages. [...] No error is produced. The manually sent message simply never appears in Watch Events, while ordinary messages and statuses continue to arrive.

This one is documented in full. Meta's Coexistence page lists three webhook fields a partner has to subscribe to in its own App Dashboard, "in addition to any fields you are already subscribed to as a partner", and says of the third:

Each time a business sends a message with one of these apps, it triggers an smb_message_echoes webhook, which you must digest and display in the contact message thread history in your app.

The ordinary messages field does not carry them. Meta's reference for that field says outgoing messages "have a different structure" and that those webhooks "don't describe the contents of the outgoing message itself, only its status". A reply typed on the phone reaches the scenario, if at all, as a status with no text.

The user reporting this listed what Make's "Watch Events" trigger lets you choose: Messages, Message Statuses, Message Template Status Update, Account Review Update, Account Update, Business Capability Update, Phone Number Name Update and Phone Number Quality Update - eight fields, and not the one Meta says a Coexistence partner "must digest". Make does not publish the list on its documentation page and did not dispute his, so his is the one on record. The subscription lives in Make's App Dashboard, which is Make's, not yours; there is no setting in a scenario that adds a field the partner's app is not subscribed to. Whether Make receives the echoes and drops them, or never subscribed, is a question only Make can answer, and on 12 September nobody there had.

For a business that wanted the CRM to hold both sides of the conversation, this is the quietest of the three failures. The scenario runs. The customer's messages are in the CRM. The replies your staff sent from the phone are not, and nothing counts them.

There is a fourth item in the same family, from the same user the day before. Meta gives the partner 24 hours after onboarding to synchronise the customer's message history - "otherwise they must be offboarded and they must complete the flow again" - and of the request itself: "You can only perform this step once." Make has no module for it, and whether Make makes that call on your behalf during onboarding is not documented anywhere. If it did not, the window closed on the first day and nothing said so.

The same number in n8n and Zapier

n8n does not offer Coexistence, and the reason is structural rather than a missing feature. Its WhatsApp credential wants an access token and a business account ID from your own Meta app - its documentation notes that "Meta classifies users who create WhatsApp business apps as Tech Providers" - and there is no Embedded Signup in it. The trigger node lets you subscribe your app to any of a fixed list of ten fields, from Account Review Update to Template Category Update, set in the node's source; smb_message_echoes is not among them. So even a business that had built the Coexistence onboarding itself against Meta's partner documentation would find the n8n trigger unable to hear the phone's side of the conversation without a separate webhook of its own.

Zapier's WhatsApp Business app requires "a WhatsApp Business Account (WABA) with a valid and registered phone number", and says "a personal WhatsApp number will not work". Nothing on its pages mentions Coexistence or the app on the phone by name. If Coexistence is the requirement, Make is the one of the three that offers it, which is also why Make's forum is where the reports are.

Which of the three you are in

Everything below is read-only and can be done on a live number. None of it requires disconnecting the app.

  1. Open Make → Connections and search for "WhatsApp". If the connection is not there, you are in the first case, and Meta's screen told you the truth about the grant and nothing about the rest. Retrying is what Make's page says to do; the users above did, and it is the only step available to you. What to send Make Support if the retry ends the same way: the time of the callback, the phone number ID from WhatsApp Manager, and the exact text of both messages.
  2. Open WhatsApp Manager → Account tools → Phone numbers and read the Status column. "Connected" is the only value under which the API will carry messages for the number. "Pending" with a working connection in Make is the second case. Do not run the "Register a Sender" module against it; it will return the "registered with an existing WhatsApp account" error, and the only way to make it succeed is to take the number out of the app.
  3. Send a message to the number from a customer's phone, and reply from the Business app. With the trigger running, the first arrives as a bundle and the second does not. That is the third case, and it is not a misconfiguration on your side: there is no field to tick. If replies from the phone must reach the CRM, the scenario needs a second source for them, and Make's trigger is not it today.
  4. If you open a case with Meta, use the categories Meta assigns to this setup. Its Coexistence page ends with them: for onboarding, Question Topic "WABiz: Onboarding" (Meta lists "TechProvider: Onboarding" alongside it, for partners) and Request Type "Embedded Signup - Coexistence Onboarding"; for the API side, "WABiz: Cloud API" with "Coexistence Data Synchronization APIs and Webhooks". A case filed under a generic topic is answered generically. Expect Meta to point at the partner: one user in the Pending thread was advised to open exactly this case "because Make cannot complete the Meta-side provisioning itself", and Meta's own text on the number says to contact the technology partner.

The check the partner is supposed to run is in Meta's documentation too: a GET on the phone number ID for the fields is_on_biz_app and platform_type, which should return true and CLOUD_API for a number that is working in both places. It needs a token for your business portfolio, which a Make user does not have by default; if you or whoever built your automations has one, it is the one request that answers the question without inference.

This is the same shape as a webhook that Meta reports as verified while no messages arrive, with one difference that matters. There, the missing subscription was in your own app and you could add it. Here, the app is Make's, and the green status is Meta's report on a grant to Make, not on anything Make did with it. Establishing which of the three cases a business is in, and building the phone side of the conversation into the CRM by another route where it has to be, is Make work with a price on it, and it does not need the number taken offline.

What changes before this is read

One date sits between the day this was written and the day it is published: on 8 October Meta retired version 2 of Embedded Signup, and which version Make's connection flow runs on is not published. One change was already under way. Since 15 July Meta has been rolling a "Phone Number First" order of screens out to Embedded Signup, and on 3 September it updated the v4 flow to it and explained the consequence for this mode: "Embedded Signup now enters the Coexistence flow automatically when Coexistence is enabled and the number is already in use with the WhatsApp Business app, instead of the business customer selecting the WhatsApp Business app option." The rollout was in progress on 12 September. Once it reaches everyone, the mode described in this article is no longer a choice a Make user makes; it is what happens when the number typed in is the one on the phone.

Sources

Broken workflow? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.