Create and configure a brand
Use brands as the tenant, timezone, approval-policy, and direct-publishing boundary.
A brand groups members, API keys, provider apps, connected accounts, media, posts, webhooks, and audit history. Configure its timezone, approval policy, and direct-publish setting before onboarding accounts so every client applies the same workflow rules.
What this means in practice
A brand groups members, API keys, provider apps, connected accounts, media, posts, webhooks, and audit history. Configure its timezone, approval policy, and direct-publish setting before onboarding accounts so every client applies the same workflow rules.
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
Create a brand with a stable name and IANA timezone.
Choose approval policy none or one_approver based on the team's publishing risk.
Leave allow_direct_publish disabled until API scopes and operational ownership are reviewed.
Add members with the least-privileged role that supports their work.
Create environment-specific API keys and provider apps instead of sharing them across brands.
Example request
This example uses a server-side API key and an explicit brand selection. Replace placeholder values and keep credentials out of browser bundles, client logs, and source control.
curl --request POST \
--url 'https://postapi.app9.co/v1/brands' \
--header 'Authorization: Bearer APP9_POST_API_KEY' \
--header 'X-App9-Post-Brand: BRAND_ID' \
--header 'Content-Type: application/json' \
--data '{
"name": "Acme Social",
"timezone": "America/New_York",
"approval_policy": "one_approver",
"allow_direct_publish": false
}'Operational details
Dates are stored in UTC and displayed using the brand timezone.
Only owners and admins manage credentials, keys, webhooks, and roles.
Brand settings apply to scheduler users and API clients consistently.
Common mistakes to avoid
- Do not use one brand for unrelated customers if they require separate data and audit boundaries.
- Do not encode secrets or customer data in the brand name.
- Do not enable direct publication simply to bypass an approval workflow during testing.