Create API keys and choose scopes

What this means in practice

App9 Post API keys are brand-scoped bearer credentials. Grant only the scopes a client needs, separate read-only and publishing workloads, set an expiration when practical, and record the raw key immediately because it is not returned again.

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

1. Inventory the endpoint families the client will call.

2. Create separate keys for production services, scheduled jobs, developer machines, and third-party integrations.

3. Use posts:publish only for clients authorized to dispatch content.

4. Store the raw key once, then retain only its sanitized name, prefix, scopes, and dates in user interfaces.

5. Revoke and rotate a key immediately when its environment or operator changes.

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/api-keys' \
  --header 'Authorization: Bearer APP9_POST_API_KEY' \
  --header 'X-App9-Post-Brand: BRAND_ID' \
  --header 'Content-Type: application/json' \
  --data '{
  "name": "Publishing service",
  "scopes": [
    "accounts:read",
    "media:write",
    "posts:read",
    "posts:write",
    "posts:publish"
  ],
  "expires_at": "2027-01-01T00:00:00Z"
}'

Open the complete API reference

Operational details

Common mistakes to avoid