Preview and validate before publishing

What this means in practice

POST the proposed content to /v1/social-post-previews before creation or publication. The response returns account-level render data and structured errors so a composer can show the exact target affected, the constraint violated, and the correction required.

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. Preview after account selection, media processing, or any override change.

2. Group validation feedback by target account and provider.

3. Block create or publish when an error is actionable and provider-enforced.

4. Distinguish warnings, unsupported optional fields, and hard validation failures.

5. Store the approved revision and require another review when material content changes.

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 POST \
  --url 'https://postapi.app9.co/v1/social-post-previews' \
  --header 'Authorization: Bearer APP9_POST_API_KEY' \
  --header 'X-App9-Post-Brand: BRAND_ID' \
  --header 'Content-Type: application/json' \
  --data '{
  "caption": "Preview this campaign before scheduling.",
  "mode": "draft",
  "target_account_ids": [
    "acct_x",
    "acct_youtube"
  ],
  "media_ids": [
    "media_demo"
  ]
}'

Open the complete API reference

Operational details

Common mistakes to avoid