Authenticate and select a brand
Use bearer keys or App9 Account sessions without weakening brand isolation.
Authenticate with a bearer API key for server integrations or an App9 Account session for the console. Select the brand with X-App9-Post-Brand when it is not already bound to the credential, and expect every resource lookup to enforce that brand boundary.
What this means in practice
Authenticate with a bearer API key for server integrations or an App9 Account session for the console. Select the brand with X-App9-Post-Brand when it is not already bound to the credential, and expect every resource lookup to enforce that brand boundary.
Use the documented brand and account boundaries consistently across the scheduler, REST API, SDK, MCP tools, SSE consumers, and webhooks. That makes the same social operation explainable to an operator and reproducible by an integration.
Implementation checklist
Choose API-key authentication for server-to-server workloads.
Keep browser sessions on the console BFF rather than exposing raw service keys.
Send the brand header consistently on brand-scoped calls.
Validate redirect targets during account sign-in and provider OAuth.
Return sanitized errors without revealing credential-validation internals.
Operational details
The API rejects a requested brand that conflicts with a brand-bound key.
Delegated MCP tokens are short-lived credentials for assistant tool calls, not general API keys.
CORS permits only the documented request headers and configured console origins.
Common mistakes to avoid
- Do not pass API keys through query strings.
- Do not trust a brand ID from a client without checking membership or key binding.
- Do not expose authentication failure details that help enumerate valid keys.