One integration standard.
Every product.

Register each product once, isolate every environment, and give each runtime only the capabilities and credentials it needs.

Product and environment model

A product is the application in the Alex Studio registry. An environment is a separately configured deployment such as development, staging, or production. Each environment maps to its own project namespace. That namespace is the API authorization and data-isolation boundary; a shared Alex identity does not combine product data.

Existing projects are marked legacy until someone confirms their actual environment. Do not label an environment production merely because it is currently live. Create a separate environment instead of reusing a production API key for local development or staging.

Standard onboarding

1. Create the product and first environment.

   Choose the product name and environment type in Admin → Products. The environment gets a new isolated project namespace.

2. Choose only required capabilities.

   Enable the capabilities this environment actually uses. Some capabilities require others, for example workflows require AI and data.

3. Create an environment-scoped key.

   Under API keys, create a key for the environment's project namespace. Grant only the scopes required by that application. Store the key in that environment's server-side secret manager.

4. Configure shared sign-in when needed.

   Enable auth for that environment's project and key. Register exact HTTPS callback URLs and origins. Keep email sign-in disabled unless it is intentionally enabled for this product.

5. Verify the integration.

   From the server, call GET /v1/capabilities using the environment key. Confirm the returned project ID and granted capabilities before serving traffic.

Server-side setup

import { createClient } from "./alex-studio-hq.js";

const hq = createClient({
  apiKey: process.env.ALEX_STUDIO_HQ_API_KEY,
  baseUrl: "https://admin.alexstudiohq.com",
});

const capabilities = await hq.capabilities();
if (capabilities.contractVersion !== 1) {
  throw new Error("Unsupported Alex Studio API contract");
}
console.log(capabilities.projectId, capabilities.features);

Use a different secret for every environment. Never put API keys in browser code, source control, logs, support messages, or AI prompts. Public auth client IDs are not API keys; they cannot authorize project APIs.

Authorization and user data

Alex Studio authorizes requests by project and key scope. Records stored through the data API are project-scoped; the API does not automatically partition them by the signed-in end user. Your product backend must verify the Alex identity token and enforce ownership/authorization on every user-data read or write. Do not accept a client-supplied user ID as proof of ownership.

New environment creation does not copy data, keys, auth sessions, provider credentials, domains, or user records. Configure and migrate each one deliberately.

Admin → Users shows shared sign-in methods, verified account sources, and Alex Auth memberships per environment. Existing-account migration status is an owner-maintained note; it does not inspect or prove migration from an external product database. Mark an environment verified only after the product owner has tested its account-linking and data-ownership behavior.

Operational change policy

Use additive schema changes, test migrations against a copy, deploy compatibility code before switching callers, and preserve a rollback point. Rotate a key by issuing and verifying the replacement before revoking the old one. Pause an environment only when its traffic is expected to stop.

The capability catalog is versioned metadata for onboarding and discovery. It does not execute arbitrary extensions. A truly new capability still requires implementation, authorization tests, operational limits, and deployment in the appropriate private service.