I’m getting this error when I test my POST to a data source, which is a Zapier webhook configured to catch a raw hook:
Zapier is receiving a hook, but the body is empty:
(Here’s the rest of the data Zapier is capturing:)
The schema is super simple:
There aren’t any http placeholders, query parameters or anything. All of the other methods (GET, DELETE, PUT, etc) are disabled.
I tried changing my zapier catch to accept a regular webhook, and tried that both regular and with silent mode (no response) enabled. Made no difference.
Anyone have any insights about what might be going wrong? I’m stumped.
Can I see the raw network request from the browser inspector? That might help you to pinpoint the issue as well.
@Sasu_Makinen, I don’t see a way to attach the .json file to this post, so I’m sending it to firstname.lastname@example.org with a request to forward it on to you.
I don’t speak dev, so if I sent the wrong thing, just let me know and I’ll try again.
I took a look at the request. It seems valid. Is the Zapier endpoint expecting the body to have specific form? Like all data under specific key etc?
The Zapier endpoint doesn’t require any specific form. We use the same kind of Zapier endpoint for some webhooks we POST from our own server. I’ll sit down with my developer and compare that JSON file to what we’re producing to see if there are any noteworthy differences.
I’ll report back!
Our developer wasn’t able to find anything obvious. His guess is that Zapier might not like XHR requests (sent from a browser rather than a server). I found a StackOverflow post from 6 years ago that says that was originally an issue with them but that it had been fixed.
I’m reaching out to Zapier’s tech support to see what they have to say. As before, I’ll report back!
I heard back from Zapier.
It turns out that Zapier does not allow OPTIONS requests to their hook infrastructure. Is there a way of doing the test calls in the API designer in a way that proxies the requests through AppGyver? It might be a more “accurate” way to test it anyway, since the calls made by the designer are XHR calls (hence the OPTIONS request that’s failing), and calls made by an app look to a server like they are coming from another server or desktop application (i.e., no OPTIONS call necessary).
I have zero comprehension of what would go into that–whether it’s a 2-second fix or a major overhaul that would have to go onto the wishlist.
Proxying the requests is a bit of a double-edged sword, as the requests from the web version of your app will come from the user’s browser. It’d be easy to shoot yourself in the foot with that, as then your web app won’t work, and CORS rarely fully makes sense to anyone who’s doing battle against it for the first time.
It sounds like you’re only planning on using the mobile version of your app (where CORS is not a concern), so I realize it’s not much comfort
We have internally discussed providing such a proxy option for the test requests. It’d require actually proxying the requests through our (non-existing) CORS-friendly proxy server. No decision on it yet one way or the other, as there are a number of complications, but we hear that this is causing an issue for you. And if you’re developing for mobile only, it doesn’t make sense that you have to deal with CORS in Composer.
For actual recommendations:
(recommended) Set up a mock response to some sandbox server and run test queries against that. This way you get a real-looking response back, and can utilize the schema auto-detection etc. We’ve frequently used https://getsandbox.com/, but plenty of other options available as well.
Set up an actual proxy server where you can control the access-control headers, and point the requests there. Definitely overkill if you do not need any custom backend for anything else.
Set the response schema manually and trust that things just work™ in mobile without running the test requests. This can be an option if your response schema is trivial or doesn’t matter, as you can probably easily manually verify if the resource is working correctly through the preview app.
Thank you so much for this detailed information, @Pekka_Aaltonen! We’ll figure out the best path forward for now.
@Erin_Wagner any update on connecting AppGyver to Zapier?
Curious if you ever managed to get it sorted!
What we realized was that my tests from within Composer were failing because they were sent from within a browser. However, they worked just fine when using the app–both in the AppGyver previewer and when we built the file.
Moral of the story: If your users are on the web app, you’ll need to find a workaround like having a simple endpoint on your own server that redirects the data to its final destination.
But if your users are only ever on iOS or Android apps, then it can work just fine. Just be sure to test it within the previewer app since you can’t within the data source configuration.
Sending good vibes for your project, @William_Glass!
Another temporary workaround is to use during testing in browser this page:
Be aware though that I don’t know who is hosting this page or any listening on the data, but it might be helpful to verify non-sensitive request.
Thanks Erin! We are sticking to iOS & Android for now so this works great.
Thanks for confirming it works. I’ll let you know how connecting directly to Zapier goes for us!