HTTP API
Typed services, custom apps, and direct integrations.
Use the OpenAPI 3.1 contract to generate a client or call the workspace-scoped API directly.
Developers and agents
Use the interface that fits the job.
OpenPost exposes one publishing system through a typed HTTP API, a CLI, and an MCP server. They use the same workspace terms, access rules, provider checks, and publication states as the web app.
Three maintained interfaces
One contract, different clients.
Choose by who or what will run the work. You can mix these interfaces without creating a second publishing model.
Read the API guide
CLI
Terminal work, scripts, CI, cron, and deploy jobs.
The CLI calls the same HTTP API and keeps named instances, tokens, and workspace selection explicit.
MCP server
AI assistants that need to inspect or prepare publishing work.
Start read-only, search the operation catalogue, and grant change access only when the client needs it.
Shared safety boundary
Automation does not bypass product rules.
A client can only do what its token, workspace role, plan, connected accounts, and provider readiness allow.
- Every call stays inside an authenticated OpenPost workspace.
- API and MCP tokens can be limited to one workspace and removed later.
- MCP separates read-only queries from calls that change OpenPost or contact a network.
- Provider rules, account setup, plan limits, and publishing checks still apply.
Inspect the contract before writing code.
The generated OpenAPI JSON is authoritative. The source and developer docs explain how the interfaces share authorization and workspace boundaries.