Client-side API Calls

Client-side integrations should eventually be possible without encouraging developers to leak privileged credentials into the browser. The ideal model is delegated, scoped, and explicit about which operations are safe to perform from user-facing clients.

Design goals

Browser access should be:

• scoped to a signed-in user or a delegated client token
• restricted to explicitly allowed operations
• auditable by organization, user, and application
• unable to manage high-privilege resources with long-lived secrets

Recommended model

The preferred pattern is:

1. Your backend authenticates the user.
2. Your backend exchanges that user context for a short-lived delegated token.
3. The browser uses that delegated token for low-risk reads or approved executions.

const response = await fetch('/api/platform-token', { method: 'POST' })
const { delegatedToken } = await response.json()

const client = new AIPlatformBrowserClient({
  token: delegatedToken,
  organizationId: 'org_123',
})

Browser-safe patterns

Good candidate operations for future delegated client calls:

• reading prompt metadata needed by an in-app builder
• listing the current user's recent runs
• starting a browser-approved prompt execution
• creating a realtime session for a voice UI

What stays server-side

The following should remain server-only:

• service key management
• API key management
• tool creation and secret-bearing config
• organization-wide automation workflows
• privileged billing, user-management, and support administration operations

The practical rule is simple: browser clients can act as a user, but they should not become a substitute for backend credentials.