Authentication & environments

The Platform API authenticates with CuraeAI-owned API keys on a server-to-server channel.

Authorization: Bearer cae_live_…

Key kinds

Keys are environment-segregated: a cae_test_ key presented against production is rejected. The SDK enforces this at construction — building a client with a test key but a production base URL throws immediately, so the mismatch surfaces in development, not in production.

What a test key can do today

cae_test_ keys are scoped to the non-PHI surface — the Connect catalog, webhook management, and connection lifecycle. PHI reads (patient profile, observations, records export) require a cae_live_ key after you accept the BAA via the developer portal's go-live flow. A test key that attempts a PHI scope receives SCOPE_INSUFFICIENT.

Keys are secrets

Never put a key in a browser bundle, mobile app, log line, screenshot, or source control. Browser UI integrates through @curaeai/platform-sdk/react plus a backend proxy you host. The SDK's secret-bearing entry points (createPlatformClient, the webhook sign/verify helpers) fail closed in browser-like runtimes, and browser-aware bundlers resolve the root//server subpaths to a deny module.

import { createPlatformClient } from '@curaeai/platform-sdk';

const client = createPlatformClient({
  apiKey: process.env.CURAEAI_PLATFORM_API_KEY!, // server-side only
  baseUrl: process.env.CURAEAI_BASE_URL!,
  apiVersion: '2026-04-15',
});

Going live

When you're ready for real patients, complete the go-live flow in the developer portal: accept the BAA, then mint a cae_live_ key with the PHI scopes your product needs. Rotate keys from the portal; revoked keys stop authenticating immediately.

Next

• Webhooks — verify deliveries with your signing secret.
• API conventions — versioning, errors, rate limits.