Messaging trigger works on the hosted instance but fails on my self-hosted one — same credentials, same workflow

Worth adding the verification handshake, because it produces a very specific and confusing failure.

Many messaging platforms verify a webhook endpoint before they will use it: they send a challenge request, and your endpoint must echo a value back, or reply with a specific status, within a short timeout. If that handshake fails, registration is rejected — sometimes with a generic message that tells you nothing.

Things that break the handshake even when the URL is otherwise perfect:

• a reverse proxy that adds an authentication layer in front of the whole instance, so the challenge gets a login page instead of the expected response
• a redirect from http to https, or from a bare domain to www, that the verifier does not follow
• a trailing slash difference between what you registered and what your proxy serves

That authentication-in-front one catches a lot of people who did the responsible thing and put their self-hosted tools behind an access proxy. You have to exempt the webhook paths.

The difference is the callback URL, and once you see it the whole class of "triggers do not work self-hosted" problems collapses into one thing.

An incoming-message trigger is not polling. When you activate it, your instance registers a webhook with the provider — it tells the provider "call this URL when a message arrives". The provider then makes an inbound HTTP request to that URL from the public internet.

On the vendor's hosted version, your instance has a public HTTPS URL and it knows what that URL is, so registration works and the provider can reach it.

Self-hosted, two things go wrong:

1. Your instance advertises the wrong URL. By default it builds the callback URL from its own idea of where it lives, which is often localhost, a container name, or an internal address. It registers that with the provider. The provider stores it, dutifully calls it, and reaches nothing — or refuses to accept it in the first place, which is your intermittent registration error.

The fix is the setting that tells the instance its public base URL. Nearly every self-hostable automation platform has one, usually an environment variable, and it exists precisely for this. Set it to the exact public HTTPS URL the outside world uses, restart, then deactivate and reactivate the trigger — this is the step people miss. The registration is made once at activation and does not update itself when you change the config. A stale registration points at your old wrong URL forever.

2. The provider cannot reach you. Even with the right URL advertised, the request has to arrive:

• Public reachability. The URL must be reachable from the internet, not just from your network. Test it from outside — a phone on mobile data is the quickest honest test.
• HTTPS with a valid certificate. Most providers require TLS and will not accept a self-signed certificate. A self-signed cert makes the browser complain; it makes the provider silently drop the registration.
• Standard ports. Several providers only call port 443 and will reject a URL with a custom port at registration time.
• Provider IP restrictions. If you have geo-blocking or an allowlist at your edge, the provider's servers may be blocked. This produces the pure-silence case: registration succeeds, nothing ever arrives.

How to tell the two apart in one minute. Look at the trigger node in the editor — it shows you the webhook URL it is going to register. If that URL contains localhost or an internal hostname, it is problem one and nothing else matters yet. If it is your correct public URL, it is problem two, and the next step is your reverse proxy access log: make the provider send a test message and see whether a request arrives at all. Request in the log means the problem is downstream of the proxy. No request means it never got to you, and that is DNS, firewall, TLS or the provider's own restrictions.

One more, since your description mentions it activating and then nothing arriving: most of these platforms use a different webhook URL in test mode than in production, and the test URL only listens while you have the editor open with the node listening. Activating the workflow switches to the production URL and re-registers. If you tested in the editor and it worked, then activated and it stopped, that is this.

Once it works, remember that the registration lives on the provider's side and can drift.

If you rebuild the container, change the public URL, or restore from a backup, you can end up with the provider holding a registration pointing at something that no longer exists, and your fresh instance thinking it is fine. Deactivate and reactivate after any of those.

Worth putting an alert on it too — a workflow that quietly stops receiving is much worse than one that errors, because nothing tells you.

Practical debugging tool for this: point the provider at a public request-inspection endpoint temporarily instead of your instance.

If messages show up there, the provider side is configured correctly and the problem is entirely on your side of the wire — which narrows it enormously and takes about two minutes to establish.

If nothing shows up even there, the problem is the provider configuration, the credentials, the app's permissions or the number the messages are being sent to, and you have been debugging the wrong machine.

Splitting the problem at the boundary first saves a lot of time with anything webhook-shaped.