Works with all AI agents

Connect your AI agent

Choose your AI agent and connect in seconds.

Add to Claude

Works on every Claude plan, including free. Full Claude guide

  1. 1

    Add to Claude

    One click from Claude’s connector directory.

  2. 2

    Sign up or sign in

    Takes seconds, then you’re sent straight back.

  3. 3

    Ask Claude

    “Plan and schedule my posts for next week.”

PostEverywhere Changelog Reference

PostEverywhere API changelog and version history. Track breaking changes, new endpoints, and improvements.

All notable changes to the PostEverywhere API.

2026-10-20: Approvals and local uploads in MCP, honest limits

New in the MCP server (@posteverywhere/mcp 1.14.0)

  • 44 tools on the full server (was 40): 43 in Claude's connector directory, 34 in the PostEverywhere app for ChatGPT.
  • Approvals: new approve_post and request_post_changes tools, list_posts takes approval: "pending" | "approved" | "changes_requested", and create_post takes request_approval: true (with draft: true only).
  • Local files: new create_media_upload and complete_media_upload tools upload a file that has no public link, including a PDF for a LinkedIn document post.
  • create_post takes campaign_id and cover_photo ({ "media_id": "..." } or { "url": "..." }). delete_media takes force.
  • bulk_create_posts items can use schedule_at: "best_time"; each post gets its own next best time.

Behaviour changes

  • Captions over the real limit are refused with 400 content_too_long when you create or edit a post, instead of failing when it publishes. See the limits.
  • schedule_at on the REST API now returns 400 unsupported_schedule_at (it is an MCP option). Read GET /v1/best-times and send the time as scheduled_for.
  • request_approval without draft: true returns 400 request_approval_needs_draft and creates nothing.
  • PATCH /v1/posts/:id merges per-platform settings into the saved ones instead of replacing them. On a draft it only changes the draft; nothing is queued until POST /v1/posts/:id/schedule.
  • snake_case setting names are accepted in platform_content.<platform>.settings (first_comment, alt_text, privacy_level, board_id and more) and converted to the camelCase keys.
  • First comments work on X only. Sent for Instagram, Facebook, LinkedIn, Threads or YouTube, firstComment is removed and the response notes say so.
  • DELETE /v1/media/:id refuses a file that a pending post uses (409 media_in_use); ?force=true deletes it and marks those posts failed.
  • generate_caption always fits the platform's limit. The response has char_limit and trimmed_to_fit.
  • Published-with-a-problem shows up. When a post goes out but the text was cut or a setting was not applied, the platform's entry in GET /v1/posts/:id and GET /v1/posts/:id/results carries it in warnings.
  • Bulk create counts every post against your rate limit, as a single create would. See Rate limits.
  • timezone is a display label only; scheduled_for without an offset is read as UTC (unchanged, now stated everywhere).
  • The post.publishing, post.updated and account.connected webhook events are no longer listed: they never fired. See Webhooks.

2026-10-13: API and MCP logs

All changes are additive: existing integrations are unaffected.

  • Logs in the dashboard. Every /v1 call made with an API key, including MCP tool calls from Claude, ChatGPT and Cursor, is listed on the new Logs page in the dashboard with the status, action, who made it, MCP tool, duration, error and redacted request and response bodies. Kept for 30 days on every plan. See Logs.
  • New response header: X-Request-Id on every /v1 response. It matches meta.request_id and the log entry, so you can search for it in Logs or quote it to support.

2026-10-05: Best times to post

All changes are additive: existing integrations are unaffected.

  • New endpoint: GET /v1/best-times. Pass account_id, account_ids (up to 20) or platform, plus optional timezone and count (1 to 10, default 5). Each slot has an ISO weekday, a local time, the next concrete datetime and a basis: personal (the account's own posts), platform (what works across PostEverywhere on that platform) or general (guidance, not measured). next_best is the soonest of the top three slots; use its next.iso as scheduled_for in POST /v1/posts.
  • MCP: new get_best_times tool, and create_post and schedule_post take schedule_at: "best_time", which schedules for the next best time and says which time it picked.
  • CLI: posteverywhere best-times -a <ids> or --platform <name>.

2026-09-26: WordPress

All changes are additive: existing integrations are unaffected.

  • New platform: wordpress. Publish blog posts to WordPress.com or self-hosted WordPress (5.6+, HTTPS). platform_content.wordpress.settings takes title, status (publish, draft, pending, private), excerpt, slug, tags, categories and featuredImage. Up to 20 images and 1 video, uploaded to the site's Media Library. See the WordPress guide.
  • Connect self-hosted sites headlessly with POST /v1/accounts/connect-credential (site_url, username, app_password), or the MCP tool connect_credential_account.
  • New errors: wordpress_post_invalid and wordpress_title_required.
  • The hosted MCP server's create_post, schedule_post, update_post and bulk_create_posts accept WordPress posts.

2026-09-25: Larger videos and X Article limits

All changes are additive: existing integrations are unaffected.

  • Videos up to 4 GB (was 500 MB) for uploads, upload-from-url, the MCP server and the CLI. Each platform's own limit still applies when you post to it; see Media requirements.
  • X Article fair-use limit is now 2 published articles per X account per rolling 24 hours (was 1 per organisation). Only successful publishes count.
  • X's own article cap (10 article actions per X account per 24 hours) no longer fails the post: it is held and publishes automatically 5 minutes after X's reset. See Publishing an X Article.

2026-09-24: X Articles, disclosure labels and X Communities

All changes are additive: existing integrations are unaffected.

  • X Articles: platform_content.x.settings.post_type: "article" publishes X's long-form format. settings.title (up to 100 characters) sets the title, and the first attached image becomes the cover. Body up to 25,000 characters. Requires X Premium on the connected account; a fair-use limit on published articles per rolling 24 hours (see the 2026-09-25 entry). See Publishing an X Article.
  • Disclosure labels: settings.made_with_ai and settings.paid_partnership add X's own disclosures to posts and threads.
  • X Communities: settings.community_id posts into an X Community the account belongs to.
  • The same fields work through create_post and schedule_post in the MCP server.

2026-08-28: Posting queue and approval workflow via API

The posting queue and the approval workflow shipped in the app today, and the API surface shipped with them. All changes are additive: existing integrations are unaffected.

Posting queue

  • GET /v1/queue: the workspace's recurring openings plus a preview of where the next posts will land (wall-clock in the queue's timezone). The preview is a forecast; allocation happens at create time.
  • POST /v1/posts now accepts use_queue: true: the server allocates the queue's next free opening and schedules the post into it. No scheduled_for needed (passing both returns 400). Requires a queue to exist; missing, empty, and full queues each return a distinct 400 message.
  • Queue management (editing openings) is deliberately app-only: posting cadence is a human choice, and a bot silently rewriting it is the failure mode we refuse.

Approval workflow

  • POST /v1/posts with draft: true now accepts request_approval: true: the draft enters the approval workflow immediately: approval_status becomes pending, owners and admins are notified, and it appears in the app's Approvals inbox.
  • POST /v1/posts/{id}/approve: clears a pending post. Body: optional { "note": "..." }. Approving does not publish; scheduling the cleared draft is what sends it out, and one approval authorizes exactly one publish. An API key is an organization credential (only owners and admins can mint one), so a key approving is an admin approving by proxy.
  • POST /v1/posts/{id}/request-changes: sends a pending post back to its author. Body: { "note": "..." }, required (the author sees it).
  • GET /v1/posts?approval=pending|approved|changes_requested: filter by approval state. A separate axis from status: a pending post is also a draft.

New webhook events

  • post.approval_requested, post.approved, post.changes_requested: fired from both the app and the API, so an integration hears about approvals wherever they happen. Same envelope and HMAC signature as every other event.

MCP server

  • MCP tools for the queue and approvals are deliberately held until the ChatGPT apps directory review of the current 37-tool inventory completes, then ship together with an updated submission.

2026-06-14: Drafts via API & MCP: create-review-schedule for agents

You can now create a post as a draft through the API and MCP, review it, and schedule it in a separate step. This unlocks the human-in-the-loop approval pattern: an agent drafts posts, a person (or a second agent) reviews them, and only then are they scheduled or published. All changes are additive: existing integrations are unaffected.

Draft creation on POST /v1/posts

  • POST /v1/posts now accepts draft: true: saves the post as a draft instead of publishing or scheduling it. The response returns status: "draft", the post_id, and a next_steps hint pointing at the schedule endpoint.
  • account_ids is optional for a draft. You can save a draft now and choose its target accounts later (either when editing the draft or in the schedule call). For a non-draft post, account_ids is still required.

New endpoint: POST /v1/posts/{id}/schedule

  • Turns a draft into a scheduled (or immediately-publishing) post. Body: { "scheduled_for": "<ISO 8601 UTC>" } to schedule, or { "publish_now": true } to publish immediately. Optional account_ids (to set/override the draft's targets) and timezone (display metadata).
  • Only works on drafts. Calling it on a post that is already scheduled, publishing, or published returns 409: re-scheduling an existing scheduled post is still done with PATCH /v1/posts/{id}.

Richer drafts on GET /v1/posts and GET /v1/posts/{id}

  • GET /v1/posts?status=draft and GET /v1/posts/{id} now return each draft's target account_ids and platform_content, so an agent (or a reviewer) can inspect exactly what a draft will publish before scheduling it.

MCP server

  • create_post gains a draft boolean: set draft: true to save a draft instead of publishing/scheduling.
  • New schedule_post tool: params: post_id, plus scheduled_for (ISO 8601 UTC) or publish_now: true, and optional account_ids and timezone. The full agent flow is now create_post(draft: true) → review with list_posts(status: "draft") / get_post → schedule_post.

ChatGPT & OpenAI Codex

  • The hosted MCP server and the agent docs now call out ChatGPT (via the hosted connector at posteverywhere.ai/agents) and OpenAI Codex alongside Claude Code, Claude Desktop, and Cursor as supported AI clients.

2026-06-11: Major API upgrade: introspection, webhooks, campaigns, bulk ops

The largest single API expansion since launch. Eleven new endpoints + a comprehensive enhancement of GET /v1/posts. All changes are additive: existing integrations continue to work unchanged.

New endpoints

  • GET /v1/me: introspection. Returns your API key context, scopes, organization, quota (accounts/AI credits/storage), and plan limits in one call. Call this first when initializing an integration so you don't have to hardcode organization_id.
  • GET /v1/analytics/summary: aggregate counters for a time window (today / week / month / all / custom). Returns posts-by-status, per-platform breakdown, total views/likes/comments/shares/impressions/clicks, and AI credits used. One call instead of listing every post and counting client-side.
  • Campaigns CRUD (GET/POST /v1/campaigns, GET/PATCH/DELETE /v1/campaigns/:id): group related posts under named campaigns. Tag posts via campaign_id on POST /v1/posts and filter via ?campaign_id=… on the list endpoint.
  • POST /v1/posts/bulk: create up to 50 posts in one call. Each post counts against your rate limit like a single create (corrected 2026-10-20). Returns per-item success/error so you can handle partial failures (HTTP 207 Multi-Status for mixed outcomes).
  • POST /v1/posts/retry-failed: bulk retry every failed destination matching a filter (account_id, platform, date range, post_ids, max_attempts). Refuses when no filter is provided to avoid "retry the entire failure history" footguns.
  • GET /v1/accounts/:id/health: token expiry, last successful publish, recent failure count, needs_reconnection flag, can_post boolean, and an overall status (healthy/warning/broken). Use this BEFORE publishing to detect a dead token in advance.
  • POST /v1/accounts/:id/reconnect: generate a signed dashboard URL that opens the platform OAuth reconnect flow for an account. 30-minute single-use token.
  • POST /v1/ai/generate-caption: generate 1-5 caption variants from topic + tone + platform. Respects per-platform character limits (X: 280, Bluesky: 300, LinkedIn: 3000, IG: 2200) and hashtag conventions. Costs 1 AI credit per returned caption.
  • Webhooks: POST/GET /v1/webhooks, GET/PATCH/DELETE /v1/webhooks/:id, POST /v1/webhooks/:id/test. Subscribe to event streams instead of polling. 12 event types (post.published, post.failed, post.partially_failed, account.reconnect_needed, media.uploaded, …). HMAC-SHA256 signing, exponential-backoff retries (30s → 2min → 10min → 1h → 6h → 24h, 6 attempts), auto-disable after 20 consecutive failures.

Enhanced GET /v1/posts

All new query params are optional and additive: the old single-value ?status= and ?platform= keep working.

  • status now accepts comma-separated values, and adds failed, partially_failed, publishing (was: only scheduled / published / draft). Example: ?status=failed,partially_failed.
  • platform now accepts comma-separated values. Example: ?platform=instagram,tiktok.
  • account_id: filter to one social account.
  • campaign_id: filter to a campaign.
  • Date range filters: created_after, created_before, scheduled_after, scheduled_before, published_after, published_before, updated_after (the last one for incremental sync polling).
  • search: full-text search on post content (ILIKE).
  • sort: created_at (default) | scheduled_for | published_at | updated_at.
  • order: asc | desc (default).
  • Response includes pagination.total + pagination.has_more so clients know if more pages exist without fetching the next one.
  • Response includes per-destination metrics (views/likes/comments/shares/impressions/saves/clicks) inline: no more N+1 fetch pattern.
  • Response includes campaign_id on each post for round-trip + filtering.

MCP server expansion

The Claude Code MCP server now exposes the new endpoints as tools: get_me, get_analytics_summary, list_campaigns, create_campaign, get_campaign, update_campaign, delete_campaign, bulk_create_posts, retry_failed_posts, get_account_health, reconnect_account, generate_caption, list_webhooks, create_webhook, get_webhook, update_webhook, delete_webhook, test_webhook, list_posts_advanced. Existing tools (list_posts, create_post, etc) are unchanged.

SDK

@posteverywhere/sdk v1.3.0 publishes companion methods: client.getMe(), client.getAnalyticsSummary(), client.listCampaigns(), client.bulkCreatePosts(), client.retryFailedPosts(), client.getAccountHealth(), client.getAccountReconnectUrl(), client.generateCaption(), client.listWebhooks(), client.createWebhook(), client.listPostsAdvanced(). All new methods are TypeScript-typed.

Backwards compatibility

  • All previously documented params and response fields continue to work and contain the same shape.
  • ?status=scheduled (single value) still works: comma-separated is opt-in.
  • ?platform=instagram (single value) still works.
  • Old pagination: { limit, offset } shape unchanged; new fields (total, has_more) are added.
  • New response fields (campaign_id, metrics, etc) are appended; nothing was removed.
  • New endpoints are net-new: they don't collide with anything in v1.

2026-05-29: Bluesky support, accurate post status, media auto-finalize

Bluesky (AT Protocol) is now a supported platform (the 9th). Connect a Bluesky account with a handle + app password, then publish text, images (up to 4), video (MP4), and threads. Links, @mentions, and #hashtags are turned into rich-text facets automatically, and URLs render as link cards. See the Bluesky guide.

  • post_status now reflects real publishing progress. Previously a publish_now post could report scheduled indefinitely because the value was fixed at creation time. The status is now derived from per-destination state and can be scheduled, publishing, published, partially_failed, or failed: consistent across POST /v1/posts, GET /v1/posts/{id}, the list endpoint, and /results. The ?status= list filter now filters on the same real status.
  • Posts auto-finalize uploaded media. If you attach media_ids for media that was uploaded but not yet finalized with POST /v1/media/{id}/complete, POST /v1/posts now completes it for you (verifying the file exists) instead of returning media_not_ready. The explicit /complete call is still supported and recommended for tighter control.
  • Clearer errors. Posting multipart/form-data to /v1/posts now returns guidance on the correct JSON shape and the upload → media_ids flow. The media status response exposes ready and action_required fields so polling clients know a /complete call is required.

2026-04-12: scheduled_for rename, strict field validation, scope visibility

scheduled_for is now the canonical request field for scheduling posts. The old name scheduled_at was a misnomer: it read as a past-tense timestamp (like created_at / updated_at) even though it represented a future moment when the post will publish. scheduled_for makes the intent explicit.

  • scheduled_for is the canonical request field name (was scheduled_at). The response also returns the value under scheduled_for, completing the round-trip.
  • scheduled_at is deprecated but still accepted as an alias. Existing integrations built before 2026-04-12 will continue to work unchanged. New integrations should use scheduled_for.
  • Strict 400 validation for unknown media field names. If you send media, media_id, mediaId, or attachments in a request body, the API now returns 400 invalid_field_name with a helpful did you mean media_ids? hint. The only accepted media field on requests is media_ids (an array of UUID strings).
  • OAuth scope visibility. When a user reconnects a social account and the platform drops scopes from the grant, we now record the drop and alert on the mismatch, so silently-broken integrations surface quickly.
  • Body logging for v1 endpoints. The v1 API now logs sanitized request bodies (with API keys and tokens redacted) for debug visibility, making it much easier to trace bad requests when you email developer support.
  • Round-trip principle. Every top-level field name in a request body also appears in the response with the same name and meaning. You can take a post you got from GET /v1/posts/{id} and POST its fields straight back to clone it: no renaming.

v1.0: March 2026

  • Initial public API release
  • 18 endpoints across Accounts, Posts, Media, and AI
  • Support for 8 platforms: Instagram, TikTok, YouTube, LinkedIn, X, Facebook, Threads, Pinterest
  • Bulk scheduling (up to 100 posts per request)
  • AI image generation
  • MCP server integration for Claude Code
  • Node.js SDK

Subscribe to API updates by emailing developers@posteverywhere.ai.

Resources:

Building on the API?See plansAPI overviewConnect an AI agent