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

Reply to a social inbox thread

Send a capability-aware reply with explicit user authorization and target-level results.

Direct answer

POST a message to /v1/inbox/threads/:id/replies only when the thread and account capabilities permit replies. Use an Idempotency-Key, require an editor-or-higher reply role, and show the provider result rather than optimistically treating a local message as delivered.

What this means in practice

POST a message to /v1/inbox/threads/:id/replies only when the thread and account capabilities permit replies. Use an Idempotency-Key, require an editor-or-higher reply role, and show the provider result rather than optimistically treating a local message as delivered.

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 the latest thread messages and reply capability.

  2. Require an explicit human confirmation for assistant-suggested replies.

  3. Validate length, media, and provider-specific response windows.

  4. Send the reply with a stable idempotency key.

  5. Update the thread after provider confirmation and preserve failure details.

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 POST \
  --url 'https://postapi.app9.co/v1/inbox/threads/THREAD_ID/replies' \
  --header 'Authorization: Bearer APP9_POST_API_KEY' \
  --header 'X-App9-Post-Brand: BRAND_ID' \
  --header 'Content-Type: application/json' \
  --data '{
  "message": "Thanks for reaching out. We are checking this now."
}'

Operational details

A local pending message is different from a provider-delivered reply.

Some providers support comment replies but not direct messages through the same account.

Provider deep links remain the fallback for unsupported operations.

Common mistakes to avoid

Protect intent, tenant boundaries, and provider state.
  • Do not let an AI draft silently become a sent customer message.
  • Do not retry an ambiguous reply with a new idempotency key before reconciliation.
  • Do not mark a thread resolved just because a reply request was accepted locally.

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