Planify

Read this before writing a post. Returns, for one specific channel: the character limit, how much media it accepts, whether media is required, the rules that decide whether publishing succeeds, a JSON Schema for its platform settings, and any lookups it supports. Per channel, not per platform, because a Facebook Page and a profile differ.

Fetches values that cannot be guessed — Pinterest boards, Twitter communities. Which lookups exist for a channel is listed as tools[].method_name by planify_channel_settings, and each says which post setting its result fills in. A Pinterest pin cannot be created without running the boards lookup first.

Creates a post. Defaults to a draft. content as a string sends the same copy to every channel in channel_ids. As an array of { channel_id, content } it gives per-platform copy — which is what you want when the same idea needs 280 characters on Twitter and 2,200 on Instagram. Call planify_channel_settings first and honour what it returns, including any required platform_settings such as a Pinterest board_id. Attachments publish in the order given — media[0] is the first image, and for an Instagram carousel that is the first slide. Reordering the array reorders the post. Prefer media: [{ url, alt }] over media_urls when the images carry information: alt text is the only machine-readable copy of what is on a data slide, and on the platforms that accept it there is no other way to add it to a scheduled post. limits.supports_alt_text on planify_channel_settings says whether this channel delivers it. type "now" publishes immediately and cannot be undone. Only use it when the user has confirmed this specific post should go out now; otherwise create a draft or schedule it.

Removes a draft or scheduled post so it will not go out. On an already-published post this deletes only Planify's record — the post stays live on the platform and must be removed there. The response says so when that is what happened. Confirm with the user before deleting anything they did not ask you to delete.

One post in full: content, attachments with their alt text, platform settings, and what happened when it published — permalink, published_at, or the platform's error. This is how to answer "did post X go out, and where is it" for a post that was scheduled rather than published on the spot.

The weekly slots and the timezone they are written in. Returns schedule: null when the channel has none — which is also why planify_next_slot would return slot: null, so read this first if that happens rather than inventing a time.

Connected social accounts, with the channel id needed by every other tool. Channels the plan does not cover are included but marked available: false — so "not connected" and "not on your plan" stay distinguishable.

Media already in this account, newest first — including files uploaded through the Planify web app, not just through this server. That is what makes it possible to finish a post someone started in the browser: the images are already there, and this is how to name them. Returns next_offset when more pages exist; null means this was the last.

Posts in this account — drafts, scheduled, and published — newest scheduled first. Call this before adding to a queue, so "what is already going out this week" is answered before "add another". Each post carries its delivery outcome: status, published_at, permalink once it is live, and last_publish_error when a platform rejected it. A date window (from/to) filters on scheduled_at, so it excludes undated drafts — which is correct for a calendar question, and worth knowing when a draft seems missing.

The plan, the permissions this API key holds, and quota remaining. Call this first if a later call fails with a payment or permission error — it says exactly what the key can and cannot do. The `endpoints` block lists every endpoint split into what this key can call and what it cannot, with the missing scope named per entry. Read it instead of discovering the boundary by being refused: a key without posts:publish can prepare and schedule everything and publish nothing, and saying so up front is better than failing the call.

The next free time from the weekly posting schedule the user already set, skipping slots already taken. Prefer this over choosing a time yourself. Returns slot: null when the channel has no schedule — then ask the user, or send an explicit scheduled_at.

Publishes a post that already exists — the approval half of "let the agent draft it and I will approve". Irreversible and public. Needs the posts:publish scope, which keys do not carry unless asked for. Only call this when the user has confirmed this specific post should go out now; if they have not, leave it as a draft and tell them how to review it. Returns the permalink for each channel it reached.

Sets the weekly grid planify_next_slot draws from. Replaces the whole schedule, so send every slot you want, not just new ones. Times are local wall-clock time in `timezone`, never UTC: a slot written as 12:30 in Asia/Kolkata stays 12:30 to the audience across a daylight-saving change, which a UTC time would not. Ask the user which zone they mean rather than assuming — an hour's error here is invisible until posts go out at the wrong time. This is the user's publishing rhythm, not an implementation detail. Confirm before changing a schedule they already set.

Changes a post that has not published yet. Send only the fields to change. This is the tool that makes correcting a mistake possible: without it the only way to change a scheduled post is to create a second one, which is how duplicates happen. Prefer editing over recreating. A published post cannot be edited and the call is refused — Planify's copy would then claim text the audience never saw. Editing what is already live is a platform-side action, not this.

Uploads local files and returns media_urls to pass to planify_create_post. Use this for anything an agent has just produced — rendered slides, a chart, an exported video — which lives on disk and has no public URL yet. Files are sent in the order given, and that order is the order they appear in the post: for an Instagram carousel, files[0] is the first slide. Prefer this over planify_upload_media_from_url unless the file is already published somewhere public — uploading directly avoids having to host the image before the post exists.

Planify downloads the file and returns media_urls to pass to planify_create_post. Use this when the image already exists at a public URL — the usual case after generating one. The URL must be publicly reachable; private and internal addresses are refused.

Takes the same arguments as planify_create_post and reports whether they would be accepted. Creates nothing, publishes nothing. Use it when a post is close to a limit, or when a platform has rules you are unsure you have satisfied — it is cheaper than finding out by leaving a failed draft in someone's queue. Returns errors with the field, the rule and the numbers, plus warnings for things that would be silently ignored (alt text a platform will not deliver, a thread on a platform without threads). Content and settings only: plan limits and quotas are checked when the post is actually created, so a valid result is not a guarantee the create call will succeed. planify_me covers the plan side.