Framer CMS API: A Developer's Guide

Search "framer cms api" and you'll land on a mix of official docs, a Reddit thread asking if it even exists, and a community post literally titled "Shipped: CMS API (via Plugins)." That title is the answer. There is a Framer CMS API, but it isn't a public REST endpoint you can hit from an external server. It's a programmatic interface exposed to plugins running inside the Framer editor, and that distinction decides what you should try to build.

What "Framer CMS API" Actually Means

When people search for a "CMS API," they usually picture something like a headless CMS: an API key, a REST or GraphQL endpoint, and the ability to curl your content from anywhere. Framer's CMS doesn't work that way, and you should know that before you scope a project around it.

What Framer does provide is a Plugin API with CMS-specific methods, getCollections(), methods to read collection fields and items, and methods to add or update items programmatically. This API runs inside the context of a plugin operating within the Framer editor, authorized by the person using it. It's the same interface that powers marketplace plugins that sync, import, or manage CMS content, including the official CMS Starter plugin Framer ships as a reference implementation.

There is also a second surface, the Server API, which you call from your own infrastructure using a project-scoped API key you create inside the Framer project's settings. It reaches collections and their items, item draft state, and site publish and deploy.

We know that one first-hand rather than from documentation. is our product, and its backend runs against the Server API in production: connect a project with its URL and an API key, load the collections and their draft items, and at the scheduled minute flip the item out of draft and publish. Framer still describes the Server API as open beta, so treat every endpoint and signature as movable, and do not sell a client an integration on the assumption it will stay put.

So the split is: Plugin API for anything that happens with the editor open and a person present, Server API for anything that has to happen while nobody is looking. This guide covers CMS data on both. The wider developer surface, the plugin system itself, canvas APIs, what a plugin can do beyond the CMS, is covered in our .

What You Can Actually Build With It

Because the API is plugin-scoped, the realistic use cases look like this:

• Bulk import/export tools, a plugin that reads a spreadsheet or external database and writes items into a CMS collection, saving the one-by-one manual entry that native Framer CMS requires.
• Content sync plugins, reading from Notion, Airtable, or a custom backend and pushing updates into a Framer collection, either on-demand or on a schedule triggered from within the plugin's UI.
• Content audit and QA tools, scanning a collection for missing fields, broken references, or inconsistent formatting before a client site goes live.
• Enhanced editing UIs, a custom plugin panel that presents CMS fields differently than Framer's native property panel, useful for non-technical clients managing complex collections.
• Filtering and search layers, reading collection data and building richer query logic (multi-field, price ranges, realtime search) than Framer's native single-condition filter supports. This is the exact mechanism is built on.
• Scheduled publishing, the one that genuinely needs the Server API rather than the Plugin API, because it has to run when the editor is closed. Our own scheduler holds a queue, checks it every minute, and un-drafts and publishes when an item comes due.

What You Can't Do (Yet)

Verified as of August 2026. The Server API is in open beta, and open betas move. Check each of these against Framer's current developer documentation before you quote a client on it.

• No unauthenticated public endpoint. There is nothing you can curl anonymously to read a Framer collection the way you can point a browser at a headless CMS's public content API. Access is always authenticated, either as the editor user (Plugin API) or with a project API key (Server API).
• No stability guarantee. Framer lists the Server API as open beta. That is not a reason to avoid it, we run a product on it, but it is a reason to write your integration so a changed signature is a small fix rather than a rebuild.
• No native webhook on CMS item change. If you need "the moment this item changes, tell my system," you are polling or triggering it yourself. We have not found a native subscription for this.
• No item-level publish. The next section covers what that does to your architecture.

If the client requirement is "our content syncs with our internal system overnight, unattended," that is now buildable against the Server API rather than impossible. It is still a build, not a setting.

Publishing is a project-level operation

We learned this from running a product on the API rather than from the documentation.

A publish triggered through the Server API is a site operation, not an item operation. The flow our scheduler runs is: take the item out of draft, then publish and deploy the project. There is no way to publish only that item, everything else sitting unpublished in the project goes live in the same deploy.

Two consequences worth designing around:

1. Keep work in progress somewhere else. If a project holds half-finished pages, an automated publish will ship them. A separate staging project is the honest answer, and it is the caveat we put on our own product page rather than in the small print.
2. Batch, don't loop. Three items due at 10:00 should become one publish and one deploy, not three. Our scheduler groups everything due per project, un-drafts them all, and then publishes once. If you write the naive loop instead, you pay for three full site deploys and the client watches the site rebuild three times.

The Permission Model

Because the CMS API runs inside a plugin rather than as a standing external service, the permission model looks different than what a headless-CMS developer expects. There's no API key to leak, rotate, or scope down, access is tied to the user actively running the plugin inside their own Framer project. When someone installs a plugin that touches CMS data, they're granting it the access that plugin's manifest declares, for as long as it's running.

The Server API has the opposite shape: there is a key, it is created inside the Framer project's settings, and it is scoped to that project. That makes it a real secret with real handling obligations. In CMS Scheduler we store it encrypted, decrypt it only server-side at the moment of use, and delete it when the user disconnects the project. If you build against this API, budget for that work, it is not optional and it is not glamorous.

That changes how you scope a build:

• You can't build a background job that runs independently of the editor. If a plugin needs to sync data nightly, it needs the user to open Framer and trigger it (or you need a separate, non-Framer backend that pushes updates some other way that doesn't rely on the CMS Plugin API at all).
• Multi-user teams share plugin access at the project level, not per-seat. If a plugin can write to a collection, anyone on the project with edit access can trigger that write.
• There's no granular field-level permission inside the CMS API itself. A plugin that can write to a collection can generally write to any field in it, scoping down to "this plugin can only touch the status field" is something you'd enforce in the plugin's own logic, not something Framer restricts natively.

None of this makes the API unsafe, it's a reasonable model for an in-editor tool. It just means "build an automated sync pipeline" and "build a plugin the user runs to sync on demand" are different projects with different architectures, and conflating them is where CMS API projects go over budget.

Common Developer Questions From the Community

A running Reddit thread titled simply "API for CMS" is a good proxy for what real builders get stuck on, and the pattern repeats across Framer's community forum too:

• "Can I query my Framer CMS from an external app?" Not directly, you'd build a plugin that reads the CMS and separately pushes that data somewhere your external app can reach, rather than pointing your app at Framer directly.
• "How do I bulk-add hundreds of items without clicking through the UI?" This is the single most common CMS API use case in practice, a small import plugin (or an existing marketplace plugin built for this) that loops through a spreadsheet or JSON file and calls the item-creation methods.
• "Can two Framer sites share one CMS?" Not natively. Each site's CMS collections are scoped to that project. Sharing content across sites means syncing between them via a plugin or an external source of truth, not a native shared-collection feature.

How to Start Building Against It

If you're building a plugin that touches CMS data, the practical path is:

1. Read Framer's official developer docs for the CMS surface, start at framer.com/developers/cms for the current method reference, since plugin APIs evolve and this guide won't stay pinned to specific method signatures.
2. Study the CMS Starter plugin. Framer ships this as a reference implementation specifically so plugin developers have a working example to build from rather than starting from empty documentation.
3. Scope your plugin's permission model early. Decide whether it needs read-only access (an audit tool) or read/write (a sync tool), this affects both the API calls you'll use and how you explain the plugin's access to end users installing it.
4. Test against a real collection with realistic field types early, not a toy example. Reference fields, multi-line rich text, and image fields all behave differently than a simple text field, and that's where most plugin bugs surface.

Where This Fits Into a Bigger Project

Most people asking about the Framer CMS API aren't planning to build a plugin from scratch, they're trying to solve a specific content problem: filtering, syncing, or bulk-managing a collection. If that's you, it's usually faster to reach for a plugin already built on this API than to build your own. uses the CMS API to add multi-field filtering, realtime search, and price-range sliders without you writing a line of plugin code. If your problem is specifically an external tool syncing into Framer CMS, look for a sync-focused plugin in the before committing engineering time to a custom build.

For a broader look at where Framer's CMS runs into walls, collection caps, filtering, code component access, our covers the rest of the picture beyond the API layer specifically.

FAQ

Does Framer have a public REST API for the CMS? Not in the traditional headless-CMS sense. There is no anonymous public endpoint. CMS content is reachable two ways: the Plugin API, running inside the editor with the user present, and the Server API, which your own server calls using a project-scoped API key created in the project settings. Framer lists the Server API as open beta.

How do plugins read Framer CMS data? Plugins use the Framer Plugin API's CMS methods to get collections, list fields, and read or write items. This runs in the context of the Framer editor with the user's permission, not as an unauthenticated public endpoint.

Can I sync an external database to Framer CMS automatically? There is no native two-way sync with Airtable, Notion or anything else. You either build a plugin the user runs in the editor, or you drive the Server API from your own backend with a project API key. Both are integrations somebody builds; neither is a switch you flip.

What's the difference between the CMS API and the Server API? The Plugin API runs inside the editor, authorised by the person using the plugin, with no API key involved. The Server API runs from your own infrastructure against a project-scoped API key and reaches collections, items, draft state, publish and deploy. Publishing through it is project-level, not item-level.

Do I need to know JavaScript to use the Framer CMS API? Yes. Plugins are built with the Framer Plugin SDK in TypeScript/JavaScript. If you're not building a plugin yourself, you can still benefit from the CMS API indirectly through plugins that already use it, like CMS Filter or a CMS-to-spreadsheet sync tool.