Platform / External clients

Embed Telara in the dashboard your team already uses

Give an internal portal or customer-facing product a governed Telara connection. Your people sign in with their own Telara account, so they do not need a second dashboard or a shared credential.

OAuth 2.0 authorization code + PKCE

Tenant-scoped API access

MCP support

Choose the connection

Use the client type that matches where code runs

Browser, mobile, or desktop app

Create a public PKCE client. It has a client ID and never has a secret. The app creates a PKCE verifier and sends each person to Telara to approve access.

Use this when your application runs on an end user's device.

Customer backend or BFF

Create a confidential client. Telara shows the client secret once; store it in your server-side secret manager and use it only at the token endpoint.

Use this when your backend exchanges authorization codes. Never ship this secret to a browser, mobile app, or desktop app.

Administrator setup

Register the external product once

Open Developer Access

In Telara, open Organization → Developer Access, then select Create external client. Tenant administrators manage this setup.

Add the exact callback URL

Enter the URL your product uses after Telara authorization, for example https://portal.example.com/oauth/telara/callback. Telara rejects a redirect URI that does not exactly match the registered value.

Choose the target and application type

Choose Telara API for a tenant-scoped dashboard integration, or choose a governed MCP configuration for agent tools. Then choose public PKCE or confidential backend/BFF as described above.

Copy the setup values

Copy the client ID, authorization endpoint, token endpoint, and resource URL into your product. Confidential clients also receive a secret once. Store it before leaving the screen; Telara cannot display it again.

What your developers configure

Standard OAuth endpoints, plus an explicit resource

Authorization endpoint: https://api.telara.dev/oauth2/authorize
Token endpoint: https://api.telara.dev/oauth2/token
API resource URL: https://api.telara.dev/v1
MCP resource URL: https://api.telara.dev/v1/mcp

// Send the user to Telara. PKCE S256 is required.
GET https://api.telara.dev/oauth2/authorize?
  response_type=code&client_id=YOUR_CLIENT_ID&
  redirect_uri=YOUR_REGISTERED_CALLBACK&
  code_challenge=PKCE_S256_VALUE&
  code_challenge_method=S256&scope=api:read

At the callback, exchange the code with the original PKCE verifier. A confidential backend authenticates the token request with its selected client-secret method; a public client does not send a secret.

End-user experience

People authenticate as themselves

1. Sign in

The product redirects the person to Telara. Their existing Telara session is used when available.

2. Approve scope

They see the requested read/write capability and explicitly approve the connection.

3. Continue working

They return to the external product. The product acts only as that person, in their Telara tenant.

Access boundary

Scopes are deliberately narrow

api:read authorizes read-only API operations; api:write authorizes write operations. API tokens are accepted only for Telara's non-admin API surface. Platform administration, CLI endpoints, tenant-key management, webhooks, and MCP transport keep their dedicated authentication boundaries.

MCP tokens and API tokens have different audiences and cannot be replayed across the two resources. Suspending or removing a tenant member, or revoking the external client, blocks that person's OAuth access on subsequent requests.