How to connect to WooCommerce

This guide covers connectivity troubleshooting for the WooCommerce connection. For credentials, add your store's Shop Domain, Admin URL, Consumer Key, and Consumer Secret in Vault.

Troubleshooting: no data returned

If your WooCommerce connection shows as connected in Vault but list calls (e.g. products, orders) return no data — or fail intermittently with 403, 400, or 401 — the request is most likely being blocked by a security layer in front of your store, before it reaches WooCommerce. This is not an Apideck or credentials problem: WooCommerce stores are self-hosted, so the block usually comes from a WordPress security plugin (Wordfence, Sucuri, iThemes Security, Cerber, Shield), Apache mod_security, or Cloudflare sitting in front of the store.

How to recognize an edge block

• The error body is HTML or plain text, not WooCommerce's usual JSON error. WooCommerce returns JSON for real API errors (e.g. {"code":"woocommerce_rest_cannot_view", ...}). An HTML page means the request never reached WooCommerce.
• The response headers name an edge layer, not WordPress:
  • server: cloudflare with a cf-ray id → blocked at Cloudflare.
  • server: Apache with a body mentioning "…encountered while trying to use an ErrorDocument…" → blocked by Apache mod_security or a security plugin.
• A direct call from your own machine to the same URL (e.g. https://yourstore.com/wp-json/wc/v3/products?page=1&per_page=100) returns the same block — confirming it happens at your store's edge, independent of Apideck.

How to fix it

1. Allowlist Apideck's static egress IPs on your firewall / security plugin / Cloudflare, or add a "skip / allow" rule scoped to the WooCommerce REST path /wp-json/wc/v3/*. Apideck's EU (eu-central-1) egress IPs are:

   • 18.197.244.247
   • 18.156.9.3
   • 3.65.139.215

   These are Apideck's current EU (eu-central-1) egress IPs; support for other regions is upcoming. If you need to confirm the latest list for your region, contact Apideck Support.

2. Check which rule fired. In Cloudflare, open Security → Events and search for the cf-ray value from the error — it names the exact rule that blocked the request, so you can tune it precisely.

Important: allowlisting IPs is not always enough

On Cloudflare, several protections still block an allowlisted IP. If requests are still blocked after allowlisting, check these:

• Bot Fight Mode — cannot be bypassed by IP rules or a WAF skip; turn it off or scope it away from /wp-json/*.
• Browser Integrity Check — blocks non-browser clients by User-Agent; disable it for /wp-json/* via Configuration Rules.
• Managed / custom WAF rules on /wp-json/*.
• JA3/JA4 TLS fingerprinting and rate limiting.

If Cloudflare looks clean, check the origin: Apache mod_security, .htaccess, or a WordPress security plugin (Wordfence and similar).

Why the connection still shows "connected"

Apideck relays your store's error exactly as received. A 403 is not retried automatically and does not mark the connection as disconnected — so the connection stays healthy while individual data calls fail. Because these WAF / rate-limit / IP-reputation blocks are often transient, retrying a little later frequently succeeds. To stop them recurring, apply the allowlist / rule changes above.