Skip to main content

WAF and Security Plugin Settings

If your website uses a Web Application Firewall (WAF), a WordPress security plugin, or security provided by your hosting company, ensure that Slynk can access your WordPress API and that API responses are not cached.

These settings help prevent connection checks and product, stock, and order syncs from being blocked or receiving outdated data. You can send this guide to your website developer or hosting provider if they manage these settings for you.

If you use Cloudflare, follow our Cloudflare Settings guide.

Allow Slynk through your firewall​

In your firewall or security plugin, look for settings such as Allowlist, Exceptions, Custom rules, or Trusted requests. The names and available options depend on the provider.

  1. Create an exception for requests where the User-Agent contains Slynk. Slynk requests use the User-Agent Slynk/1.0.
  2. Also allow request-header conditions to match requests where the Origin header contains slynk.io. Use this as an alternative match, not a requirement alongside the User-Agent, as not every request includes an Origin header.
  3. Configure the exception to allow matching API requests through the rules that block or challenge them. Check WAF rules, User-Agent blocking, and rate limits.
  4. If your provider evaluates rules in order, place the exception before rules that could block the requests. Check whether any other security controls still apply after the exception.

If your provider only supports IP allowlisting, contact Slynk support for the current connection details before adding a rule.

Prevent API caching​

Check each caching layer, including caching plugins, hosting caches, and any CDN or proxy in front of your website.

  1. Add a Do not cache or Bypass cache rule for the WordPress REST API: the /wp-json path and all paths beneath /wp-json/.
  2. If your site uses REST API URLs with a rest_route query parameter, exclude those requests from caching too.
  3. Place these exclusions before any broader cache rules, where rule order applies.
  4. Clear any existing cached API responses after saving the changes.

WooCommerce API endpoints sit beneath the WordPress REST API path, for example /wp-json/wc/v3/. See the WooCommerce REST API documentation for examples.

Check bot protection and challenges​

Slynk sends automated API requests. These requests cannot complete CAPTCHA checks, JavaScript challenges, or browser verification screens.

Ensure that bot protection allows Slynk API requests without a challenge. Some providers apply bot protection separately from custom firewall rules, so a firewall exception alone may not be enough.

If your current plan or plugin cannot apply an exception to bot protection, ask your provider how to allow the integration. Prefer an exception for the required API traffic over disabling protection across the whole website.

Also check whether your security plugin disables or restricts the WordPress REST API. It must allow authenticated access to the endpoints used by Slynk.

Verify the settings​

After saving the changes:

  1. Retry the connection or plugin check in Slynk. During onboarding, click Check again.
  2. Confirm that the connection check succeeds and that subsequent syncs complete.
  3. If requests still fail, check your firewall or security plugin logs at the time of the retry. Look for blocked requests, browser challenges, or rate limits affecting Slynk.

If you need help, send Slynk support your store URL, the name of your security provider or plugin, the time of the failed check (including your time zone), and any relevant error or blocked-request details. Remove API keys, passwords, and other credentials before sharing logs or screenshots.