Customer-facing checks for widget, dashboard, API, notifications, and integrations.
Use these checks before changing your integration. Convor is hosted, so customer troubleshooting should focus on the browser, account, public API, and connected services.
Confirm the page contains one production embed copied from Settings → Widget → Installation and security:
<script
src="https://cdn.convor.io/widget.js"
data-key="convor_wpk_..."
async
></script>Then check:
data-key matches the public widget key for the selected site.Do not add API, iframe, or WebSocket addresses to the production embed as a troubleshooting step.
Reload the page and reproduce the problem in a clean browser profile. Use the browser Network and Console panels to check for blocked or failed Convor requests. Corporate networks and aggressive privacy tools can block persistent connections even when the initial script loads successfully.
If only one site is affected, compare its allowed-domain and widget settings with a working site. If several unrelated sites fail at the same time, check the Convor status information available from the product before editing every embed.
For Convor.identify() failures, verify all of the following:
visitorId from Convor.ready() to your
authenticated backend;visitorId, id, email, name,
phone, with empty strings for missing optional values;userHash is the 64-character hexadecimal HMAC-SHA256 digest.See Convor.identify(identity)
for the complete example.
Refresh the dashboard and sign in again if the session has expired. Confirm your account still belongs to the expected organization and that the correct site is selected. Try a clean browser profile to separate an account problem from a local browser problem.
If an action is unavailable rather than failing, check your role and current plan or module entitlements.
For server-to-server API requests:
| Status | Check first |
|---|---|
400 | Request body, path parameters, and documented field formats |
401 | API key is present, active, and sent using a supported authorization header |
402 | Required product module or entitlement is active |
403 | API-key scope, organization access, or resource permissions |
404 | Resource ID belongs to the current organization and still exists |
429 | Back off and respect the documented rate limit |
Record the response correlation ID when available. Never paste a complete API key into a support ticket or log.
Check the credential and URL in the connected service first. Make sure the credential has the permissions described by that integration guide and has not been revoked or rotated outside Convor. For webhook-based integrations, confirm the public callback URL is reachable over HTTPS and that the signing secret matches on both sides.
Use the integration's own delivery or audit log when available to distinguish a provider-side rejection from a Convor-side error.
Confirm the notification type is enabled for the affected operator and that the operator has access to the relevant site or conversation. For browser notifications, also check browser permission and operating-system notification settings. For email, check spam filtering and organization mail rules before changing Convor settings repeatedly.
Include the smallest reproducible case:
Redact API keys, identity secrets, webhook secrets, session tokens, and customer personal data.
Ostatnia aktualizacja: 10 sie 2026
Czy ta strona była pomocna?