How can I loop a POST to Wordpress until a new order is created?
Dealing with the weirdest thing, hoping ya’ll can help. Long time lurker, first time poster!
I’ve created a Zap to make pending Orders in WooCommerce using data from Deals in Pipedrive. And it works….but not all the time. Sometimes the Webhook Zap step returns data from a different / already existing order (a GET endpoint feature), and other times it creates the new order as it should from a POST (no modifications take place between these two). I’ve tried about a million different things but nothing seems to work. I’m no API expert but I think POST requests are either supposed to work, or not.
I either need one of two solutions to make this thing work:
A solution to loop the Webhook request until a string is matched (or not matched, either way)
A solution such that a post request to the WP / WooCommerce API will reliably result in orders being created.
Site is hosted on Pantheon and WooCommerce is updated.
Any ideas how I can get out of this?
Many, many thanks in advance.
Chris
Page 1 / 1
Hi @montague.cd
Good question.
Please post detailed screenshots with how your Zap steps are configured in order for us to have more context, thanks.
Also, check your ZapRuns history details to see the DATA IN/OUT for each Zap step to help you troubleshoot why the issue may be happening: https://zapier.com/app/history/
Hey Troy -
Thanks for the response. As the Zap is 20+ steps (all of which work as expected except this one step) are you looking to see how the Webhook step is set up, or something else?
@montague.cd
We need more visibility into the described issue.
How the Zap step is configured.
Specific examples of when it works and when it does not work.
Zap step in question is below:
@montague.cd
Do you have specific examples of when it works as expected vs when it does not?
Did you check your Zap Runs history details to see the DATA IN/OUT to help you troubleshoot?
OBSERVATIONS
Unsure if these are related to your issue.
The mapped variable for Subs # has “no data”.
The bottom 2 metadata items have the same display key.
I dummied up this data a bit so as to not ID my company and such, but I have tried it many ways and the duplicate display keys / lack of data in the Subs# doesn’t kill this process.
The real issue here is that the process always runs - it never errors out so there’s nothing to troubleshoot. Each time the Webhook step runs, one of these two things happens:
An order is created as expected from POST - data is returned from WooCommerce about that order
No order is created - data is returned from WooCommerce about other orders. This is a GET function of the WooCommerce Orders API.
Worse yet, when #2 occurs, WooCommerce passes back an array of 9 recent orders, which triggers 9 instances of the Zap steps after step 20. So instead of 1 good invoice, we’re making 9 invoices, all of which have the wrong information on them! Lovely.
In my mind, this webhook should either fail because it’s malformed in some way / missing data / etc or it should POST an order and return the order data to Zapier.
FWIW Postman shows a 201 created on a successful order - I cannot see what Zapier is sent back.
Looking at Data In / Out confirms my statement - I am passing POST data for order 123 to WooCommerce, and getting back data about a completely different order, which we’ll call 456 for this example. They don’t even begin to match.
@montague.cd
No order is created - data is returned from WooCommerce about other orders. This is a GET function of the WooCommerce Orders API.
In app APIs, I’ve seen this happen when a required path parameter is missing, which in turns can change the nature of the request. (e.g. from a POST to a GET)
I will emphasize this again: Check your ZapRuns history details to see the DATA IN/OUT to help you troubleshoot: https://zapier.com/app/history/
Worse yet, when #2 occurs, WooCommerce passes back an array of 9 recent orders, which triggers 9 instances of the Zap steps after step 20. So instead of 1 good invoice, we’re making 9 invoices, all of which have the wrong information on them! Lovely.
For this, why not add a Filter step to prevent the Zap from continuing if there isn’t the expected response returned.
We’d need to see screenshots of the Zap Runs DATA IN/OUT for the Zap step in question for examples where it work VS when it did not work.
If you need additional help, then I suggest opening a ticket with ZapierSupport since they can look into the Zap Run logs deeper: https://zapier.com/app/get-help
FWIW - I figured this out, and it wasn’t an issue with the API call. Troy’s answer above got me thinking about other reasons that the action might not be working, which ultimately led me to the solution - thank you @Troy Tessalone .
For anyone else in the world that is confounded by a similar issue, WooCommerce does not document adding ‘www’ to your base URL (in fact, it shows the opposite) but in the end that’s what solved this issue.