API Keys

Both are managed on the API Keys(sign in required) page. A secret key is shown once, when you create or rotate it, and is stored only as a hash afterwards, so it cannot be shown again. A publishable key is created as part of an installation and stays available on it, in the embed snippet, along with the origins that installation allows.

A publishable key is not restricted to one endpoint. It is valid on the public surfaces that read metadata or start a widget session, and refused on every chat route.

The rule worth remembering is that a publishable key cannot reach the model. Reading an agent's appearance or the model list costs nothing and consumes no allowance, which is why those stay open to a key that ships in page source.

A publishable key has to be readable, because it ships inside a page. What protects it is not secrecy but the origin check. A request carrying it must come from a browser origin registered on that widget installation. Copied onto someone else's site, it answers nothing.

See Allowed Origins for what counts as a match.

• Read it from an environment variable. Never hardcode it in source, and never commit it.
• Never prefix it for a client bundle. A name like NEXT_PUBLIC_ or VITE_ tells the bundler to inline the value into JavaScript the browser downloads.
• Put a small endpoint of your own in front of it, so your frontend calls your server and your server calls Wicarax.
• Keep it out of logs, error reports and support tickets. Log the key prefix if you need to identify which key was used.

// The key stays on the server; the browser talks to your own route.
const wicarax = new Wicarax({ secretKey: process.env.WICARAX_SECRET_KEY });

Only an active key can be rotated. Rotation is per key: it issues a replacement of the same class and nothing else changes, so rotating the key in your web page cannot take your server integration down with it. The previous value stops working immediately and there is no overlap window, so the order of operations still matters.

1. 1Decide where that one key is deployed, meaning your embed snippet, or your server environment and any automation.
2. 2Rotate it on the API Keys page and copy the replacement.
3. 3Update every place from step one, then deploy.
4. 4Load your site and ask one question, or run one server-side call, to confirm the replacement works.

A revoked key cannot be rotated. Create a new secret key to replace a revoked secret. If a revoked publishable key leaves its installation unable to serve, create a new installation for the same agent and update the embed snippet.

After replacing a key, update every deployment that used the previous value. Usage totals are available on Usage and Analytics(sign in required).

• One key per deployment, named after where it runs, so you know what breaks when you revoke it.
• One installation per site, rather than one key shared across unrelated sites. Rotating then affects one place, and usage stays separable.
• Register only origins you control, and remove staging entries when a project ends.
• Deactivate an agent instead of deleting it when you want to stop traffic but keep the option to resume. Deleting takes its keys down permanently.
• Rotate on a schedule you can maintain, and whenever someone with access leaves the project.

For what to do when a request is refused, see Errors.