Messages not being sent to Chatwoot

[justinkruit]

I've been trying to get it to work for the last few days, but no luck.

1. Installed Chatwoot adapter 0.8.0
2. Set the base URL to my own instance
3. Set the account ID
4. Created an API channel inbox in Chatwoot and added the ID
5. Did the instance settings as described in The Setup

But no matter what, new messages from people don't get sent to Chatwoot. I can also see no logging for this to see if something goes wrong.
I do see, when I press the Healthcheck button "1 dead-lettered after 5 attempts". But I double checked all config lines, and still it runs into an issue.

[rmyndharis]

Sorry you've lost days to this. The "dead-lettered" line means your messages are reaching the plugin and Chatwoot is rejecting them (or is unreachable) — so this is a connection or configuration problem between OpenWA and Chatwoot, not a WhatsApp one. That narrows it a lot.

The frustrating part is that the plugin already knows exactly what went wrong and writes it to the server log, but never shows it to you. That's a gap on our side and I've opened #66 to fix it. In the meantime, the log is where the answer is.

The one thing that would settle this immediately — send a WhatsApp message to the connected number, wait about three minutes, then:

docker logs --tail 300 <your-openwa-container> 2>&1 | grep chatwoot-adapter

(or journalctl -u openwa --since '5 min ago' | grep chatwoot-adapter if you're not on Docker)

Look for inbound relay failed or inbound relay dead-lettered. Those lines carry the exact Chatwoot status code and response body. Paste them here and I can tell you the cause outright.

If you can't get at the logs, these four questions cover the common causes:

1. What exactly is in the "Chatwoot base URL" field, character for character? It has to be the address only — https://chat.example.com — with nothing after it. If it contains /app or anything else copied from the browser address bar, every request goes to a URL that doesn't exist. This is common enough that fix(chatwoot-adapter): tell the operator why a relay failed #66 makes the plugin reject it when you save.

2. Where did the API access token come from? It must be Chatwoot → your avatar → Profile Settings → Access Token. The API inbox's "Inbox Identifier" and the webhook HMAC key both look like credentials but authenticate nothing on this API. Also check the user that token belongs to is actually a member of the account ID you configured.

3. Run this from the machine (or inside the container) running OpenWA — running it from your laptop won't test the same thing:

   curl -i -H "api_access_token: YOUR_TOKEN" \
     "https://YOUR-CHATWOOT/api/v1/accounts/YOUR_ACCOUNT_ID/contacts/search?q=test"

   200 with JSON clears most causes at once. 401/403 is the token, 404 is the account ID or the URL, and a connection or certificate error points to the next question.

4. Is your Chatwoot on a public domain with a normal certificate? OpenWA refuses to connect to private addresses and won't accept an untrusted certificate — either produces exactly your symptom with no HTTP status to show for it. Worth checking from inside the container:

   getent hosts your-chatwoot-domain

   Anything in 10.x, 172.16–31.x, 192.168.x or 127.x is blocked. Same applies if there's Cloudflare Access, Authelia or basic auth in front of it — those return a login page instead of the API response.

One more worth a quick look, because we have a confirmed fix for it in #62: in Chatwoot, go to Contacts and search for the phone number of the person whose messages aren't arriving (try with and without the leading +). If a contact already exists and its Identifier field is blank or is anything other than the number followed by @c.us, that's the bug — the plugin can't claim the number and every message from that person fails. Contacts are shared across your whole Chatwoot account, so one created by an import or another inbox counts even though your API inbox is new.

Lastly, a detail that trips people up: the dead-letter count resets when OpenWA restarts or the plugin is re-enabled. "1" means one message has failed since the last restart, not that only one ever has.

[rmyndharis]

Quick follow-up: 0.9.0 is out, and it includes the change that would have shown you the cause on day one.

Download it here and upload it in the dashboard over your current install — your configuration and API token are preserved.

Two things change for your situation:

The Healthcheck button now tells you the reason, not just the count. Instead of 1 dead-lettered after 5 attempts you'll get something like:

1 dead-lettered after 5 attempts; last error: Chatwoot GET https://.../contacts/search -> 401: {"error":"..."}

That single line usually identifies the problem outright — a 401 is the token, 404 is the account ID or the URL, Blocked internal address means Chatwoot isn't reachable from inside OpenWA, and a certificate error says so directly. It also appears on the first failure now, so you don't have to wait ~3 minutes for the retries to run out.

A baseUrl with a path is now rejected when you save the settings. If that was the issue, the plugin will refuse to enable and say so, instead of accepting it and failing on every message.

So the fastest path from here: upgrade, send one test message, press Healthcheck, and paste what it says. That should replace most of the questions in my previous comment.

To be clear, this doesn't fix whatever is rejecting your messages — it makes the reason visible. But once we can see it, the fix is usually a one-line configuration change.

Also worth knowing since you're upgrading anyway: 0.9.0 fixes two separate bugs where messages were silently lost, one of which is the contact-identifier collision I mentioned in my previous comment. If that happened to be your cause, the upgrade fixes it outright.

[justinkruit]

It returns me the following error:

Chatwoot GET https://chatwootinstance.com/api/v1/accounts/2/contacts/search?q=hiddenforprivacy -> 401: {"errors":["You need to sign in or sign up before continuing."]}

Which seems weird as I provided the access token. And yes I updated it the plugin to v0.9.0

[justinkruit]

Got it fixed; it was because of Nginx. Needed to add underscores_in_headers on; as the api key was falling away.