N8n Cloud WhatsApp Trigger reports existing webhook subscription, but Meta API returns none

Questions
1

Hello,

I am using n8n Cloud 2.41.0 with the WhatsApp Trigger.

The WhatsApp Trigger reports:

“The WhatsApp App ID 4742348275987173 already has a webhook subscription. Delete it or use another App before executing the trigger.”

However, I reproduced the exact Graph API request used by n8n.

Using the same App ID, the same Client ID + Client Secret authentication flow, and Graph API v19.0:

GET /v19.0/4742348275987173/subscriptions

returns:

{“data”:}

The production webhook URL is also not registered in n8n. Requesting the production webhook URL returns:

“The requested webhook … is not registered.”

The workflow is published, but the production webhook is not reachable.

I also tested with a completely separate Meta App (App ID 1648520190125854), and the same n8n WhatsApp Trigger error occurs there as well.

The WhatsApp credentials themselves work:

  • OAuth credential connection succeeds.
  • The WhatsApp API credential can successfully send messages.
  • The new FAROL 4.0 WhatsApp number is connected.

Please investigate the webhook subscription/registration state on the n8n Cloud side for my instance. It appears that the WhatsApp Trigger is detecting an existing subscription that is not returned by Meta’s /subscriptions endpoint.

Thank you.

2

Hey @Multiplanos_Uberland, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@LogeshwariV, @Anshul_Namdev - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hi @Multiplanos_Uberland I checked the 2.41.0 code. That warning comes after a fresh GET to /{APP_ID}/subscriptions, when n8n finds an active WhatsApp subscription pointing at a different callback URL. An empty data array would skip that warning.

Does it appear when publishing, or only when clicking Execute step? Testing a published trigger uses a different callback URL.

If publishing itself raises it, please share the exact UTC timestamp and the redacted /subscriptions response immediately afterwards, without starting a test listener between them. The Cloud team would need to compare that with the response n8n received during activation. I wouldn’t delete anything while your API check returns no subscriptions.

4

Hey @Multiplanos_Uberland Welcome to the n8n community, The empty list is the state n8n leaves behind after that warning, not the state it saw. When the check finds a conflicting subscription it throws, and both the test path and the publish path then run the trigger’s delete on the way out, which is DELETE /{appId}/subscriptions. A failed publish also removes n8n’s own webhook rows, hence “not registered” on the production URL.

The check only matches a subscription with exactly your trigger’s fields, so the conflict is this workflow’s own other URL (or another workflow with a WhatsApp Trigger on the same App): /webhook-test/ from Execute step or Listen for test event versus /webhook/ from publishing. An App holds one subscription, so testing and publishing on it knock each other out, which is why the second App fails the same way.

Stop any test listener, Unpublish, then Publish, and leave Execute step alone on this trigger. Your GET right after should show one active subscription on the /webhook/ URL. Then send a real message and watch Executions.

5

I have run into this exact one before - the error is telling you the App ID already has a subscription registered somewhere, and Meta only allows one webhook subscription per app, so n8n correctly refuses to double-register.

The Graph call you reproduced returning empty data is the clue: the subscription n8n sees at the app level is not necessarily the one your GET shows. In my experience there are two usual causes:

1. Another environment holds it. If this App ID was ever used with a different n8n instance, a different workflow, or a manual webhook registration, that old subscription still owns the app. The n8n-side error and the Graph-side emptiness coexist because the subscription is registered against a different callback URL than the one n8n Cloud wants.

2. The subscription was created outside n8n. A manual subscriptions POST in the Meta console (or a previous test) registers a callback URL that no longer matches.

The clean fix: get an app access token (Graph API Explorer - your app - app token), then DELETE /v19.0/{app-id}/subscriptions - this clears whatever holds the slot. Then open the WhatsApp Trigger in n8n fresh and let it register itself. Verify afterward with your GET: you should see exactly one subscription pointing at the n8n Cloud callback URL.

If the trigger still complains after that, the remaining suspect is the WhatsApp Business Account linkage in Meta under Configuration: the messages field must be subscribed AND the specific WABA connected to that app, otherwise events validate but never dispatch.