Install on Shopify

Prepare the website in Reesponder#

In Reesponder, open Websites → Connect a domain, enter a Website name and the public Domain, then select Start automatic setup. Use the final hostname customers see after redirects, not an administrator URL, preview host or product-page path. The setup queues public-page Knowledge preparation.

Open that website's Installation view. When Shopify is detected, it provides the storefront-specific instructions and store theme links. You need permission to edit the published theme and active workspace access. Core includes one website; Business and Scale allow multiple within workspace capacity. Crawl preparation and installation detection can proceed separately; neither authorizes private order data.

Paste into the current theme#

1. Choose Generate & copy code, or copy the current complete code already displayed.
2. Open Shopify Online Store → Themes.
3. On Current theme, choose … → Edit code.
4. Open layout/theme.liquid and locate the closing </body>.
5. Add the tag on a new line immediately before it, preserving the existing markup, then Save.

Add one tag to the shared layout rather than one per product. If clipboard access fails, select the code field manually; that is not a reason to issue another token. The installation guide's placeholders cannot be used on a live store. Use the code generated for this website.

See Shopify's theme-code instructions for its editor. Theme updates can remove manual changes, so record the installation location and review it during theme releases.

Verify on the public storefront#

Open the registered public storefront, unlock any storefront password and reload. Check the launcher, then return to Reesponder and use Refresh detection status; the portal also updates while installation is pending. Confirm that Last seen advances after this visit rather than relying on an older green label.

Ask a safe question grounded in reviewed store Knowledge. The greeting and detection establish installation; the first question exercises bootstrap and answering. If detection remains pending, inspect the published layout and actual delivered tag, then browser blocking and hostname alignment before replacing credentials. The delivered-code section below gives a layered diagnosis.

Theme coverage and limitations#

The snippet covers public pages using the edited layout. Identify custom layouts and give each intended document shell the existing current tag once. Test direct entry to a product and policy page, not only navigation from the homepage. After switching themes, verify the newly published layout.

A headless storefront has its own frontend shell; editing a Shopify theme does not modify it. Checkout and new customer-account pages use separate systems and are not covered by this theme installation. Keep those surfaces outside a completion claim unless a specific supported integration has been agreed.

Existing app embeds and private Actions#

If Installation shows an existing Reesponder app connection, follow its embed guidance instead of adding a manual tag. To switch to manual setup, uninstall that app first and refresh the website view. The standard current theme-snippet path does not require an app merely to display chat; app-connection code does not imply universal app availability.

Private order lookup needs separately authorized store access and verified customer ownership. A theme snippet grants no Shopify Admin API permissions. Follow the actual authorized connection or a merchant-controlled HTTP adapter for that task. The illustrated Shopify guide shows the corresponding storefront setup.

Worked example: publish a new theme without losing support#

A store’s designer prepares a new theme while the old published theme continues serving customers. Copy the existing valid snippet into the new theme’s shared layout before the new theme is published. Keep its current site ID and token. A visual redesign does not require a new token. Once the theme is live, open the final public domain, check a product and a policy page, and confirm a fresh detection time.

If a replacement token was deliberately generated, the old tag is no longer valid. Update every layout containing it and remove duplicate copies. A rollback to the old theme must use the current credential too; reverting theme files does not reverse token revocation. Keep the installation location in your theme-release notes so a later designer can identify it without generating another credential.

Acceptance checklist for a Shopify storefront#

Confirm that the current published theme includes one unchanged loader, the public hostname matches the website workspace, a fresh installation check succeeds, and a representative source-backed question works on desktop and mobile. Check direct entry to a product, a policy and any custom layout you intend to support. Verify that the phone keyboard, close control and important storefront controls remain usable.

Review private order lookups separately if they are configured. Test a known owner and a mismatching identity; the latter must not reveal another person’s data. Record whether the store uses the manual theme snippet or an existing app embed, and who can publish changes. Do not mark checkout, new customer accounts, private data access or automatic return approval as completed by the theme installation.

Inspect the delivered code when the launcher is missing#

Begin with the public page that is failing, not the theme editor. Open its delivered HTML or browser Network panel and search for reesponder.js. If the tag is absent, you may have edited an unpublished theme, a layout the page does not use or the wrong store. Check the selected Shopify store and its Current theme before changing credentials.

If the tag exists, confirm that its data-site-id and data-installation-token were preserved and that the CDN script loaded. A browser blocker or security policy can stop the download or API request. Look next for the installation-detection request to https://api.reesponder.com. A safe rejection code can distinguish a domain/token mismatch from script delivery failure. Do not share an unredacted payload.

Unlock a password-protected storefront before testing its public pages. A theme preview hostname is not equivalent to the registered production domain. If the browser shows a different final hostname, solve that domain alignment first; token rotation does not authorize a new host.

Copying failures do not require new credentials#

The Shopify installation view offers a selectable read-only code field. If the browser refuses clipboard access, select the full script tag and copy it manually. Do not repeatedly click generation as a way to fix clipboard permissions: a newly issued credential invalidates the old one and creates extra deployment work.

Use a complete current tag and place it once in the shared layout. Avoid smart quotes from a rich-text document or an editor that turns the code into visible page text. The CDN URL, data attributes and defer attribute should remain as generated. Keep the code inside the document, immediately before the closing body tag, without deleting other theme scripts.

After saving, compare the public HTML with the intended tag. If your editor still shows the correct current code but a visitor receives an older one, inspect the active theme and any delivery cache. Preserve the website identifier and credential pairing. Your workspace password and private provider secrets have no role in the storefront tag.

Prepare useful storefront Knowledge#

The automatic crawl prepares public website information, but review the result before promising useful support. Check that your product descriptions, delivery terms, return policy and business contact details are available and current. A password wall, missing policy page or incomplete product description can leave gaps even though the widget is installed correctly.

Use the website’s Knowledge view to inspect its sources and add necessary business information. Ask a question about the current product, a delivery policy and a request your business does not support. The answer should use available facts and acknowledge missing details. A dynamic stock level or private order status should come through a properly authorized live Action when that requirement exists.

Private test offers five questions using current Knowledge without consuming customer conversations. It is useful for content review but does not reproduce the public storefront path, authenticated customer facts or complete live Action flow. Finish with the visitor widget on the actual domain and follow normal usage rules for those live questions.

Keep a small release record for the next theme change#

Record the final public domain, published theme, shared layout location, installation method and time of the successful visitor test. Note any custom layouts that need their own inclusion and any deliberately excluded surfaces. Store this alongside your theme deployment notes so it remains available when staff or agencies change.

Give the person publishing the next theme a concrete acceptance task: open the public product and policy routes after release, confirm detection and ask the known safe test question. If an app embed owns the installation, that ownership should be explicit. If a manual snippet owns it, identify the exact layout rather than saying only “the chat is installed somewhere”.

When contacting support, provide the public host, platform, affected route, approximate time and safe request status. Hide raw installation values and customer information. These details let the team distinguish a theme delivery problem from a domain authorization problem without asking you to expose unrelated store credentials.