---
title: "The Framer API: What You Can Build"
description: "Framer actually has three distinct developer surfaces. Here's what the Plugin API, Server API, and Code Components each let you build — with real limits."
canonical_url: "https://framerhub.io/blog/framer-api-guide"
last_updated: "2026-10-16T00:00:00.000Z"
---

"Framer API" is one search term hiding at least three different developer surfaces, plus one common mix-up with an entirely different product. Before you go looking for documentation, it helps to know which one you actually need.

## The Three (Real) Framer Developer Surfaces

**1. The Plugin API** is what powers everything in the Framer Marketplace — CMS Filter, Components, Gallery Kit, and every other plugin you've installed inside the editor. It lets developers build tools that run inside Framer's canvas: reading and writing CMS data, manipulating layers, building custom UI panels, and reacting to what's selected on the canvas. If you want to build something a user installs and interacts with *inside* Framer, this is the API.

**2. The Server API** is a newer, separate surface for automating operations at the site and project level — publishing, managing projects, and other operations that happen outside the visual editor entirely. Framer publishes example code for this on GitHub, and it's aimed at teams who want to script or integrate Framer project management into their own tooling, rather than build an in-editor plugin.

**3. Fetching external APIs from inside Framer** is the third, most common case for regular site builders: using `fetch` inside a code component or override to pull data from a third-party API (weather, exchange rates, a custom backend) and render it on a live Framer site. This isn't a "Framer API" in the sense of Framer exposing something — it's standard JavaScript `fetch`, running inside Framer's code component environment, hitting whatever external API you point it at. Framer's own academy has a lesson specifically on this pattern because it's such a common first question for builders moving from no-code to code components.

## Framer API vs. Framer Motion — Clear This Up First

If you searched "framer api" hoping to find animation documentation, you likely want a different product. **Framer Motion** — now rebranded simply as **Motion** — is a widely used open-source animation library for React, originally built by the Framer team but functioning as its own independent product with its own docs and API. It shares a name with Framer the website builder for historical reasons, not because they're the same system.

If you're building animations with code (in React, Vue, or elsewhere) and searching for spring physics, gesture handling, or animation orchestration APIs, you want Motion's documentation, not Framer's developer/plugin docs. If you're building *inside* the Framer website builder and want to automate, extend, or integrate with it, you want one of the three surfaces above. Conflating these is the single most common source of confusion in this search term, so it's worth the one paragraph of disambiguation before diving into either.

## What You Can Realistically Build With the Plugin API

The Plugin API is the surface most people actually mean when they ask "what can I build with the Framer API." Realistic plugin categories include:

- **CMS tools** — import, sync, filter, and audit tools that read or write collection data. (Covered in depth in our [Framer CMS API guide](/blog/framer-cms-api-guide).)
- **Design system utilities** — plugins that enforce spacing, color, or typography consistency across a project by inspecting and adjusting selected layers.
- **Content component libraries** — like FramerHub's own [Components](/plugins) plugin, which lets you search, drag, and drop pre-built elements directly inside the editor without leaving Framer.
- **Workflow accelerators** — bulk-renaming layers, exporting design tokens, or generating boilerplate structure for a new page type.

The constraint to plan around: everything runs inside the editor, scoped to the user actively running the plugin. There's no background execution, no server-side cron job, and no access outside the project the user has open. If your idea requires automation independent of someone actively using Framer, you're looking at the Server API instead, or a hybrid architecture where an external service does the automation and a lightweight plugin handles the in-editor side.

## What the Server API Actually Covers

The Server API is aimed at a narrower, more technical audience: teams managing many Framer projects who want to script operations rather than click through the UI for each one. Based on Framer's own example repository, realistic Server API use cases include:

- **Scripted publishing workflows** — triggering a publish as part of a broader CI/CD-style process rather than manually clicking "Publish" in the editor.
- **Project provisioning at scale** — useful for agencies spinning up many similar client projects from a template pattern.
- **Integrating Framer project state into internal tooling** — surfacing project status, ownership, or metadata inside an internal dashboard instead of manually checking Framer's own interface.

This is genuinely new territory for Framer as a platform, and documentation is still maturing relative to page builders or CMSs that have had server-side APIs for a decade. If you're evaluating whether it can support a specific automation, the most reliable path is testing against the official example repository rather than assuming parity with more mature server API ecosystems.

## Fetching Data Into a Live Framer Site

For the majority of people who land on "framer api" without meaning to build a plugin at all, the actual need is simpler: showing dynamic, external data on a page. This is handled with standard `fetch` calls inside a code component or code override — no special Framer-specific API required. Common real examples:

- Displaying live pricing or exchange-rate data
- Pulling reviews or ratings from a third-party service
- Rendering a custom calculator or configurator backed by an external calculation service

The pattern is the same as fetching data in any React-based frontend: call the endpoint, handle loading and error states, and render the response. Framer's constraint here isn't really about an "API" — it's about making sure the fetch happens in a code component (which supports arbitrary JavaScript) rather than trying to do it through native, no-code Framer elements, which don't support arbitrary network calls.

## Common Mistakes People Make Scoping "Framer API" Projects

After enough client conversations that start with "can we just use the Framer API for this," a few recurring mistakes stand out:

- **Assuming plugin access means server access.** A plugin that can read and write CMS data cannot, on its own, expose that data to an external app over HTTP. If the actual requirement is "our internal dashboard needs to read Framer CMS content," the plugin is one half of the architecture — you still need a place for that data to land that your dashboard can query, whether that's a database the plugin pushes to or a scheduled export.
- **Underestimating how "in-editor only" changes an automation plan.** Plugin API workflows require a human to have Framer open and the plugin running. If a workflow needs to run unattended overnight, that's a Server API or external-service problem, not a Plugin API one — and realizing this after scoping the project as a simple plugin build is an expensive mistake to catch late.
- **Treating the Server API as feature-complete with mature platforms.** Because it's newer, don't assume it has parity with the server APIs of platforms that have supported headless operations for a decade. Verify specific operations against Framer's current example repository before committing to a timeline.
- **Confusing "code component" with "API."** A code component using `fetch` to call a weather API isn't using anything Framer-specific — it's plain JavaScript running in a supported environment. This matters because the troubleshooting path is different: bugs here are usually standard fetch/CORS/async issues, not Framer API quirks, and treating them as the latter wastes debugging time.

## Choosing the Right Surface for Your Project

A simple way to sanity-check which surface actually fits: ask who or what triggers the action, and where it needs to run.

<table>
<thead>
  <tr>
    <th>
      Trigger
    </th>
    
    <th>
      Runs where
    </th>
    
    <th>
      Surface
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      User clicks something inside Framer's editor
    </td>
    
    <td>
      Inside the editor
    </td>
    
    <td>
      Plugin API
    </td>
  </tr>
  
  <tr>
    <td>
      A scheduled job or external system, no human involved
    </td>
    
    <td>
      Outside the editor
    </td>
    
    <td>
      Server API
    </td>
  </tr>
  
  <tr>
    <td>
      A visitor loads the live published site
    </td>
    
    <td>
      On the live site
    </td>
    
    <td>
      <code>
        fetch
      </code>
      
       inside a code component
    </td>
  </tr>
  
  <tr>
    <td>
      You want animation/gesture code, not a Framer integration
    </td>
    
    <td>
      Anywhere in a React/Vue app
    </td>
    
    <td>
      Motion (unrelated library)
    </td>
  </tr>
</tbody>
</table>

If you can't cleanly place your idea in one row, it's usually a sign the project needs two of these working together — most commonly a Plugin API tool feeding data to an external service, with a Server API or scheduled job handling the unattended half.

## Where to Start

If you're trying to figure out which of these applies to your project:

1. **Building something a Framer user installs and runs inside the editor?** → Plugin API.
2. **Automating site or project operations from outside the editor entirely?** → Server API.
3. **Displaying external, dynamic data on a live site you're building?** → Standard `fetch` inside a code component.
4. **Looking for animation code, not a Framer-specific integration?** → You want Motion, not Framer's developer docs.

For most freelancers and agencies, the practical answer is usually "I don't need to build any of these — I need a plugin that already solved this." Browse the [plugin directory](/plugins) before committing engineering time to a custom Plugin API or Server API build; it's very likely someone has already shipped the specific integration you're trying to build.

## FAQ

**What does 'the Framer API' actually refer to?**
It's not one thing. Framer exposes a Plugin API for building in-editor tools, a Server API for automating site and project operations, and support for fetching external APIs inside code components and overrides. Which one you need depends on what you're building.

**Is Framer API the same as Framer Motion?**
No, and this is the most common confusion. Framer Motion (now just "Motion") is a popular open-source animation library for React, unrelated to the Framer website builder's own developer APIs. If you're searching for animation code, you likely want Motion's docs, not Framer's developer API reference.

**Can I use the Framer API to automate publishing a site?**
That's what the Server API is for — programmatic site and project operations rather than in-editor tools. Framer publishes example code on GitHub for common Server API workflows.

**Do I need to be a developer to use any of this?**
To build a plugin or use the Server API directly, yes. To benefit from what these APIs enable, no — plugins like CMS Filter or Components already do the API-level work, so you get the result without writing code.

**Where do I start if I want to build a Framer plugin?**
Start with Framer's official developer docs and the CMS Starter plugin as a reference implementation, then scope a small, single-purpose plugin before attempting anything broad — narrow plugins ship faster and are easier to get approved on the marketplace.