Traditional social media management tools make the dashboard the product: you log in, you see their calendar, you click their compose box. PostGate has no equivalent screen you're required to use. The scheduling and posting logic — cron expressions, recurring queue slots, drafts, and immediate publishing — lives entirely behind the API. Put your own UI on top of it, embed it inside a product your customers already use, or skip a UI altogether and let a pipeline schedule content on its own.
Create a kind: "cron" schedule with a standard expression and IANA timezone for a recurring template, or a kind: "slots" schedule with comma-separated HH:mm times to build a posting queue. There's no calendar UI in the loop — the schedule is a resource you create, patch, and pause with PATCH /api/schedules/{id}. See schedules & queues.
draft: true saves for approval, an ISO 8601 scheduled_at fires at a fixed instant, scheduled_at: "queue" takes the next open recurring slot, and omitting all three publishes immediately. It's the same POST /api/posts shape every time — whatever front end you build only has to render one model, not four.
A dashboard-first tool couples its scheduling logic to its own calendar view. PostGate's scheduling logic has no such coupling — nothing renders unless your product renders it. That's what makes it usable both as the engine behind your own customer-facing calendar and as the invisible layer inside a fully automated content pipeline with no calendar at all.
Design the interface your product actually needs — a Kanban board, a calendar, a Slack command — and call the same schedules and posts endpoints underneath it. Your UI, your interaction model, PostGate's delivery.
Generate content programmatically, create a cron schedule or push directly to scheduled_at: "queue", and let delivery run unattended. Read status through the API or subscribe to webhooks — nobody has to open a screen for the pipeline to work.
Each materialized post reports its own target-level delivery status, and post.published/post.partial/post.failed webhooks tell your system — not a PostGate dashboard — the moment something needs attention.
For the full API contract — OpenAPI document, generated SDKs, sandbox keys, idempotency, and structured errors — behind these scheduling endpoints.
For the reliability case — delivery evidence, retries, and webhooks — that makes scheduling logic safe to build a product on top of.
Every PostGate plan — Free, Solo, Launch, and Build — includes cron schedules, queue slots, and webhooks. No card required to start.