Make your first App9 Post API call
Authenticate, select a brand, and list the social accounts available to your integration.
Send a bearer API key to the App9 Post API and include X-App9-Post-Brand when the key or session does not already select a brand. Start with GET /v1/social-accounts because it proves authentication, tenant selection, account access, and response handling without creating side effects.
What this means in practice
Send a bearer API key to the App9 Post API and include X-App9-Post-Brand when the key or session does not already select a brand. Start with GET /v1/social-accounts because it proves authentication, tenant selection, account access, and response handling without creating side effects.
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 an API key with accounts:read for a test brand.
Store the key in a server-side secret manager and expose only your own backend to browsers.
Send the Authorization and X-App9-Post-Brand headers to the production or staging API origin.
Log the returned X-Request-ID and parse non-success responses as application/problem+json.
Use the returned account IDs only inside the brand that produced them.
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 GET \
--url 'https://postapi.app9.co/v1/social-accounts' \
--header 'Authorization: Bearer APP9_POST_API_KEY' \
--header 'X-App9-Post-Brand: BRAND_ID'Operational details
API keys are displayed in full only once when created.
A 401 usually indicates missing or invalid authentication; a brand-selection problem is returned as a structured error.
Use staging credentials and accounts for integration tests instead of pointing development builds at production.
Common mistakes to avoid
- Never embed a privileged API key in a public JavaScript bundle or mobile binary.
- Do not retry 4xx authentication errors as if they were transient provider failures.
- Do not reuse IDs across brands or infer brand ownership from an ID prefix.
Frequently asked questions
Which base URL should I use?
Use https://postapi.app9.co for production and https://postapi-staging.app9.co for staging.