Embed Widget

Paste your installation's snippet immediately before the closing </body> tag of your site. The installation on the API Keys(sign in required) page renders it prefilled with your publishable key, so there is nothing to replace. The example below shows the shape.

<script
  src="https://api.wicarax.app/v1/widget.js"
  data-wicarax-key="wcx_pk_YOUR_PUBLISHABLE_KEY"
  async
></script>

1. 1Create an installation on the API Keys(sign in required) page and copy its embed snippet. The snippet contains its publishable key.
2. 2Add your site's exact origin to the same installation, including the scheme, for example https://yoursite.com.
3. 3Paste the snippet before the closing body tag and deploy.
4. 4Load the page. A launcher appears in the corner; open it and ask a question you know your material covers.

The widget is deliberately small and self contained. It injects a launcher and a panel, and it takes its appearance from the agent rather than from your CSS.

• A launcher button in the corner, positioned bottom right or bottom left according to the agent.
• A panel with the agent name, the conversation, and an input.
• The welcome message when the conversation is fresh.
• A typing indicator while an answer is being produced, since answers arrive complete rather than word by word.

The panel has no online indicator. Check account and installation status in the dashboard if messages stop working; the launcher alone does not confirm that the agent can serve requests.

The loader applies its colours, sizing and typography inline on the elements it creates, and the few class names it registers are prefixed. In practice it neither depends on your stylesheet nor adds rules that can affect it.

The loader is hosted, and it reads the agent's appearance at run time. Rename the agent or switch it between light and dark and the change appears on your site without touching your HTML again.

• The conversation is held on our servers, not in the page. The widget sends only the new message, and the transcript it answers against is the one we stored.
• Reloading the tab rejoins the same conversation. The access token stays in memory; a resume token in sessionStorage restores the transcript on reload. Closing the tab removes that resume token.
• Answers are returned complete in a single response. There is no partial text to reassemble.
• When a request fails, the widget shows a short message in the panel and does not add it to the conversation, so a failure never becomes something the assistant appears to have said.
• Answers never name a document, a file or a passage, on this surface or any other.

Reloading the tab redraws the recent transcript, so the visitor sees the conversation they were in. The welcome message is reserved for a fresh conversation, where there is no transcript to restore.

Because the transcript is server-owned, nothing on your page can add to it. The message endpoint accepts no conversation history at all, so a script on the page cannot put words in the assistant's mouth by editing what gets sent.

If the widget loads but every question is refused, compare the page's exact origin with the Allowed Origin configured for its publishable key.

Use the widget when you want a chat bubble today. Reach for the SDK when the interface itself is part of your product, for example an assistant embedded in a page layout, a support view inside your app, or anything that must match your own components. Both surfaces run through the same engine and produce the same answers.

Continue with Official SDK.

The widget starts a server-owned conversation with its installation key and the page origin. Later messages use a short-lived access token kept in memory. The resume token in sessionStorage is only for restoring the same tab after reload.

A session accepts a finite number of messages. When it is full, the widget asks the visitor to reload for a fresh conversation. Its visitor and installation safeguards are separate from your account's plan limit; see Rate Limits for the account boundary.