Shopify Trigger Not working

New to N8N - I’m trying to set up a Shopify Trigger to update a Case in Salesforce when a Shopify Order is Paid, but I’m not getting any Order info in N8N. I saw that there were other topics made about similar problems but none of the solutions suggested worked.

I created a new Private App and I’m using the credentials from the new Private App (including the Shared Secret, not using the one that is found in the bottom of the Webhooks section in Shopify).

I also set up the Webhook in Shopify itself with the Test URL given by N8N.

I’ve sent the Test Notification from Shopify after turning the Workflow active and executing it, but there’s never any information received from Shopify by the Trigger. I also don’t get any errors from the Shopify Trigger.

What could be causing this?

I’m running the Desktop App.

Here’s my workflow:

Hi @jkwok, welcome to the community :tada:

I’m sorry to hear you’re encountering this behaviour. You wouldn’t usually need to manually create a webhook for trigger nodes (this can in fact be problematic for services where only a limited number of webhooks can be active at the same time).

Unfortunately, I don’t have a paid Shopify account, so I can’t test the “Order Paid” event directly. But I’d suggest the following:

  1. Make sure your n8n instance is available under an HTTPS URL. Shopify rejects sending webhooks to HTTP URLs.
  2. Create a new workflow with only a Shopify Trigger to start with. Execute the workflow manually, trigger the event the Trigger node is waiting for and see if that works.
  3. If the manual execution has worked, switch the workflow to active and make sure you save successful executions in your workflow settings. Now trigger the event again. You will not see the data coming live into your canvas for production executions, you would need to open it through the executions list available through the sidebar:
    image

If you’re still able to see incoming Shopify data after following the above steps, could you confirm where exactly it’s failing for you? Many thanks!

@MutedJam thanks for your response:

  1. Where do I check for the instance URL? I’m using the desktop app. The URL being used for the Webhook is HTTPS.
  2. I tried this and I don’t receive any data.

I tried using a regular Shopify node to retrieve data and it worked - so my credentials are correct. I suspect it’s something to do with #1 but I don’t know where to check for this in the Desktop App.

Yes, the webhook URL shown would be the right one here. Can you share the error message you’d be getting when opening the webhook URL in a browser? This should give us an indicator if your n8n instance responds with its own error message or whether the error might be somewhere outside your instance.

https://redacted-for-privacy-reasons.hooks.n8n.cloud/webhook-test/c7422666-fe08-4a1b-9b0b-7b987c407afe/webhook

I get a 404 when I open the webhook URL - what would be the cause of this?

So the error shown under the URL you have originally shared wouldn’t be coming straight from the n8n instance (as it would throw an error like {"code":404,"message":"The requested webhook \"GET foo\" is not registered ... instead). I do however wonder if you are affected by the problem described here:

Could you try the approach suggested by @ivov in the linked thread to see if that changes the behavior for you here? So deleting the tunnelSubdomain key from your ~/.n8n/config (Mac) or C:\Users\Username\.n8n\config (Windows, replace username with your actual username) file, changing the file content from something like this:

{
  "encryptionKey": "foo",
  "tunnelSubdomain": "bar"
}

to this:

{
  "encryptionKey": "foo"
}

Make sure to quit n8n.desktop beforehand and restart it afterwards.

I tried doing this but after restart the config file is changed and shows “tunnelSubdomain” again. Should I try reinstalling the app?

So having the key re-appear is normal as long as it has changed. That’s because removing it should only lead to your n8n receiving a new subdomain (hopefully a working one).

So the next question is whether the subdomain used by your n8n instance has changed as expected here? E.g. when opening the Shopify trigger, does the URL shown now consist of a random string rather than the previous format {adjective}-{noun}-{number}?

If so, could you try testing the Shopify trigger one more time?

The URL still shows as the previous format and the Shopify Trigger still doesn’t work.

I’m sorry to hear that - I haven’t seen this problem first hand yet unfortunately. If un- and re-installing n8n.desktop doesn’t help either, maybe @ivov has any additional ideas on how to re-generate a working tunnel URL?

Other approaches I can think of:

  • Using n8n.cloud (which wouldn’t require the tunnel) or self-host n8n with a publicly available HTTPS URL. These approaches would also have the advantage of being able to process Shopify events when your computer isn’t turned on.
  • Poll the required data from Shopify in intervals. For example, you could run a workflow every 10 minutes searching orders created in the last 10 minutes. This should also work fine when incoming requests aren’t working.

So I’m now using the npm version of n8n and I changed the webhook URL via setting the environment variable to one that I am using in other services (from ngrok).

However I still am not getting anything from the Webhook - I’ve changed the link on the Shopify end to match the Webhook link generated by N8N. Whenever I fire a test event from Shopify nothing happens.

Seeing you are using ngrok now for your npm, could you confirm whether other webhooks are working fine for you? E.g. when creating a simple workflow with a webhook node, manually executing that workflow and then opening the test URL, would this work? Just trying to get a sense of whether this is a Shopify problem or a more general problem.

Just to close this issue out - I went back to the Desktop version and the webhook URL is now a random string instead of the {adjective}-{noun}-{number} format, and I was able to get a response from Shopify, so it appears that the fix you suggested worked (albeit it took some time to take effect).