TeleQuick issues eleven distinct credential types. Each one is created and revoked in the console that owns the product it reaches, so a single account can accumulate keys with several different prefixes sitting in several different config files. This page is the map. If you have read mpk_, ctk_, cwk_ or nck_test_ out of an environment file and need to know what it opens, start with Prefix reference. For the underlying model — long-lived keys on your server, short-lived tokens on clients — see Authentication.

​
The credential map

The Credentials screen in the portal renders this same list with a direct link into each owning console. It does not mint keys itself.

​
Account keys: MCP access, Voice API, and CTI

Three credentials are account-level rather than product-level. They are created together on Admin · API keys. MCP access key (mpk_) lets a coding agent or MCP client operate the workspace. It acts as you: the key carries your membership, and it stops working when that membership ends. Treat it as equivalent to your own console session, not as a service credential that outlives you. Voice API key (cvk_) is the bearer key for the voice API — agents, outbound calls, call records, recordings, and transcripts. CTI key (ctk_) is the long-lived credential a CTI integration exchanges for the short-lived token that its control leg presents. The ctk_ key itself never rides the wire; only the exchanged token does. This is the same pattern as API key → relay token described in Authentication.

​
Agent and messaging keys

These three are created on the screen for the object they belong to, not on a shared keys page. External agent app key (ck_) is the key and secret your own voice agent uses to connect and to receive calls. Created per external agent on Voice AI · External agents. The secret is displayed once at creation. SMS API key (smk_) sends and reads messages over the SMS API, and is scoped at creation to send, read, or both. Created on Admin · SMS. Chat widget key (cwk_) identifies a chat widget to the platform. It is the one credential designed to sit in your page source — see Publishable vs secret. Created per widget on Admin · Chat widgets.

​
Per-product keys

Each product console issues its own key for its own API. The realtime credential is a pair, not a single string. The key half is public and ships in client code; the secret half stays on your server.

​
Environment scoping

Two credential types are scoped to an environment, and the environment is visible in the prefix: A test key cannot touch live data. This is the property you rely on when wiring a CI job or a local development environment: give it the _test_ key and a mistake in that environment cannot reach production inputs or match sessions. Every other credential type on this page has a single prefix with no environment segment. For those, separation between staging and production means issuing separate keys and tracking which is which yourself — the prefix will not tell you.

​
Prefix reference

Sorted by prefix, for when you have the string and not the context. ck_ and cck_, and ctk_ and cvk_, are easy to confuse at a glance. Check the fourth character before you file a key in the wrong secret store.

​
Publishable vs secret

Exactly one credential type is intended to be visible to the public:
  • Publishable — the chat widget key (cwk_). It is designed to sit in the HTML or JavaScript your visitors download.
  • Secret — everything else on this page.
Treat every secret credential as a password: keep it server side, keep it out of source control, and rotate it if it is ever exposed. Most are shown once at creation and cannot be read back afterwards. The realtime app credential deserves a note, because it is listed as secret while half of it is not. The pair as issued contains a secret, so the pair is secret. Within the pair, the key is public and ships in client code, and the secret stays on your server. Splitting the pair correctly is your responsibility; shipping the secret half to a browser leaks it.

​
Where each key is created and revoked

Creation and revocation live in the console that owns the product. That is deliberate: a credential has exactly one authoritative place to be issued and withdrawn, so there is never a second surface that can disagree about whether a key is still valid. The portal’s Credentials screen links out to each of these. Use it as the index when you know what you want to do but not which console does it.

​
Rotation and exposure

If a secret credential is exposed, issue a replacement in the owning console, deploy it, then revoke the old one there. Because creation and revocation are both on the owning screen, no other console needs to be touched. Two cases behave differently from the rest:
  • MCP access key. It is tied to your membership. Revoking your membership revokes the key’s access, without any separate key operation.
  • CTI key. The key is exchanged for a short-lived token rather than presented to the service directly. Replacing the ctk_ key stops new exchanges; tokens already issued remain valid until they expire.
Relay-token-style credentials that are minted from a long-lived key have their own rotation procedure, covered under rotating keys.