The HTTP 403 Forbidden error means that a client (in our case the server/service/website who sends the webhook action) is forbidden from accessing a webhook action URL
An example:
Let’s assume you’re using the create_user action on a different server (Server A) to create a user on Server B. While sending the request from Server A, Server B returns an error message with the HTTP code 403 and the request failed.
While the reasons for the error can be versatile, they are mostly related to either a proxy, firewall, or a security plugin that blocks the request due to some problems with the request that makes the server believe the request is not “legit”.
Below we summarized some of the errors that other users of WP Webhooks faced in regards to the error code 403:
1. If you’re using the CleanTalk plugin
Sometimes, the CleanTalk plugin might identify specific requests as spam (depending on the data you send along with it).
To solve this problem, please refer to this manual.
2. If you’re using the iThemes Security plugin
The iTheme Security plugin comes along with the “Default ban list” feature (located in Configure > Lockouts > Ban Users), which can cause requests to be blocked if no valid “User-Agent” header was set with your request from Site A.
This specific feature adds various code lines to your .htaccess file, including the line RewriteRule ^.* - [F,L], which can cause your requests to be blocked if no “User-Agent” was defined.
To make this work, please set the “User-Agent” within the header. An example value would be something like this: User-Agent: Site A/1.0.0
3. Your website is protected by an extra authentication layer
If you are using an extra authentication layer to protect your website with a username and password, internal requests for Flows will fail (by default). To make it work, you must add authentication to internal requests. We have written a blog post that is available here: https://wp-webhooks.com/docs/knowledge-base/workflow-automations-fails-with-website-authentication-basic-auth/