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

Work with unified inbox threads

Normalize comments, mentions, and direct messages while preserving provider-specific reply support.

Direct answer

Inbox threads combine supported comments, mentions, and direct messages into brand-scoped records with unread count, assignment, status, messages, and provider deep links. Unsupported operations remain read-only rather than pretending a reply succeeded.

What this means in practice

Inbox threads combine supported comments, mentions, and direct messages into brand-scoped records with unread count, assignment, status, messages, and provider deep links. Unsupported operations remain read-only rather than pretending a reply succeeded.

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. List threads using inbox:read and display provider, account, contact context, and latest activity.

  2. Mark unread state only after the user or workflow has actually consumed the thread.

  3. Assign ownership before multiple agents reply.

  4. Use resolved and archived states consistently with your customer-support workflow.

  5. Check reply capability before rendering the composer.

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

Operational details

The inbox is social engagement infrastructure, not a replacement for CRM contacts, pipelines, or opportunities.

Provider message types and history depth vary.

A consuming CRM can subscribe to inbox events and link threads to its own records.

Common mistakes to avoid

Protect intent, tenant boundaries, and provider state.
  • Do not combine different people solely because their display names match.
  • Do not hide the provider source of a normalized message.
  • Do not show an editable reply box for read-only threads.

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