Authentication

:::caution Products do not share credentials KOBANA_TOKEN holds a banking OAuth token or an inbox JWT, depending on which product you are calling — never both at once. kobana auth login only produces banking credentials. :::

banking

Access token (simplest)

Get the token in Integrações > API > Token de API in the Kobana dashboard.

export KOBANA_TOKEN=your_token_here

OAuth (PKCE)

The CLI uses OAuth with PKCE — works with zero configuration:

# Login (opens the browser, zero config)
kobana auth login

# Login asking for specific scopes. A resource with no verb is read, so this
# is a read-only session on two resources:
kobana auth login --scopes "inbox/emails,inbox/agent_runs"

# Add the global `write` verb when the session also has to write. There is no
# `read` scope in this API — see the API's Authentication page for the list.
kobana auth login --scopes "inbox/emails,write"

# Client credentials (for server-side apps)
kobana auth login --client-id <ID> --client-secret <SECRET>

# Check status
kobana auth status

# Export credentials (for CI)
kobana auth export > credentials.json

# Logout
kobana auth logout

Saved credentials are encrypted with AES-256-GCM. The key lives in the OS keyring (macOS Keychain, etc.) with a file fallback.

Resolution priority

Priority	Method	Configuration
1	Direct token	KOBANA_TOKEN
2	Credentials file	KOBANA_CREDENTIALS_FILE
3	Saved credentials	kobana auth login

inbox

The Autonomous Inbox does not share credentials with banking:

• KOBANA_TOKEN must be a JWT (RS256, issued by the Kobana authorization server) whose aud includes https://api.inbox[.<env>].kobana.com.br — see API Authentication for how that token is issued. kobana auth login does not produce it.
• KOBANA_INBOX_CLIENT_CERT must point to a PEM file with the client certificate chain and its private key — the API sits behind mTLS, exactly as described in API Authentication. Without it the CLI warns on stderr and requests are rejected.

kobana inbox emails list --fields "id,subject,received_at"
kobana inbox webhooks deliveries replay \
  --params '{"id": "WEBHOOK_ID", "deliveryId": "DELIVERY_ID"}'

Environments

The CLI operates in three environments. Production is the default.

Environment	API	OAuth	--env
Production	api.kobana.com.br	app.kobana.com.br	production (default)
Sandbox	api-sandbox.kobana.com.br	app-sandbox.kobana.com.br	sandbox
Development	localhost:5005/api	localhost:5005	development

# Production (default — no flag needed)
kobana banking charge pix list

# Sandbox
kobana banking charge pix list --env sandbox

# Local development
kobana banking charge pix list --env development

# Via environment variable
export KOBANA_ENVIRONMENT=sandbox
kobana banking charge pix list

# Login against sandbox
kobana auth login --env sandbox

Tokens are different across environments — a sandbox token does not work in production and vice versa. For inbox, the environment is carried in the JWT's aud claim (inbox/dev, inbox/stg, inbox/sdb, inbox/prd), so the right token must already match the --env you pass.

Next steps

• Usage — syntax, products, resources, examples.
• Environment variables — the full reference, including config and logging.