Troubleshooting / FAQ

The <style id="..."> tag (a random id, unique to your stream) hides your page instantly so there's zero flash while the check runs — a brief blank/hidden state right after page load is expected, not a bug. It always self-resolves one of three ways:

• The check completes normally and the page reveals (real-world measured range: under a second up to several seconds, worst case around 8–9 seconds on an uncached IP lookup).
• The script fails to load in a way the browser can detect (404, DNS failure) — an onerror handler on the script tag removes the hide immediately.
• Neither of the above happens (an ad blocker silently aborts the request without firing an error event, or the request simply hangs) — a 10-second timer is the last-resort failsafe that always removes the hide regardless.

With Money Page Delivery set to proxy (the default), the server fetches your destination's HTML and serves it directly at your own URL. A destination built as a JavaScript-framework single-page app (Next.js, Nuxt, Angular, React) tries to take control of the browser's address bar itself the moment it starts up — which crashes with a SecurityError when the page is actually running at a different domain.

The server-side integrations (PHP snippet, WordPress plugin) already detect this automatically by scanning the fetched HTML for common framework build markers (__NEXT_DATA__, _next/static/, __NUXT__, ng-version=, data-reactroot) and fall back to a real client-side navigation instead of proxying the raw HTML whenever one is found.

This notice appears whenever the plugin's Stream ID or Cloaking X API URL is empty (or still the literal placeholder from a hand-copied file instead of a real download).

Fix: WordPress admin → Cloaking X → Settings → fill in your Stream ID and API URL. If they still show as "NOT SET" on the plugin's Status page after that, re-download the plugin from your dashboard's Integration page (WordPress tab) — that download bakes your real values into the file. The API Key field is optional and only needed for the stats dashboard inside WordPress; filtering itself works without it.

Common causes, in order of likelihood:

• The X-API-Key header wasn't sent at all, or was sent under a different header name.
• The key was copied incompletely — a valid key matches either ak_ followed by 48 hex characters (current format) or a bare 64 hex character string (legacy format, still accepted).
• The key's owning account has been deactivated.

Fix: in your dashboard, go to Integration and check the API Key section — click Show to confirm the full value, or Regenerate Key if you're not sure you have the right one anymore (this invalidates the old key immediately).

Several stream settings intentionally skip logging entirely — a click can happen and even redirect a real visitor without ever producing a Reports row:

• Mode is "off" — every visitor is sent straight to the destination page; the stream's click counter still increments, but no Reports row is written at all.
• Require Click ID is on and the visitor has no click ID from a recognized ad platform (gclid/fbclid/ttclid/msclkid/etc. — see Stream Settings) — the check returns immediately with no log and no click-count increment.
• The stream is paused (or the account is disabled) — visitors pass through silently, with no log.
• Your plan's click limit was reached — traffic past the limit is sent to the fallback page without being logged.

Beyond stream configuration, also check:

• The snippet is actually installed and pointing at the right Stream ID.
• For server-side integrations (WordPress, PHP), that your server can actually reach the Cloaking X API — firewall rules and outdated SSL certificates on some hosts block outbound requests.
• You're not testing so rapidly from one IP that you're hitting the check endpoint's own rate limit (60 requests per IP per minute), which also returns silently with no log.

Under proxy delivery, the server injects a <base href="..."> tag pointing at the destination's real origin so relative CSS/JS/image paths still resolve correctly when the HTML is served from your own domain. This only fixes relative paths — a destination that hardcodes absolute asset URLs behind hotlink protection, or that has CORS rules tied specifically to its real domain, can still fail to load some assets when served from a different origin this way.