Skip to main content
Everything the calendar does — connect channels, schedule posts, read performance — is available over HTTP.

​
Base URL

​
Your first call

Start here: nearly every other route needs an integration id, and posting needs the identifier to know which settings object to send.

​
Channel or integration?

The interface says channel. The API says integration. Same object — the naming was never reconciled. This reference uses integration because that is what the routes are called.

​
Rate limits

90 requests per hour per organisation, across every endpoint together. Crossing it returns 429. Batch reads where you can - one bounded GET /posts beats polling per post.

​
Testing without writing code

Every endpoint page in this reference carries a runnable panel: paste your API key from Settings → Developers into the Authorization field, fill the parameters, and press Send.
The panel talks to your live organisation - a POST /posts from the docs creates a real post, and a delete really deletes. Test destructive calls against a draft, not a published campaign.

​
Dates

ISO-8601, always UTC. A post scheduled for 2026-09-01T09:00:00Z publishes at 09:00 UTC no matter what timezone the account displays.

​
Posting, end to end

1

List channels

GET /integrations — keep the id and identifier.
2

Upload media

POST /upload or POST /upload-from-url, if the post needs it. Keep the returned media id.
3

Pick a time

GET /find-slot/{id} for the next free slot, or choose your own.
4

Create the post

POST /posts with the channel, the content and that channel’s settings.
5

Confirm

GET /posts over the window, and GET /analytics/post/{id} once it is live.
Building something incrementally? Create posts with "type": "draft" — drafts skip settings validation, so you can assemble one over several calls, then use /posts/{id}/missing to see what is still outstanding.