Provider readinessInterfaces and provider certification may evolve. Check account capabilities before production use.Read the readiness contract

Use account capability discovery

Render only the formats, metrics, inbox actions, and media constraints a connected account currently supports.

Direct answer

Fetch GET /v1/social-accounts/:id/capabilities after connection and whenever provider access changes. Treat the returned matrix as the shared source for UI controls, validation, API decisions, and AI tool behavior instead of hardcoding platform assumptions.

What this means in practice

Fetch GET /v1/social-accounts/:id/capabilities after connection and whenever provider access changes. Treat the returned matrix as the shared source for UI controls, validation, API decisions, and AI tool behavior instead of hardcoding platform assumptions.

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. Load capabilities before opening a composer for one or more accounts.

  2. Intersect capabilities for common controls and retain per-account overrides where support differs.

  3. Display provider constraints before upload or schedule submission.

  4. Refresh after reconnect, permission changes, provider migrations, or a capability-version event.

  5. Keep unsupported metrics null and unsupported actions read-only with a provider deep link.

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.

Shell
curl --request GET \
  --url 'https://postapi.app9.co/v1/social-accounts/ACCOUNT_ID/capabilities' \
  --header 'Authorization: Bearer APP9_POST_API_KEY' \
  --header 'X-App9-Post-Brand: BRAND_ID'

Operational details

Capabilities cover publishing formats, media limits, feeds, analytics, comments, mentions, messages, replies, and remote deletion.

Two accounts on the same provider may differ because of account type, region, scopes, or provider review state.

App9 Post validates requests again on the server even when a client already used the matrix.

Common mistakes to avoid

Protect intent, tenant boundaries, and provider state.
  • Do not assume every Instagram account supports identical publishing surfaces.
  • Do not translate unsupported analytics into zero because that changes the meaning of reports.
  • Do not let an AI assistant call tools that the selected account capability matrix forbids.

Was this useful? This documentation is reviewed against the public App9 Post contract. Use the API reference and live capability response for machine-enforced details.

Open API reference