Get your API key

Create an organization and an app in the Console, and get the client_id and client_secret you'll use to call the SDK.

Every SDK call needs credentials. This guide gets you the client_id and client_secret you’ll use in the next guide — Your first SDK call — in about two minutes.

What client_id and client_secret are for

The client_id/client_secret pair you get below are Basic-auth credentials for POST /auth/token — the recommended way to mint the short-lived, per-user session JWTs your browser SDK uses (see Choose your auth mode). Your backend sends them as Authorization: Basic base64(client_id:client_secret); the platform returns a JWT scoped to your app’s allowed_pipelines.

They are not the same credential as the x-api-key used in server-only API key mode, and they are not a JWT-signing secret. If you go with the (legacy, alternate) self-signed-JWT approach described in Integrate into your own server, that path needs a different secret — a per-app signing secret — which isn’t issued from this Console flow at all. It’s provisioned out-of-band by the platform operator, over a secure channel, and is only needed if you deliberately choose to self-sign instead of calling POST /auth/token.

What about a static `x-api-key`?

This guide covers the client_id/client_secret pair for session-JWT mode — the recommended path for most integrations. A static x-api-key is a separate, self-service credential for the same app: open the app’s detail page in the Console and click Regenerate API Key under the “API Key” card. The key is shown once; store it in your server’s secrets store.

Unlike client_id/client_secret (which you exchange for a short-lived JWT via POST /auth/token), an x-api-key is used directly as a header on every call — no minting step. It’s scoped to the same app: it can only call pipelines on that app’s allowed_pipelines list, and bills to that app’s org wallet, same as a session JWT. The tradeoff is per-user attribution — every call looks like it came from “the app,” not a specific user. For anything where per-user attribution matters, use session JWT mode instead. See Choose your auth mode for the full comparison.

Open the Console and sign in, or create an account (50 free credits, no card required).

2. Create an organization

Create an org. You become its owner. The org holds your apps, usage and billing.

3. Create an application

Under Applications → New application, give it a name. This app is the identity your server will use to call the SDK.

4. Copy your client_id and client_secret

You’ll see a client_id and a one-time client_secret. The secret is shown once — copy it into your server’s secrets store now. It must never reach browser code or a public repo.

5. Enable a pipeline

Go to Tools, pick a pipeline (start with translate-string), and click Enable onto application. This adds it to the app’s allowed_pipelines allow-list — the SDK (and any JWT minted via POST /auth/token) can only call pipelines your app has enabled.

Next: Your first SDK call uses this client_id/client_secret pair to make a real translate call.