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

Read a connected account feed

Retrieve normalized published posts while preserving provider links and unsupported fields.

Direct answer

Call GET /v1/social-account-feeds/:id for a connected account. The response normalizes common post identity, caption, media, publish time, provider permalink, and available metrics while retaining null for information the provider does not supply.

What this means in practice

Call GET /v1/social-account-feeds/:id for a connected account. The response normalizes common post identity, caption, media, publish time, provider permalink, and available metrics while retaining null for information the provider does not supply.

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. Confirm the account capability matrix includes feed access.

  2. Use cursor pagination and preserve provider ordering semantics.

  3. Display the source provider and a deep link beside normalized content.

  4. Cache responsibly and respect the account's latest sync timestamp.

  5. Handle deleted, private, or no-longer-visible remote posts explicitly.

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-account-feeds/ACCOUNT_ID' \
  --header 'Authorization: Bearer APP9_POST_API_KEY' \
  --header 'X-App9-Post-Brand: BRAND_ID'

Operational details

Provider history depth varies and should not be presented as a universal retention promise.

Feed items are brand-scoped records and can be consumed by a CRM through API or events.

A feed record is not proof that App9 Post originally published the remote post.

Common mistakes to avoid

Protect intent, tenant boundaries, and provider state.
  • Do not merge feeds without preserving account and provider identity.
  • Do not display null metrics as zero engagement.
  • Do not scrape provider pages when a capability reports feed access as unavailable.

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