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.

Create an API key

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

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

Create an API key

Available on every plan, including free workspaces.