Changelog

Your workspace's link pages — the Nimply Pages published at nimply.link/<handle> — are now available through the public API, the MCP server, and the Zapier, Make and n8n apps.

New scopes: links:read and links:write (opt-in; existing keys are unchanged).

Endpoints under /v1/link-pages: list pages, get a page with its blocks, update title/bio/SEO, add/update/delete blocks, publish, and read analytics (paid plans). Blocks that can be created through the API: LINK, TEXT, SECTION, POST_CARD, PRODUCT, COUPON, COUNTDOWN, NOTICE_BAR, FAQ, TESTIMONIAL. Changes are saved to the page draft and go live at the public URL only after POST /v1/link-pages/{id}/publish (live within about a minute).

MCP tools: list_link_pages, get_link_page, add_link_block, update_link_block, publish_link_page. See the Link pages reference and the recipe Add a link to your page when a video goes live.

The MCP server sent a JSON Content-Type header on every request, including actions that carry no body. The API rejects an empty JSON body, so publish_post, unschedule_post, request_approval and publish_link_page returned HTTP 400 from the MCP server even though the same calls worked through the REST API. The server now declares a JSON body only when it sends one. No change to the API itself.

Every tool on the Nimply MCP server (https://mcp.nimply.io/mcp) now publishes the standard MCP annotations — readOnlyHint, destructiveHint, idempotentHint, and openWorldHint — alongside its title. Clients that honour them (claude.ai, Claude Desktop, ChatGPT) can run read-only tools such as list_posts and get_analytics without a per-call confirmation, while tools that can put content live on a network (create_post, schedule_post, publish_post, approve_post) always ask first.

Tool names, inputs, and outputs are unchanged. The OAuth protected-resource metadata now reports the resource as https://mcp.nimply.io/mcp (the exact URL you paste into a client) and is also served at /.well-known/oauth-protected-resource/mcp; existing connections keep working.

Nimply adds no per-message charge for replies sent to WhatsApp. The 2026-09-09 entry said each reply would use AI credits from 1 October 2026; that is withdrawn. Agent runs on WhatsApp use AI credits exactly as on every other channel, and human replies are free.

Meta's own delivery charge is unchanged and separate: from 1 October 2026 Meta bills your WhatsApp Business Account per delivered reply at its published rate for the customer's country, after 1,000 free replies a month per phone number. Add a payment method in WhatsApp Manager before then or Meta stops delivering replies. Details in the WhatsApp guide.

Leads captured in Nimply now fire outbound webhooks, so Zapier, Make, n8n or your own endpoint can push them into a CRM.

• lead.created fires when a lead is captured by the Sales Lead agent, saved from the Nimply Sidekick browser extension, or added by hand. data.lead carries id, person_id, name, handle, profile_url, platform, source, temperature, interest, stage, value, currency, follow_up_at, contact_email, contact_phone, lost_reason, created_at and updated_at.
• lead.stage_changed fires when a lead moves between NEW, CONTACTED, QUALIFIED, PROPOSAL, WON and LOST. data carries the same lead object plus previous_stage and stage.
• Both events can be selected when creating or updating a webhook (events: ["lead.created", "lead.stage_changed"]).

Leads and people remain app-only: there are no public People endpoints, and no inbox or AI-generation endpoints, by design.

Meta approved Nimply's whatsapp_business_messaging and whatsapp_business_management permissions, so every workspace on a paid plan can now connect a WhatsApp Business number (Creator 1, Growth 3, Agency 10).

• Channels of type WHATSAPP_BUSINESS appear in GET /v1/channels with capabilities.publish: false and capabilities.analytics: false. The post endpoints reject them with CHANNEL_NOT_PUBLISHABLE, as documented on 2026-08-31.
• Customer chats land in the unified inbox; the Customer Support, Sales Lead and Personal DM agents bind to the channel. Inbox and agent behaviour is app-only — there are no public inbox endpoints.
• Nimply adds no per-message charge for WhatsApp replies (see the 2026-09-16 entry — an earlier version of this note said replies would use AI credits from 1 October 2026). Meta bills delivery to your own WhatsApp Business Account.

See the WhatsApp guide.

Two additive changes, both backwards compatible.

New scopes: ideas:read and ideas:write. The scope catalog gains two values for the Ideas boards (the content-planning kanban):

• ideas:read — read boards, columns and labels.
• ideas:write — create cards on them.

They can be selected when creating an API key in the Nimply app under Settings → Developers, and they appear in scopes_supported in the authorization-server metadata at /.well-known/oauth-authorization-server. Existing keys are unaffected: the default scope set is unchanged, and no existing endpoint started requiring them.

POST /v1/media accepts an optional sourceUrl. When you import a file by URL, you can now record the page it was found on:

{
  "url": "https://cdn.example.com/launch-banner.png",
  "name": "launch-banner.png",
  "sourceUrl": "https://example.com/blog/launch"
}

The value is stored as import provenance on the asset (alongside a source marker) purely for attribution inside the workspace. Nimply never fetches it, and it is not returned in the media response. The field is optional — requests that omit it behave exactly as before.

Telegram is now a channel type. Two new values can appear in a channel's type:

• TELEGRAM_CHANNEL — a Telegram channel or group the workspace connected by adding the Nimply bot as an administrator. It is a full publishing channel: POST /v1/posts accepts it like any other platform, and it reports capabilities.publish: true and capabilities.analytics: true.
• TELEGRAM_BUSINESS — the owner's personal Telegram direct messages (inbox-only). It reports capabilities.publish: false and is rejected by the post endpoints with CHANNEL_NOT_PUBLISHABLE, exactly like WhatsApp.

The capabilities object on channel responses gains two flags:

• capabilities.editAfterPublish — the platform lets a post be changed after it is live. Today only Telegram channels and groups report true; every other platform keeps its immutable-once-published behaviour and reports false.
• capabilities.deleteAfterPublish — the platform lets a live post be removed afterwards. Again true for Telegram only.

Both are additive. Enum consumers that switch on type should treat unknown values as a generic channel, as the API guide has always recommended.

Channel objects returned by GET /v1/channels and GET /v1/channels/{id} now include a capabilities object:

• capabilities.publish — whether posts can be created for and published to this channel. Today every connectable platform supports publishing; messaging-only platforms we add in the future (such as WhatsApp) will report false, and the post endpoints will reject them with a CHANNEL_NOT_PUBLISHABLE error. If you build channel pickers on top of the API, filter on this flag instead of assuming every channel is postable.
• capabilities.analytics — whether the analytics endpoints return data for this channel.

This is an additive change: existing fields and behavior are unchanged.

Two follow-ups to yesterday's TikTok Business API migration:

• New optional field uploadToDraft on POST /v1/posts/tiktok: send the post to the creator's TikTok inbox as a draft instead of publishing it — the creator finishes and posts it from the TikTok app. This is the only path for private TikTok accounts, which cannot be published to publicly via the API. When uploadToDraft is true, TikTok ignores the other post settings (cover, interactions, disclosure) — those are chosen in the app while finishing the draft.
• allowComments, allowDuet and allowStitch are now optional in behavior: when omitted, the post follows the TikTok account's own settings (interactions enabled unless the account disables them). Explicit values are still honored — except that a setting the account has disabled is always sent as disabled, per TikTok's rules. Previously an omitted value published the interaction as off.

Nimply's TikTok integration moved to the TikTok Business API (Accounts API). What this means for POST /v1/posts/tiktok:

• privacyLevel is now optional and deprecated. TikTok's Business API publishes posts publicly — the platform no longer accepts a per-post privacy level through the API. The field is still accepted for backward compatibility but is ignored.
• New optional field uploadToDraft (coming to the typed endpoint shortly): send the post to the creator's TikTok inbox as a draft instead of publishing directly. This is the path for private TikTok accounts, which cannot be published to publicly via the API.
• GET /v1/channels/{id}/tiktok/creator-info keeps its response shape. Use privacy_level_options to detect private accounts: if the list has no PUBLIC_TO_EVERYONE, direct publishing will fail and drafts are the alternative.
• All other fields (allowComments, allowDuet, allowStitch, brandContent, brandOrganic, media rules) behave as before.

TikTok channels connected before this change must be reconnected by their workspace owners — the old app's tokens cannot call the Business API. Affected channels show as Needs reconnect and their scheduled TikTok posts were moved back to drafts, ready to reschedule after reconnecting.

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.