Set up development, staging, and production
Keep brands, credentials, accounts, webhooks, and content isolated across environments.
Use separate App9 Post brands, API keys, OAuth provider apps, connected test accounts, and webhook endpoints for each environment. Point staging at postapi-staging.app9.co and reserve postapi.app9.co for production traffic.
What this means in practice
Use separate App9 Post brands, API keys, OAuth provider apps, connected test accounts, and webhook endpoints for each environment. Point staging at postapi-staging.app9.co and reserve postapi.app9.co for production traffic.
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 environment inventory that names every brand, provider app, webhook, and owning team.
Register distinct OAuth callbacks and console redirects for staging and production.
Use synthetic or dedicated social accounts for automated staging certification.
Keep idempotency keys and event consumers environment-scoped.
Promote configuration intentionally; never copy provider tokens or raw API keys between environments.
Operational details
Provider reviews may require separate development and live modes even when App9 brands are isolated.
Webhook signatures must be verified with the secret created for that environment's subscription.
Run end-to-end scheduling and result reconciliation in staging before enabling production dispatch.
Common mistakes to avoid
- Do not route staging callbacks into production applications.
- Do not use production customer accounts for load or retry tests.
- Do not rely on hostnames alone; verify brand IDs and credential ownership in deployment configuration.