To send a nested JSON array, use the Custom Request action. That will allow more flexibility for the payload.
This error means the domain lookup for your URL failed. If the URL seems okay, check for extra spaces before or after the URL in your webhook settings. Remove the space and you should be good to go!
For High Availability and High Throughput reasons - we always return a success message with a payload of debugging information when collecting a webhook - regardless of whether there is a Zap behind the webhook or if it is paused or not. The only way to know if a URL is live is to visit the editor and look at the URL (which never changes for a Zap). There is no way to customize the response to the request you send to the Catch Hook URL, as the response is sent before the Zap triggers and runs on the webhook request.
We cannot 301 or 302 you to a different URL and deliver/retrieve payloads from the new address. Doing so will result in a failure!
The maximum webhook size we currently support for triggers is 10MB. Any payloads that exceed this limit with receive a
413 status code.
This is very common if you have a firewall in place to limit access to your local intranet or company network. Open up your instance to the wider internet to give Zapier and similar services access to your server. Be sure to use good passwords if you can!
Chances are there are a few reasons why you might be running into an SSL certificate failure:
- Using a self-signed certificate. We currently only support SSL certificates issued by public certificate authorities. A free SSL certificate can be obtained from letsencrypt.org. Let’s Encrypt is a free, automated, and open certificate authority provided by the non-profit Internet Security Research Group (ISRG).
- Incorrect usage of a
example.comcertificate on a domain like
testing.example.com. The reverse can be the case as well, for example: a
*.example.comwildcard certificate for
- Other improper installation of the certificate (missing chain certificates, improper modes, etc). Use a tool like https://www.ssllabs.com/ssltest/ to test.
Unfortunately, not all apps can send back data in a way that our system can interpret in subsequent steps.
Specifically, the error:
Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.
This happens when trying to send data to the Zapier webhooks from inside a web browser and altering the Content-Type header during the process. Because of Cross Browser Security restrictions, your browser will reject these requests. To combat this, do not set a custom
Content-Type header in the request.
This means we can't get a reliable IP for the domain. Even though you may be able to access the URL via the browser or an API client, it may still fail our requirements. When it does, this often means there are issues with the DNS configuration for the domain. You can run it through http://dnscheck.pingdom.com/ to find them.
If the webhook response data is an array of objects, that will run the subsequent steps in your Zap multiple times — once for each object in the array. If this isn't what you're looking to do, you'll need to check the documentation for the API you're connecting to and see if there's a way to limit the number of objects returned in the response to just one (e.g. a
limit parameter). If that isn't possible, take a look at building a custom integration using our Developer Platform which will give you full control over the data received from webhook requests and how it is handled in your Zaps.
If the Zap receives an invalid payload, it will be ignored and the Zap won't trigger. If you have a payload that didn't trigger the Zap, make sure to check if it is valid. The Zap will still respond with a Success status.
In Team and Company accounts, if the owner of the Zap changes, the webhook URL of the Catch Hook trigger will change. You must update it in the app that sends the webhook.