Unable to use WhatsApp omnichannel via Meta API plugin

Community Support
1

Description

Hi all,

I am trying to setup the WhatsApp Omnichannel feature with the official Meta API plugin.

After installing the plugin I received a message from the Omnichannel bot with the requirements and the setup forum. All of the requirements in the message are met

After filling out the forum and submitting, I get a strange error: 'Error occured while saving Phone Number. More info: invalid webhook url"

I wasn’t aware of any webhook setup so I’m not sure where to start.

Thanks a lot
Daniel

Server Setup Information

  • Version of Rocket.Chat Server: 6.11.1
  • Operating System: Docker container on Unraid
  • Deployment Method: Docker
  • Number of Running Instances: 1
  • DB Replicaset Oplog: N/A
  • NodeJS Version: 14.21.3
  • MongoDB Version: 8.0.3
  • Proxy: NGINX
  • Firewalls involved: Basic SOHO router
2

First, upgrade. Now. You should be on at least 6.11.3

For your own safety & security follow release information and keep up to date.

Next, what licence are you using? CE, Starter etc.

Number of users.

Next.

Use of an API usually necessitates a webhook url to call the API.

So have you got a reverse proxy, https & certs correctly set up? Tell us about it.

Tell us more about the Meta setup process.

What do your logs say, including your proxy logs?

3

Hi, thanks a lot for responding.

First, upgrade. Now. You should be on at least 6.11.3

I’ve now updated to version 7, the issue is still occuring.

Next, what licence are you using? CE, Starter etc.

Starter with 1 user

So have you got a reverse proxy, https & certs correctly set up? Tell us about it.

I’m using NGINX for reverse proxy with LetsEncrypt SSL which seems to be working as expected. The only slightly strange configuration I have is that the app is exposed on port 3000 (i.e. https://sub.mydomain.com:3000) and that port number is configured in the website URL value in the settings.

Tell us more about the Meta setup process.

I got all of the Meta API information direct from the dashboard, but I will double check they are all correct

What do your logs say, including your proxy logs?

No errors in Rocket.Chat logs, MongoDB logs, or the NGINX log

4

After further investigation it appears that after clicking ‘Connect’, a new popup asking for webhook details should appear.

It would seem this step is somehow being skipped resulting in the process failing

5

You need to fix that. 3000 will be available on the actual server, but 3000 should be blocked in your firewall for all remote access.

You should never access rocket with anything beyond the correct URL and https.

If you do when you login it can change the rocket server setting and the server will lose itself.

Go back and fix that all correctly so you only can contact your server from anywhere using:

https://chat.yourdomain.com

Make sure that is set in the server settings/config entries as well.

6

but 3000 should be blocked in your firewall for all remote access.

3000 is forwarded in the firewall for external access. I have tested and it is externally accessible.

You should never access rocket with anything beyond the correct URL and https.

Unfortunately it is the only option I have, as another web app is running on 80/443.

7

I’m sure it is. Except you don’t understand why you should not do that.

You are at serious risk of attack. Rocket is NOT a webserver. It has no web server protections. It just happens to produce html code on 3000 but that does NOT make it a web server.

You will not be able to use the iOS app with it at all. The Android version may complain but I haven’t tested on years.

I suslect your bginx proxy is actually doing anything flr Rocket. You just have a port forward to 3000.

I suggest you look at setting up your domains and web server correctly.

It is perfectly possible to do this but you will have to learn how.

Pretty sure you knew this already but thought you could work around it…

Very similar to this scenario:

https://xyproblem.info/

Hence my questions as I was pretty sure what you were doing wrong.

All of this is likely why it won’t work, and I am not offering you advice on trying to make an insecure setup work.

So, do yourself a big favour and set it all up properly. Nginx can handle multiple domains/subdomains etc.

You’ll likely find your original issue is then resolved. It almost certainly won’t until you fix this.

8

I understand that Rocket.Chat serves HTML on 3000 internally, however I have changed the internal port of Rocket.Chat to 2999 and NGINX serves 192.168.x.x:2999 to <public ip>:3000. I haven’t forwarded the internal Rocket.Chat server to the internet. That wouldn’t support HTTPS in the first place.

The web app is publicly available through that port with SSL support, via NGINX.

I doubt that the original issue has anything to do with that there is a port at the end of the URL. This looks more like a failed API call to Facebook or such.

9

Your problem here is not being accurate or consistent in what you say.

One minute you say you have:

3000 is forwarded in the firewall for external access.

Then you say Niginx is setup and properly configured but:

I understand that Rocket.Chat serves HTML on 3000 internally, however I have changed the internal port of Rocket.Chat to 2999 and NGINX serves 192.168.x.x:2999

And then:

I have changed the internal port of Rocket.Chat to 2999

So it is hard to understand exactly what you have got setup.

I suspect your issue lies either in the external access to your server somehow, or your firewall blocking an outgoing requests from Rocket - or a mismatch between outgoing and incoming requests.

We have spent a week kind of going in circles trying to understand your setup and getting nowhere fast. You have got to be more informative about things. You should also try and simplify your setup as much as possible to help yourself.

Why change the Rocket.Chat default port of 3000 when you have it behind a reverse proxy? Makes zero sense. The proxy can handle multiple different domains/subdomains and reverse them all to different places and ports.

I use Apache on my servers - I have say mail.domain going to one place and chat.domain going to another, all on the same server.

You should read this, particular “how to report bugs effectively” and the XY Problem.

10

Rocket.Chat is internally on port 2999 (I changed this in the Docker Compose to differentiate 2 different instances from different container images on Docker Hub. Now there is only 1 container with 2999.

NGINX + the graphical tool NGINX Proxy Manager is set up in another container, and configured to forward the internal IP’s 2999 port to another internal port on the server.

That port is forwarded to 3000 in the SOHO router, making it externally accessible with SSL certs from LetsEncrypt.

So, sub.mydomain.com:3000 maps to the reverse proxy port on the server, which forwards the traffic to port 2999 on the internal side (the Rocket.Chat container).

Sometimes I am not on the network of the server and can confirm that external access is 100% working on that port with HTTPS via LetsEncrypt.

Let me know if there’s anything else I could clarify
Thanks

11

This was my mistake in wording, 3000 is the external port. In the network there is no internal 3000 port as it was changed to 2999.

I see now I probably shouldn’t have used 3000 for the external port since it is the same as the default port for Rocket.Chat internally.

12

Yup.

I strongly suspect that you should make life simpler for yourself and tidy all that up.

You should not be using a port to connect to it remotely.

It might not be the fix but this is about trying to eliminate what it can’t be…

Then we can look at what it might be - you then might want to check the internal DNS in the docker container to ensure that domains resolve as expected.

13

I strongly suspect that you should make life simpler for yourself and tidy all that up.

You’re absolutely right, I should have fixed it earlier. I’ll clean it up and let you know if anything changes.

Thanks for the help so far

1 Like
14

@reetp Would you happen to know if the Meta API plugin is open-source considering it is made by the official Rocket.Chat developers? It would certainly be helpful for debugging. I haven’t been able to find the source anywhere.

15

I can see you refer to the “WhatsApp Omnichannel feature”

So which plugin did you actually install?

https://docs.rocket.chat/docs/rocketchat-marketplace

I believe that they are all private I’m afraid.

Note that the “Meta API” itself is here - I think what you mean is you wanted to see the app code:

16

So which plugin did you actually install?

WhatsApp Cloud → This one

Shame they are closed source.

17

So you followed this doc which I think is for this app?

And exactly where did you get stuck?

https://docs.rocket.chat/docs/whatsapp-cloud-app

It is what it is. Rocket have to try and make some money somehow. Otherwise they go bust and you have no chat software.

Of course you can build your own app…

18

@reetp
On this step:

  1. Click "Connect." After successfully saving the credentials, the final setup instruction for configuring the webhook URL on your Facebook developer console is displayed.

From what the docs say, after clicking Connect in that forum, “the final setup instruction for configuring the webhook… is displayed.”

However, after clicking Connect I immediately get a message from the setup bot saying ‘invalid webhook url’, with no such step asking to configure the webhook being displayed.

19

I think you fist said:

So what is up with the phone number?

Did you use a test phone number or a real one?

Navigate to WhatsApp > API setup. You will find a set of credentials to be used later for setting up the WhatsApp Cloud app in Rocket.Chat. By default, you’re provided with a test phone number, which has a Phone Number ID and WhatsApp Business Account ID. The access token provided is temporary and requires you to refresh periodically, follow these steps to create a permanent token.

I suspect you have made a mistake somewhere in the setup - either the data you have added is wrong or there is an issue in the docs.

20

@reetp
Looks like you were right all along, after cleaning up the environment and correctly configuring the proxy so that there is no need for a port number at the end, the issue has disappeared and the next stage of setup is working.

Thanks a lot!