Check provider availability and production readiness
Separate service health, provider certification, connected-account capabilities, and live delivery outcomes before launch.
Treat production readiness as four different signals. The API health endpoint reports App9 Post service liveness; release documentation reports provider certification; each connected account returns its current capabilities; and post results report the actual outcome for each target. A green health check alone does not prove that a provider app, account scope, or content format can publish.
What this means in practice
Treat production readiness as four different signals. The API health endpoint reports App9 Post service liveness; release documentation reports provider certification; each connected account returns its current capabilities; and post results report the actual outcome for each target. A green health check alone does not prove that a provider app, account scope, or content format can publish.
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
Confirm that the required provider and credential mode are enabled in the intended environment.
Connect a staging account with the same account type and scopes planned for production.
Fetch the account capability matrix and test every required text, image, video, feed, analytics, inbox, and reply operation.
Monitor target-level delivery results, OAuth failures, schedule lag, queue depth, provider success rate, sync lag, webhook failures, and billing blocks.
Define a read-only or manual-provider fallback when a provider removes a permission or delays app review.
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/healthz' \
--header 'Authorization: Bearer APP9_POST_API_KEY' \
--header 'X-App9-Post-Brand: BRAND_ID'Operational details
Provider policies, app-review decisions, account tiers, and granted scopes can change independently of App9 Post deployments.
Unsupported analytics metrics remain null, and unsupported inbox actions remain read-only with a provider deep link.
Provider registration does not prove production certification or availability for every account.
Common mistakes to avoid
- Do not use /healthz as a synthetic publishing test or a guarantee of third-party API availability.
- Do not hardcode one global capability matrix for every account of the same provider.
- Do not hide partial success behind one generic failed campaign state.
Frequently asked questions
Does a listed provider mean every capability is generally available?
No. Registration identifies the adapter contract. Environment flags, certification, provider credentials, account scopes, and the live capability response determine availability.
What should an integration display during a provider incident?
Preserve scheduled content, show the affected target and actionable error, avoid blind retries, and let unaffected target accounts continue independently.