---
title: "Framer CMS API: A Developer's Guide"
description: "What the Framer CMS API actually is, how plugins read and write CMS data, and what you can (and can't) build with it. A practical developer guide."
canonical_url: "https://framerhub.io/blog/framer-cms-api-guide"
last_updated: "2026-10-13T00:00:00.000Z"
---

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 whole answer, and most articles bury it. Here's the straight version: **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. Understanding that distinction changes what you should actually 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 it's worth being upfront about 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's also a separate, newer **Server API** that Framer has been rolling out for site and project-level operations — publishing, deployments, project management — which is a different surface than the CMS content API. If you're trying to programmatically manage a Framer *site*, that's the API to look at; if you're trying to read or write *CMS content*, you're working with the Plugin API's CMS methods.

## What You Can Actually Build With It

Once you understand the API is plugin-scoped, the realistic use cases become clear:

- **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 [CMS Filter](/plugins/framer-cms-filter) is built on.

## What You Can't Do (Yet)

Be honest with clients about the ceiling before you scope a project around it:

- **No server-to-server access without a plugin running in-editor.** You can't set up a cron job on your own server that calls a Framer CMS REST endpoint directly the way you could with Contentful or Sanity.
- **No public API keys for arbitrary external apps.** Every CMS API interaction happens through a plugin the user has installed and is actively running, not a standing integration.
- **No guaranteed real-time webhooks out of the box.** If you need "the moment this CMS item changes, notify this external system," you're building that logic into a plugin's polling or manual-trigger flow rather than subscribing to a native webhook.

If a client's requirement is "our CMS content needs to sync automatically with our internal system every night, unattended," today's Framer CMS API isn't the right tool without a plugin actively bridging that gap — and that's an important expectations conversation to have before signing the project.

## The Permission Model, Explained

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.

This has real implications for 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. [CMS Filter](/plugins/framer-cms-filter) 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 [plugin directory](/plugins) 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 [Framer CMS limitations guide](/blog/framer-cms-limitations) covers the rest of the picture beyond the API layer specifically. And if you're evaluating Framer's developer surface more broadly, including the plugin system itself, see our guide on [what the Framer API can build](/blog/framer-api-guide).

## FAQ

**Does Framer have a public REST API for the CMS?**
Not in the traditional headless-CMS sense. Framer's CMS API is exposed through the Plugin API — plugins running inside the Framer editor can read and write collection data programmatically, but there's no general-purpose external REST endpoint for arbitrary third-party apps to query a Framer CMS collection over HTTP.

**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?**
Yes, but only through a plugin built for that purpose. There's no native two-way sync between Framer CMS and external tools like Airtable or Notion without a dedicated integration — that's exactly the gap sync-focused plugins are built to close.

**What's the difference between the CMS API and the Server API?**
The Plugin API's CMS methods operate on collection content — items, fields, references. Framer's Server API is a separate, newer surface focused on site and project-level operations rather than CMS content itself.

**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.