INTEGRATION

Platform integration

Embed Tesska's credential capabilities into your product: your users each connect their own Tesska and your platform calls the broker on their behalf — while your platform's own operational credentials go through its own workspace. No raw secret ever touches your code.

Two integration shapes

Pick one — or combine both — depending on who owns the credentials:

Connect Tesska (OAuth) — each of your users connects their own Tesska account. Your platform receives a per-user, revocable, scoped token and calls the broker on their behalf. Credentials always remain the user's.
Platform-owned workspace — your platform hosts its own operational credentials (bot accounts, deploy keys, …) in its own workspace, issues a project key (prefixed tsk_) in the console's Token Center, and calls /v1/* directly.

Shape 1: Connect Tesska (acting on behalf of users)

Register a client yourself under Developer Apps in the console (the client_secret is shown only once — store it safely). Integration follows the standard OAuth authorization-code flow with mandatory PKCE (S256): redirect the user to the consent page, then exchange the authorization code for a per-user access_token — a revocable, scoped key you can use directly as a Bearer token on every /v1/* endpoint.

# 1. Redirect the user to the Tesska consent page (PKCE S256 is mandatory)
GET https://tesska.com/oauth/authorize
    ?client_id=YOUR_CLIENT_ID
    &redirect_uri=https://your-platform.com/callback
    &state=RANDOM_STATE
    &code_challenge=BASE64URL(SHA256(code_verifier))
    &code_challenge_method=S256

# 2. Exchange the authorization code for a per-user access token
POST https://tesska.com/oauth/token
{ "code": "AUTH_CODE", "code_verifier": "CODE_VERIFIER" }

# => { "access_token": "..." }
#    A revocable, per-user scoped key. Use it as a Bearer token on /v1/*.

With the token: call the broker on the user's behalf

Use GET /v1/grants to see which credentials the user has authorized for your app and GET /v1/platforms for available platforms, then POST /v1/login to broker short-lived access. Direct-issue (A) credentials return a short-lived token immediately; approval-required (B) credentials push a request to the owner's phone — once approved, fetch the end-to-end encrypted result via GET /v1/approvals/:id. Only your caller's private key can decrypt it.

# Discover what the connected user has authorized for your app
curl https://tesska.com/v1/grants \
  -H "Authorization: Bearer USER_ACCESS_TOKEN"

# Broker a short-lived access token (never the raw secret)
curl -X POST https://tesska.com/v1/login \
  -H "Authorization: Bearer USER_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"platform":"github","account":"octocat"}'

# Mode A (direct issue) => { "token": "...", "expiresAt": "...", "scopes": [...] }
# Mode B (approval)     => { "kind": "pending_approval", "requestId": "...", "expiresAt": "..." }
#   the owner approves on their phone; poll GET /v1/approvals/:id

Shape 2: platform-owned workspace, direct to the broker

Your platform's own operational credentials have nothing to do with your users, so they take the direct path: host them in a workspace of your own and issue a separate project key per backend service in the Token Center. Every grant = project × credential × scope, plus a token TTL cap, per-minute rate limits and a per-project platform allowlist — so the blast radius of any single leaked key stays minimal.

# Your platform's own operational credentials, via a project-scoped key
curl -X POST https://tesska.com/v1/login \
  -H "Authorization: Bearer tsk_..." \
  -H "Content-Type: application/json" \
  -d '{"platform":"slack","account":"ops-bot"}'

Security boundaries

Your platform never receives a user's raw credential — the broker only delivers short-lived access tokens (raw delivery requires the asset owner to opt in explicitly and is gated by a global switch, off by default).
Approval-required (B) credentials need the owner's approval on their phone for every call; results are end-to-end encrypted and the server never sees plaintext.
Users can revoke your app's access at any time under Connected Apps; credentials themselves can be frozen or revoked with one click.
Full audit logging records metadata only (never plaintext), backed by anomaly detection and push alerts.
Multi-sig (M-of-N) and seed-phrase-grade protection: the most sensitive keys can be Shamir-split into N shares where any M reconstruct — neither the server nor your platform ever holds the complete key (coming soon).

Credentials belong to the user.Under Connect Tesska your platform only ever handles short-lived tokens and end-to-end ciphertext; users can withdraw access at any moment without affecting their other connected apps.

Approval webhooksPlanned

Outbound webhooks are not live yet. For the approval (B) flow, poll GET /v1/approvals/:id for the result. Official SDKs have not shipped either — every endpoint is plain HTTPS + JSON, so any HTTP client plus the examples in these docs is all you need.

Partnerships & billing

Billing for platform-level integrations is covered on the pricing page. For bulk user onboarding, higher rate limits or dedicated support, get in touch with us via tesska.com.