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

Read delivery results and partial success

Explain what happened for every target account with provider IDs, links, attempts, and actionable errors.

Direct answer

Use /v1/social-post-results or /v1/social-posts/:id/results to reconcile each target. A target result can succeed, fail, remain in processing, or be billing-blocked independently, so customer-facing status must preserve those distinctions.

What this means in practice

Use /v1/social-post-results or /v1/social-posts/:id/results to reconcile each target. A target result can succeed, fail, remain in processing, or be billing-blocked independently, so customer-facing status must preserve those distinctions.

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. Display account, provider, target state, last attempt, and remote permalink together.

  2. Translate structured provider errors into a user action without discarding the original code.

  3. Treat a parent partially_succeeded state as a prompt to inspect targets.

  4. Offer retry only for targets whose failure classification is retryable.

  5. Reconcile ambiguous attempts before creating another remote post.

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-posts/POST_ID/results' \
  --header 'Authorization: Bearer APP9_POST_API_KEY' \
  --header 'X-App9-Post-Brand: BRAND_ID'

Operational details

Provider acceptance and provider publication are not always the same event.

Remote external IDs prevent a retry from duplicating already-created posts.

Billing commits only on confirmed provider success and can be refunded after a later confirmed reversal.

Common mistakes to avoid

Protect intent, tenant boundaries, and provider state.
  • Do not show a parent succeeded state when a target is still processing.
  • Do not retry validation or permission failures without a corrective change.
  • Do not remove the successful provider link when another target fails.

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