Domains and installation credentials

The public site ID and installation credential have different jobs#

The script tag contains two values that must belong to the same website. data-site-id identifies the public website record. data-installation-token is the current credential for verifying that installation. Neither is your account password, an Action provider token or a private server context credential. Copy the complete code produced by the website’s Installation view; do not combine the identifier from one website with a token generated for another.

These installation values are delivered in public page HTML. The service stores the credential as a hash and checks it with the browser request’s hostname. Public visibility therefore does not grant permission to administer the workspace or to use the installation on any domain. Keep credentials for server integrations in your backend and redact installation values in support screenshots even though visitors can inspect their own page.

Use the actual visitor domain#

Use the hostname customers see after normal redirects. example.com, www.example.com and preview.example.com are distinct hosts. The service accepts the website's canonical hostname or an explicitly registered and verified additional domain, not arbitrary subdomains or similarly named addresses. There is no general alias editor covered by this guide; arrange additional public hosts with support.

Use the public HTTPS domain for acceptance testing. The normal website setup does not accept an IP address, port or page path as the hostname.

Replacement code revokes the previous code#

Generate replacement code only when you intend to invalidate the previous manual credential. Prepare every active template and cache location first, copy the complete new tag and publish it once in each intended document shell. Restoring an old template does not restore its revoked token; a rollback must still use the current credential.

The workspace asks for confirmation when replacing a verified installation. The backend preserves historical Widget detected and Last seen values during replacement, so a green label alone does not prove the new tag works. Visit the public domain and confirm that Last seen advances after the change. Saving Appearance or refreshing detection does not rotate the token.

Respect platform-owned installations#

An active WordPress plugin or existing Shopify app connection owns its installation credential and prevents normal manual issuance. Repair the connection through its supported platform flow rather than adding a separately generated tag. When switching methods, disconnect or uninstall the platform-owned installation before generating manual code.

Choose one installation owner. A forgotten manual tag can execute before the platform's loader; the single-widget guard does not choose which credential you intended. Locate competing tags in the delivered public HTML, remove the obsolete installation and verify a fresh load through the chosen owner. Private order access remains a separately authorized Action connection.

Changing or removing the website#

A domain move needs a supported website configuration and verification from the new public host. Editing a site ID or token in HTML cannot authorize it. The WordPress plugin checks its connected hostname before rendering; reconnect for the correct new domain. Plan the change with support when the intended domain configuration is unclear.

Removing a website revokes its installation, context and private-test credentials and removes website-specific Knowledge. Shared Knowledge, recorded usage and billing remain; conversations follow retention rules. Remove obsolete frontend code too. Adding the domain again creates a fresh website identity and credentials rather than reactivating a retained old snippet.

Worked example: a shop with a www redirect#

Suppose customers enter example.com, but the website redirects them to www.example.com before showing its pages. Register and test the hostname visible after that redirect. The browser’s address bar and the origin of its installation request determine the relevant host; the domain a person typed first is not enough. A saved theme preview at preview.example.com is a third hostname and should not be treated as production proof.

Before release, open a product URL and a policy URL from a clean browser profile. Let normal redirects finish. Check that the final hostname is consistent, the current loader is present and the website’s Last seen time advances. If multiple public hosts intentionally serve the same site, discuss the required domain configuration with Reesponder rather than assuming wildcard authorization. There is no general alias-management editor described by this guide.

Evidence to keep after a domain change#

Record the website name, final HTTPS hostname, installation method, template or plugin location, time of the test and fresh detection result. Check a second route and a mobile browser. Keep the source code location in your deployment notes so a future theme or frontend change does not silently remove the widget. You do not need to store the raw token in a support ticket.

A useful completion record says that a current snippet loaded from the intended domain, a new installation check succeeded, and a representative customer question received the expected answer. An old green status without a fresh visit does not establish all three facts. If the public hostname changed, stop using cached HTML with the old snippet until the new configuration has been checked. Verify any separately connected private Action again because authorization of a storefront and authorization of its business data are separate boundaries.

Diagnose a rejected installation without rotating it#

Use browser Network tools to separate delivery from authorization. A successful reesponder.js download establishes that the loader reached the browser. It does not establish that the service accepted the website credential. Look next for POST /v1/widget/installations/detect to https://api.reesponder.com. A 403 with installation_not_allowed points to the combination of public site ID, current credential and origin hostname. Compare the final browser host with the website workspace before changing anything.

A 400 with invalid_widget_request indicates an invalid request shape or unsuitable origin. A browser policy error may mean that no valid request reached the service at all. Inspect the safe status and error code; do not copy the complete request payload into chat. If the script was combined or rewritten by an optimizer, verify that its two data attributes survived. A token replacement will not fix a CSP block or a host that was never authorized.

Contact support with the domain, installation method, approximate test time, route and safe error code when those checks do not resolve the problem. This evidence is much more useful than repeated new tokens.

Hand over an installation without exposing unrelated secrets#

A developer maintaining your website needs the current installation snippet and the location where it belongs. They do not need your workspace password, a WooCommerce consumer secret or a trusted-context credential merely to add the chat launcher. Share the snippet through your ordinary controlled deployment process and identify whether a theme, plugin or application layout owns it.

In a handover, name who may generate replacements, who can publish the template and who can purge the cache. Replacement and publishing should be coordinated because every existing snippet using the old credential becomes stale. Keep a rollback plan for the template, but remember that restoring an old HTML file does not restore an old credential that has already been revoked. A rollback must use the current valid snippet.

If a screenshot is needed, hide the raw token and private account details. Public site IDs are useful identifiers for support, but they are not enough to authorize a change. Reesponder still requires the authenticated workspace owner or administrator for management operations.