Connect support to the product your customers already use.

The Chateor Client API is a server-side interface for products that need a support experience inside their own application. It can be used from a web application backend, mobile application backend, account area, CRM integration, internal service, or custom support interface. The customer stays in the surrounding product while the support team works with the resulting conversation in Chateor.

The API can create a conversation, send a customer message, retrieve a known conversation, load message history, request messages after a known identifier, read the current status, and obtain information about the responsible agent and additional parameters. The current API version is oriented toward a basic text support scenario, so an integration should be designed around the documented capabilities instead of assuming a general-purpose CRM or ticket database.

• Base URL: https://api.chateor.com/v1/client
• Server-side authentication through the X-API-Key header.
• Conversation creation, messages, history, status, and responsible agent data.
• The integrating product stores its own relationship between a user, request, and dialog identifier.

A Client API integration sends customer messages into Chateor; webhooks carry the other direction. Operator replies, AI messages, and conversation status changes can be delivered to an endpoint configured for the channel. The external system can then show the reply in its own interface, update a local workflow, or trigger the next action that belongs outside the support platform.

Webhook consumers should validate the Chateor signature and timestamp headers before trusting an event. HMAC SHA-256 verification helps the receiving service detect messages that were not produced with the configured secret. Event processing should also account for retries and preserve a reliable relationship between the Chateor conversation and the corresponding customer or request in the external product.

• Channel-specific webhook configuration.
• Operator replies, AI messages, and status events.
• HMAC SHA-256 signature and timestamp verification.
• Server-side processing before an event changes product data.

Client API keys belong to a workspace and can access conversations across its channels. They must not be placed in browser JavaScript, public website code, a mobile application bundle, logs, or a public repository. Requests should be made from a trusted server controlled by the integrating organization, with the key stored in an appropriate secret manager or protected environment configuration.

Keys are separately manageable so an integration credential can be revoked without changing a user password or disabling the rest of the workspace. A sound implementation names keys according to their purpose, limits who can manage them through workspace roles, copies a new value into secure storage when it is issued, and rotates it when exposure is suspected.

• Never expose X-API-Key in the browser or mobile bundle.
• Use separate, named credentials for manageable integrations.
• Revoke or rotate a key without changing user credentials.

Not every integration needs the server-side Client API. A website can install the Chateor widget and use its documented JavaScript controls to influence display behavior, provide conversation context, or disable optional anonymous statistics before the widget loads. This route is appropriate for the public support surface because it does not require placing a workspace Client API key in the page.

The widget and Client API solve different problems. The widget is the ready-made website channel; the Client API is the server interface for a custom application or workflow. Both lead to conversations handled in the same Chateor support environment, where operators, statuses, roles, connected knowledge, and handoff behavior can be managed consistently.