Skip to content

Troubleshooting

Check your public key. Open the browser console and look for:

[Receiveo] Widget loader failed { reason: "missing_public_key" ... }

This means window.receiveo.publicKey was not set before the loader script ran. Make sure the config script comes before the loader:

<!-- ✅ Correct: config first -->
<script>
window.receiveo = { publicKey: "pk_live_..." };
</script>
<script src=".../loader.js" async></script>

Check the network tab. The widget fetches settings from your API. If this request fails, look for:

[Receiveo] Widget loader failed { reason: "settings_fetch_non_ok", status: 403 }

A 403 usually means the public key is invalid or the workspace is inactive.


Check showBubbleOnLoad. If you (or another script) set window.receiveo.showBubbleOnLoad = false, the bubble starts hidden. Check with:

console.log(receiveo.api.isBubbleVisible); // false = hidden on purpose

If you see [Receiveo] Loader already initialized, skipping. in the console, the loader script is included more than once. This is safe — the second instance is silently ignored. Common with WordPress optimization plugins that duplicate scripts.

The API is only available after the loader script runs. If you’re running code immediately, wait for the widget:

// Use a small interval to wait for the API
const waitForReceiveo = setInterval(() => {
if (window.receiveo?.api) {
clearInterval(waitForReceiveo);
// Now it's safe to use the API
receiveo.api.on('ready', () => { /* ... */ });
}
}, 100);

On mobile devices, the chat window takes the full screen. If it appears to not open, check:

  1. Is a CSS z-index from your site covering it? The widget uses z-index: 9998.
  2. Does your site set overflow: hidden on the body? This shouldn’t affect iframes but some setups can interfere.

If your site uses a strict CSP, you need to allow:

  • frame-src — The domain where your widget is hosted
  • connect-src — Your API domain (for settings fetch and Socket.IO)