Workspace and website data boundaries

Workspace scope is enforced by the service#

Use workspace names and membership when configuring an integration, not an identifier copied from a different account. A person who belongs to more than one workspace should confirm which one is selected before adding Knowledge or an Action. Owner/admin management privileges and ordinary member access are separate controls; giving a colleague a link does not change their role. When staff leave, remove their access using the team workflow. For support, a safe website or workspace reference can help locate the issue, but no public ID should be treated as authentication. Your endpoint should similarly authorise the intended operation rather than trust arbitrary row IDs.

Conversation requests remain domain and tab bound#

The public installation credential is expected to be visible in page markup, so its security role is intentionally narrower than a workspace login. The service combines it with domain binding, and conversation requests additionally rely on tab and conversation association. Copying the script from another site is not a valid way to claim its workspace or access its records. Changing a theme preview's hostname can therefore expose a genuine origin boundary, not a nuisance to suppress. Keep server credentials out of theme code, public repositories, browser variables and replay tools. If a private integration needs authentication, implement that in the server-to-server path.

Configure Knowledge for the intended audience#

Classify a source before uploading it. Public product specifications and policies can support visitor answers. Internal answering guidance can instruct the assistant how to handle a task, but the source is still processed by the support pipeline. It is not a sealed password vault. A shared workspace source may be available across the websites that use shared Knowledge, so keep site-specific offers in the appropriate scope and avoid private customer lists. Test the questions most likely to confuse two brands or stores: opening hours, delivery regions and support contacts. A successful crawl is not a substitute for reviewing what the captured pages actually contain.

Trust describes origin, not blanket permission#

The stock widget exposes window.Reesponder.setContext() and clearContext(), with the reesponder:ready event for availability. It has no supported setIdentity() or signed-shopper JWT shortcut.

Only send values your support flow needs. A locale, product identifier or verified account attribute can be useful; an entire session object containing credentials is not. Browser-supplied context is editable by the visitor even when the UI does not show an input for it. Trusted backend context requires your backend to establish the customer's relationship to the supplied values. It is treated as data, not instructions. The current stock widget sends browser context at first bootstrap, so changing an in-memory value later does not automatically replace the already attached server context. Do not invent a public identity callback to work around that lifecycle.

Define safe connected-system boundaries#

Return a deliberately small contract from an Action endpoint. For an order-status read, that may include a customer-safe status and delivery estimate, not a raw order object with staff notes, billing information and fraud indicators. Result mapping supports selected scalar fields; missing or non-scalar values are not a reason to expose the original object in a free-text field. Check the actual result card with two customers whose records differ. For writes, implement provider-side idempotency for safe repeated delivery of the same operation key. Reesponder's local protection cannot prove that an external service treats a separately retried business operation safely.

Use precise security language#

Write technical handover notes with the actual boundary in view. A hashed opaque token means its verification record is stored as a hash; it does not mean all conversation data is encrypted in the same way. Encrypted provider credentials are a different storage mechanism. Prompt boundaries reduce the risk of treating a document or visitor claim as a governing instruction, but business authorisation still belongs in the provider endpoint. Use the current Data Processing Agreement for processor responsibilities and ask through the appropriate private route about any processing arrangement your organisation needs to review before onboarding sensitive records.

Inventory fields before passing them into support#

For every context field, write its purpose, source, trust level, website scope and expected value type. A product reference may come from the visible catalogue page; a customer account attribute may require your backend to establish the signed-in relationship. Do not copy an entire application state object because one field is useful. Review nested data, tokens, session credentials, internal notes and unnecessary contact details before building a smaller support contract. A public field definition does not prevent a careless frontend from collecting more data elsewhere.

Apply the same inventory to Knowledge and Action outputs. Knowledge should contain business answering material for its intended audience. An Action result should be an allowlist of fields the current customer may receive. Give each contract a maintenance owner and expected fallback when a value is missing. If a field is renamed or removed, test the actual question and result card instead of merely checking that the server returns HTTP success. This inventory turns an abstract claim that an integration is safe into a concrete list of values, purposes and boundaries that a reviewer can assess without reading private production records.

Review scope when a business or website changes#

A domain migration, second brand or provider-account change can alter several boundaries at once. Begin with the final public hostname and correct workspace, then review site-specific Knowledge, shared sources, context definitions and Action connections. A retail policy copied into wholesale support may produce a wrong answer even without a technical authorisation failure. A provider secret retained from the old business account can address the wrong record set. The launch checklist should therefore follow the whole customer journey through its sources and connected systems.

Test the new site using safe records and also test an intentionally wrong scope. Confirm which sources should be shared and which remain specific to one website. Retire old publishing templates and credentials through their supported controls instead of merely hiding a navigation link. Record the provider account and endpoint owner without storing the secret in the handover notes. If a change affects an enabled Action's schema or result mapping, use the current test and activation process for that revision. A previously green connection indicator is evidence of an earlier configuration, not permanent acceptance of every later business scope.

Inspect data flow without copying credentials into tickets#

Use synthetic input to observe a complete support flow. Browser inspection can establish the site, path, request stage and permitted context; the endpoint's authorised test can establish its ownership decision and narrowed result. Keep private server credentials out of the browser altogether. If the script includes a public site ID and installation token, identify them as installation material rather than claiming the page has leaked a workspace password. Never include real account cookies, tab tokens or bearer links in a public issue just to show the request succeeded.

Share the minimal reproducible information: route with private query values redacted, approximate time, safe run reference, expected result and observed status. A complete HAR can contain authentication headers and unrelated personal requests, so review and redact it before any authorised support transfer. Check the result as the shopper sees it; a backend log showing a correct owner is not enough if the output mapping includes unnecessary private fields. Keep evidence in the appropriate access-controlled business record and remove diagnostic copies when they are no longer required. This inspection complements the integration controls without making debugging another route for exposing data.

Example: two websites and one private lookup#

Imagine a workspace containing a retail website and a wholesale website. Their public opening hours can be shared if identical, but a wholesale-only policy should not accidentally become the retail answer. Both sites can identify a visitor technically, yet an order read still needs a verified identity and provider ownership check. A support endpoint authenticated with a server secret should return only that customer's permitted order fields. Draw these boundaries in your integration specification before enabling the Action. Then test the wrong website and wrong customer explicitly, rather than testing only one successful lookup and assuming every other route is protected.

Verify the outcome and keep safe evidence#

Review a complete request and response using synthetic data. Confirm the intended workspace, website scope, source set, context trust and provider ownership decision. Check the mapped customer result, not just the endpoint's raw response. Search the published page and client bundle for private credentials; the domain-bound installation token is expected there, but account sessions and provider secrets are not. Review access when membership or endpoint ownership changes. A narrow test matrix should include a valid customer, a different customer, a different website, an expired conversation and a disabled Action. Keep redacted evidence so issues can be reproduced without copying sensitive data into public docs.