Authentication and usage

Authentication and usage

Before a session starts, the client has to say which software is calling and which end user it is calling for. It can do so in two ways: unauthenticated — your frontend presents the API key and names the account itself — or authenticated — your backend puts both into a token it signs, and the frontend only carries that token. In both cases the same two things are mandatory, an API key and an account; the difference is only how they reach Speechineer.

  • API key mandatory. Identifies your software: it belongs to one workspace and is created Unsigned or Signed. Create a separate one for every use case whose usage you want to follow or cap on its own.
  • Account mandatory. Identifies your end user — a person, a tenant, a device; you decide what it means for your product. A stable id per user, never a shared constant; the first session that names an account key creates it.
  • Signing key — authenticated clients only. A key pair whose private half stays in your backend and signs a short-lived token per logged-in user, carrying the API key and the account.

How each of them is handled, unauthenticated or authenticated:

UnauthenticatedAuthenticated
Fitpublic pages and developmentanything behind a login
Who can use Speechineer in your formanyone who can open the formonly users your backend issues a token to
API keyModeUnsignedSigned
Locationyour frontend — the client passes it in its apiKey optionyour backend — the token carries it in its api_key claim
AccountLocationyour frontend — the client names it in its account optionyour backend — the token carries it in its account_key claim
Signing keynot neededneeded — its private half signs every token

Danger

Never ship a private signing key to the browser. Sign in your backend, always.

In this section

Next: with a key and an account in place, wire the SDK — Integrate the SDK.