Changelog

DELETE /v1/media/{id} already refused to delete an asset attached to a post. The in-use check now covers every place an asset can be referenced:

• posts (as before)
• channel brand kits — logo, persona photos, and style-reference images used by AI agents
• the workspace logo
• channel profile avatars

The endpoint still returns 409 Conflict when the asset is in use; the error message lists where it is referenced so you know what to detach first. Assets with no references delete exactly as before.

Two new channel endpoints (both require the channels:read scope) return the platform data needed to fill in platform-specific post options:

• GET /v1/channels/{id}/pinterest/boards — lists a Pinterest channel's boards (id, name, privacy, pin count). Use a board id as boardId in POST /v1/posts/pinterest.
• GET /v1/channels/{id}/tiktok/creator-info — returns a TikTok account's posting constraints: allowed privacyLevelOptions, whether comments/Duet/Stitch are available, and the maximum video duration.

Four new endpoints accept the full set of options each platform supports — the same options available in the Nimply app — and validate platform-required fields at request time (all require the posts:write scope; scheduling/publishing additionally requires posts:publish):

• POST /v1/posts/youtube — upload a video or Short with title (required), category, visibility, license, notifySubscribers, allowEmbedding, and madeForKids.
• POST /v1/posts/tiktok — create a video or photo post with privacyLevel (required), allowComments, allowDuet, allowStitch, and commercial-content disclosure (brandContent, brandOrganic).
• POST /v1/posts/pinterest — create a pin on a specific board with boardId (required), destination link, and altText.
• POST /v1/posts/linkedin — post to a profile or company page with visibility (PUBLIC or CONNECTIONS).

The generic POST /v1/posts is unchanged and remains the right choice for simple cross-platform posting.

POST /v1/posts/{id}/unschedule moves a SCHEDULED post back to DRAFT and clears its publish time (requires the posts:write scope). Unscheduling a post that isn't scheduled returns 409 Conflict. The action is also available as the unschedule_post MCP tool, the Unschedule Post Zapier action, the Unschedule post operation in the n8n node, and the Unschedule a Post Make module.

Upload files as raw bytes — no public URL needed, no size ceiling from the API server. POST /v1/media/uploads returns a presigned PUT URL (quotas checked up front against the declared size); PUT the bytes to it, then POST /v1/media/uploads/{id}/complete to finalize the asset and queue its thumbnail. Upload-by-URL (POST /v1/media) is unchanged and remains the simplest path when the file is already hosted somewhere. See the binary upload recipe.

The MCP server gains matching create_media_upload and complete_media_upload tools (16 tools total) — useful for agents that can run an HTTP PUT, like Claude Code and other CLI/IDE assistants working with local files.

Read your performance data programmatically with three new endpoints, all requiring the analytics:read scope:

• GET /v1/analytics/workspace — aggregated summary across all channels: total followers, average engagement, posts published, and like/comment/share totals for the range (defaults to the last 30 days).
• GET /v1/analytics/channels/{id} — daily profile metrics for one channel: followers, engagement rate, impressions, reach, profile views, website clicks.
• GET /v1/analytics/posts/{id} — all collected daily metric snapshots for one post, plus the latest snapshot.

The Nimply public API is now available as a developer preview.

• Workspace-scoped API keys (nim_live_*) created in the Nimply app under Settings → Developers, with granular read/write scopes.
• 14 endpoints under /v1 covering workspaces, channels (including posting schedules), posts, and media.
• Full posting workflow: upload media by URL, create drafts, schedule at an ISO 8601 time or the next free queue slot, or publish immediately.
• Safe retries via the Idempotency-Key header, RFC 9457 problem details for errors, and rate limit headers on every response.

Read the quickstart to publish your first post, or browse the API reference. Endpoints may change before general availability — watch this changelog for updates.

Two additions for agencies and batch workflows:

• Approvals — POST /v1/posts/{id}/request-approval moves a draft into PENDING_APPROVAL; POST /v1/posts/{id}/approve and /reject record the decision (with an optional comment) and fire post.approval_requested / post.approved / post.rejected webhooks. List what's waiting with GET /v1/posts?status=PENDING_APPROVAL. The MCP server gains matching request_approval, approve_post, and reject_post tools.
• Bulk creation — POST /v1/posts/bulk creates up to 50 posts in one call with per-item results, so a failing item never aborts the batch. Ideal for CSV imports and RSS pipelines.

Nimply now speaks MCP. Connect Claude Code, Claude Desktop, Cursor, or any MCP-capable agent to https://mcp.nimply.io/mcp with your API key and manage your social content conversationally — 11 tools covering channels, posts, media, scheduling, and analytics. See the MCP guide for per-client setup.

The Nimply API and MCP server now support OAuth 2.1 — authorization-code flow with mandatory PKCE and dynamic client registration (RFC 7591). MCP clients with connector support (claude.ai, ChatGPT, Claude Desktop) can connect with a login-and-approve flow instead of copying API keys: the user picks a workspace, approves scopes, and access tokens work everywhere API keys do. Tokens are short-lived with rotating refresh tokens; revoke anytime. Discovery: https://api.nimply.io/.well-known/oauth-authorization-server.

PATCH /v1/posts/{id} lets you edit the content and/or title of a draft or scheduled post (requires the posts:write scope). Published posts cannot be edited; attempting to returns 409 Conflict.

Subscribe to events instead of polling: register an HTTPS endpoint via POST /v1/webhooks (scope webhooks:manage) and receive signed deliveries for post.created, post.updated, post.published, post.failed, post.deleted, and channel.disconnected. Deliveries are HMAC-signed (X-Nimply-Signature), retried 5 times with backoff, and endpoints auto-disable after repeated failures. See the webhooks guide.