Supported integration boundaries

The integration surfaces have different jobs#

Choose one surface for each requirement before writing code. A public relevance hint, a private fact, a live lookup and a business outcome differ in their authority and lifecycle; one credential does not safely cover all of them.

Use the official browser contract#

The current public browser object provides setContext() and clearContext(), plus the reesponder:ready event. There is no documented stock-widget method for opening the panel, resetting a conversation, setting verified identity, extracting the transcript, injecting custom UI or receiving a conversation-ID callback.

The widget's closed Shadow DOM deliberately isolates its implementation. Private class names, internal requests and browser-storage keys are not an extension layer. Documented storage information explains behavior; it is not permission to treat a token extracted from storage as a customer account credential.

The ready event announces the existence of the context hooks, not the completion of network detection. Keep successful loading, valid installation and a completed first answer as separate milestones in your implementation notes.

Server integration is not a browser secret#

Trusted context and journey events use a private website context credential. Your backend must authenticate its own customer or business event, preserve the correct site/conversation association and apply the allowed field/event definitions. A browser snippet cannot safely hold that credential.

Where a lifecycle hook or credential-issuance control is missing from the current portal, commission the integration with Reesponder. Do not invent a token, reuse a workspace session cookie in server code or assume an arbitrary management route is stable for third-party automation.

Specify the customer or event source and the public conversation mapping before enabling data transport. A missing mapping should fail closed rather than be guessed from a raw request captured in browser developer tools.

Action providers are your application's boundary#

An HTTP Action calls the HTTPS endpoint you configure, with inputs, a verified customer email when required, and an idempotency key. Your endpoint must implement its own business authorization, ownership checks and safe retry behavior. Reesponder's mapping limits what results are shown to the visitor; it cannot repair an endpoint that discloses another customer's records.

Write Actions require the available plan, a tested configuration and explicit visitor confirmation. Private reads require their configured identity verification. Read and write providers should be designed separately even when they use the same external service.

A field mapped out of an unsafe provider response can still reveal private data. Mapping is a display boundary, not a replacement for provider-side ownership checks. Test an unrelated identity at the destination.

Avoid undocumented automation#

The workspace's authenticated routes manage billing, members, websites, Knowledge and configuration. These docs do not present them as an open account-management API or provide a general API-key scheme for every route.

If you need bulk management, a custom frontend, a signed identity bridge or a stable webhook contract not described here, contact Reesponder with the intended flow first. The resulting integration should define authentication, authorization, lifecycle events, retry behavior and failure states before it is connected to real customer data.

Browser devtools make requests visible; visibility is not a promise of external API stability. Use the request reference for diagnosis, and keep management automation inside an explicitly agreed contract.

Worked architecture: public products and private order status#

The page uses the official domain-bound snippet and may provide a public product-category hint through commissioned context definitions. Public product and policy answers come from reviewed Knowledge. A customer requesting private order status triggers a configured read Action that collects the order reference and verifies the customer’s email when required.

The provider endpoint authenticates the service credential and checks that the verified email owns the requested record. It returns only the mapped status and customer-safe reference. The browser category hint is not used as permission, and the provider secret is never sent into page source. A later requested change uses a separate write Action and explicit confirmation on a plan that supports it.

This architecture is narrow and reviewable. It does not turn the assistant into a general proxy for arbitrary URLs or headers. If a business needs authenticated context or outcome attribution tied to that conversation, the mapping and server credential lifecycle must be commissioned separately rather than inferred from the storefront installation.

Review a boundary checklist before release#

List every public value, private credential, authenticated session and customer-controlled input. Identify where each is validated and which system owns the underlying record. Test an unrelated customer, an invalid credential, a wrong website and missing lifecycle data. Success-path testing alone is not enough for a private integration.

For writes, exercise the exact confirmation and the destination’s duplicate protection. For browser context, verify first-bootstrap timing and ignored definitions. For server context, verify the 204 response and the site/conversation association. For journey events, use a trusted business event rather than a button click as proof of purchase or booking.

Document unsupported requirements and contact Reesponder before depending on them. The current stock widget has no general public open, reset, setIdentity, transcript-extraction or conversation-ID callback API. Do not leave a production dependency on private markup merely because it works in one browser test today.

Write a short integration specification#

A useful specification names the task, website, data source, authentication, authorization, public conversation mapping, input limits, result fields, retry behavior and privacy purpose. For a read task, include the rule deciding which customer may see which record. For a write, include the exact customer confirmation and how the destination deduplicates a run reference.

Give every credential one role. The installation credential verifies a public website load. The trusted-context credential authorizes a commissioned backend attachment. The Action provider credential authenticates a call to your business endpoint. The customer’s application session proves what your own backend can establish. Reusing one value across these boundaries makes access harder to reason about.

Specify what happens when a prerequisite is missing: no mapping, missing definition, unavailable provider, stale identity or unknown external write outcome. The safe result is often a clear limitation or a request for the customer to use the business’s contact route, not a fabricated success. Keep examples synthetic and do not turn them into operational credentials.

Review changes at the boundary they affect#

A new public hostname affects installation authorization and route coverage. A new context field affects schema, timing and processing. A new provider endpoint affects credentials, ownership, network checks and result mapping. A new write operation affects confirmation, destination rules and idempotency. Avoid treating all of these as one generic configuration change.

When an Action configuration changes, it becomes a draft and needs a successful test of its current revision before enabling. When a manual installation credential changes, all deployed tags need its current value. When a context credential changes, the commissioned backend needs the replacement. Each rollout has a different verification sequence.

Keep a release record that identifies the boundary changed and the affected tests. This is more useful than a screenshot saying the feature appears to work. If a requirement crosses into an unsupported surface, define the contract first. A product finishing change should not quietly introduce a custom unofficial SDK, a broad proxy or client-side private credentials.