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

Welcome to App9 Post

Understand what App9 Post owns, which interfaces are available, and how the current service contract is organized.

Direct answer

App9 Post is an API-first social publishing service with a scheduler, REST API, TypeScript SDK, MCP interface, event stream, and webhooks. It owns connected social accounts, media, posts, delivery results, feeds, analytics, and inbox records while remaining callable from App9, Jaxia, Site9, CRM systems, or an outside application.

What this means in practice

App9 Post is an API-first social publishing service with a scheduler, REST API, TypeScript SDK, MCP interface, event stream, and webhooks. It owns connected social accounts, media, posts, delivery results, feeds, analytics, and inbox records while remaining callable from App9, Jaxia, Site9, CRM systems, or an outside application.

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. Create or select a brand, which is the tenant boundary for every resource.

  2. Choose App9-managed or customer-provided OAuth credentials for each provider.

  3. Connect a social account and inspect its live capability matrix before building a composer.

  4. Create drafts and previews before enabling scheduled or immediate publishing.

  5. Subscribe to result events so each target account can be reconciled independently.

Operational details

The current contract uses explicit publishing modes and never infers immediate publication.

Provider availability is enabled individually after certification; the capability response is authoritative.

The scheduler is optional. API, SDK, MCP, SSE, and webhook clients all operate on the same resources.

Common mistakes to avoid

Protect intent, tenant boundaries, and provider state.
  • Do not treat a registered provider name as proof that every provider operation is currently certified.
  • Do not store provider access tokens in your product; App9 Post returns sanitized account resources.
  • Do not merge target-level failures into a single post status without preserving successful deliveries.

Frequently asked questions

Is App9 Post only a scheduler?

No. The scheduler is one client of the same public interfaces available to other products and developers.

Is App9 Post generally available?

Yes. Verify provider certification and account capabilities before a production rollout.

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