Developers
Three doors into the same scheduler. One contract behind all of them.
The dashboard is one client of the Postonus API, not a privileged one. Every operation is declared once and served at /api/v1, and the CLI, the MCP server, and your own scripts all go through those same declarations. So the thing you automate cannot drift from the thing the app does — there is no second implementation to keep in step.
Available on every plan, including free workspaces.
Pick by where your automation runs
In an application — the HTTP API
The API is the base layer. REST paths, an x-api-key header that
already binds the workspace, the resource itself in the response body with no
envelope to unwrap, and error codes declared in the contract so you narrow on a
code instead of matching a message string.
In a shell or CI — the CLI
The CLI is the same API with the auth and the JSON parsing already
done. npm install -g @postonus/cli, then every command takes --json and reads
POSTONUS_API_KEY, which is what makes it usable from a build box or a
container where no browser exists.
In an assistant — the MCP server
The MCP server hands your calendar to Claude, Cursor, or ChatGPT as tools rather than as a text description. The assistant can read the queue, check posting windows, and stage a scheduled post. Approval happens in the browser, so there is no key to paste into a config file.
What they share
One contract, one set of tenant checks, one rate limiter. A post created by a script is the same row the dashboard shows, appears in the same queue, and is published by the same worker under the same publish gating. There is no API-only code path that behaves differently from the app.
Found this useful? Pass it on.
All developer surfaces
- API accessA contract-first HTTP API for scheduling posts: one OpenAPI document, workspace-scoped API keys, declared error codes, and no response envelope to unwrap.Read
- MCP serverConnect Claude, Cursor, or ChatGPT to your social media calendar over MCP. Five tools to read your queue, check posting windows, and stage scheduled posts.Read
Questions
Frequently asked questions Everything the first evaluation usually needs.
- Which surface should I start with?
If you are wiring a build step or a cron job, the CLI is faster to get working because it already handles auth and JSON output. If you are writing an application, use the HTTP API directly. If you want an assistant to draft and stage posts for you, add the MCP server.
- Do I need a paid plan?
No. API keys, the CLI, and the MCP server work on a free workspace. What a free workspace cannot do is schedule or publish, so programmatic access covers writing, media, and drafts until you add a card.
- Are the rate limits shared with the dashboard?
No, deliberately. Browser sessions and programmatic callers count against separate per-minute budgets, so a looping script cannot refuse the UI of its own workspace. Each API key also has its own tighter cap.
- Is there an OpenAPI document?
Yes, generated from the same contract the handlers are built from rather than written by hand. Operations marked internal are filtered out of the published document and refused for API-key callers.
Keep reading
- API accessA contract-first HTTP API for scheduling posts: one OpenAPI document, workspace-scoped API keys, declared error codes, and no response envelope to unwrap.Read
- MCP serverConnect Claude, Cursor, or ChatGPT to your social media calendar over MCP. Five tools to read your queue, check posting windows, and stage scheduled posts.Read