WooCommerce: calls fail with 403 because the store's firewall blocks Apideck

Symptom: the WooCommerce connection looks connected in Vault, but API calls fail with 403, sometimes 401 or 400, and sometimes only now and then. The provider's response in Logs is an HTML page or plain text instead of WooCommerce's JSON.

Cause: the store's security layer blocks Apideck's requests before they reach WooCommerce. Common sources are Cloudflare, the hosting provider's firewall (mod_security) or a WordPress security plugin such as Wordfence or Sucuri. A real WooCommerce error always looks like JSON, for example {"code": "woocommerce_rest_cannot_view", ...}, so an HTML response points to the firewall.

In the request's Logs, open the downstream (child) request and look at the response:

• headers server: cloudflare and a cf-ray ID → Cloudflare blocked it,

• an HTML "Forbidden" or "Access denied" page → the host's firewall or a security plugin.

The store owner (your customer) needs to let Apideck's requests through:

1. Allow Apideck's IP addresses: 18.197.244.247, 18.156.9.3 and 3.65.139.215. See Apideck's IP addresses.

2. Or skip the security rules for the WooCommerce API path /wp-json/wc/v3/*.

3. On Cloudflare, an IP allow rule alone often isn't enough. Also check Bot Fight Mode, Browser Integrity Check, managed WAF rules and rate limiting. In Cloudflare, Security → Events shows which rule fired; search for the cf-ray ID from the log.

• The store must use HTTPS.

• Permalinks must not be set to Plain (WordPress Settings → Permalinks). The WooCommerce REST API doesn't work with plain permalinks.

• The API key must have Read/Write permission and belong to an administrator, because Apideck reads the store's status and registers webhooks.

Contact Apideck support through the Customer Portal (the Requests link at the top of this help center), your Slack channel with us, or support@apideck.com with the request ID from Logs if calls still fail.