Connect your systems without putting secrets in the browser.
Tenant-scoped service credentials let a merchant's server call versioned public APIs. Signed webhooks deliver allowed event data asynchronously to a configured receiver. The widget's public installation identifier is a different, non-secret value.
One conversation, across your stack.
A widget or mobile app starts the thread. Scoped APIs and signed events connect it to your services.
A developer can connect customer records, conversations and goals to existing workflows while keeping access scoped, revocable and auditable.
How it works.
Follow the implemented workflow from the first action to the next.
Create the right credential
An authorized owner/admin chooses explicit service scopes. The raw secret appears once; only a hash and safe prefix persist.
Call or subscribe
Use the secret from a server for permitted customer, conversation, message, tag, goal or bounded report routes. Subscribe a server endpoint to public-safe events.
Verify and operate
Validate webhook HMAC and timestamp, handle idempotent retries, inspect delivery logs and rotate or revoke credentials when needed.
Built around the work.
Least-privilege access
Service credentials are tenant-bound, have explicit scopes and cannot become an agent session or WebSocket ticket.
Reliable event delivery
Outbox-backed dispatch retries with backoff, respects Retry-After and records dead-letter/final failure and manual replay.
Private stays private
Customer-facing service reads and signed events exclude internal notes and supervisor coaching.
Make it work for your team.
- Name and scope service credentials, then rotate, revoke or set expiry under authorized merchant controls.
- Manage subscriptions, inspect delivery logs and replay eligible failed webhooks.
- Use the merchant-generated public ID only in widget installation; never substitute it for a service bearer secret.
Know what to expect.
- Public API writes use bounded idempotency keys; conflicting reuse is rejected. Lists paginate and rate controls can return 429.
- Webhook receivers must verify signatures and reject stale/replayed payloads; a slow receiver does not block chat API requests.
- A named CRM or commerce connector is not implied by this generic integration framework. A production backend must be available for real integrations.
One event, one server-side reaction
Illustrative: a merchant server receives a signed conversation event, verifies its timestamp and HMAC, then records its event ID once. No browser code sees the signing secret.
The details matter.
Can I recover a credential's secret later?＋
No. The secret is shown once. Rotate it to receive a new one; the prior secret becomes invalid.
What if my webhook server is unavailable?＋
The delivery worker retries with backoff and keeps delivery status/logs. Final failures can be inspected and manually replayed under the validated controls.
Is the widget's workspace ID an API key?＋
No. It is publishable installation configuration and cannot authorize privileged service calls.
Make every conversation easier to carry forward.
Public signup, checkout and payments are not available yet.