Framer CMS API: A Developer’s Complete Guide
The Framer CMS API is the programmatic interface that lets developers read and write content in a Framer CMS collection from outside the visual editor. The API supports importing posts in bulk, syncing content from a headless CMS or database, automating publishing workflows, and integrating Framer with the rest of a modern stack. The API is designed for developers comfortable with JSON, REST, and a small amount of TypeScript.
This guide covers the full API surface, from authentication and core endpoints to the practical patterns developers use to sync content, build importers, and automate publishing. By the end you will have a clear playbook for shipping integrations that turn Framer into a real CMS for production sites. For the visual side of the CMS, see our Framer CMS complete guide.
What the Framer CMS API Does
The Framer CMS stores structured content in collections, where each collection is a content type with a defined schema. A collection might be Blog Posts, Case Studies, Team Members, or any other repeatable content. Each entry in a collection is a record with fields, much like a row in a database table.
The API exposes these collections to external systems. You can list entries, fetch a single entry by ID, create new entries, update existing entries, and delete entries through standard REST calls. The API authenticates through a token tied to your Framer workspace, and rate limits are generous enough to support real production workflows.
When to Use the API
The API earns its place in four common scenarios. The first is bulk content migration, where you have hundreds of blog posts in WordPress or another CMS and want to move them into Framer. The second is two-way sync, where editors work in another tool like Notion or Sanity and you sync the published content to Framer for rendering. The third is automation, where a webhook from a third-party tool creates a new Framer entry when an event fires. The fourth is custom editorial workflows, where you build a small admin interface that suits your team better than the default CMS editor.
Authentication
API access requires a personal access token generated from your Framer workspace settings. Tokens are scoped to specific projects, which means a token only sees the collections in the project it was issued for. Tokens are sensitive credentials and should be stored in environment variables, not committed to source control.
Every API request includes the token as a Bearer token in the Authorization header. The pattern looks like Authorization, then a space, then the word Bearer, then a space, then the token. Requests without a valid token return a 401 response.
Token Management
Rotate tokens periodically and immediately when an integration is decommissioned. Issue separate tokens for separate integrations so you can revoke a single integration without breaking others. Audit token usage through the workspace admin panel, which shows the last time each token was used.
Core Endpoints
The API exposes a small set of endpoints that cover the full read and write surface of the CMS.
List Collections
The collections endpoint returns the list of collections in a project, including their schema. This is the first call most integrations make to understand the shape of the content they are working with. The response includes collection IDs, names, and field definitions for each collection.
List Entries
The entries endpoint returns the records in a single collection. It supports pagination through cursor-based pagination, filtering on field values, sorting, and selective field projection. For large collections, always use pagination rather than fetching all entries in one call.
Get a Single Entry
Fetching a single entry by ID returns the full record with all fields populated. This is useful for detail views in custom admin tools and for debugging schema issues during development.
Create Entry
The create endpoint accepts a JSON payload with the fields for the new entry and returns the created entry with its assigned ID. Required fields must be present in the payload. Optional fields default to null or empty if omitted.
Update Entry
The update endpoint accepts a partial JSON payload and updates only the fields included in the request. Fields not in the payload are left unchanged. This is useful for syncing only the fields that changed in your source system rather than rewriting the entire entry every sync.
Delete Entry
The delete endpoint removes an entry permanently. Deletes are not soft deletes, so be careful. For workflows where deleted content might need to be restored, archive the source data outside Framer before issuing the delete.
Field Types and Data Mapping
Framer CMS supports plain text, rich text, numbers, dates, booleans, single and multi-select options, image URLs, file URLs, color values, references to other collections, and arrays of any of those types. When syncing from another system, the most common challenge is mapping the source data types to the Framer field types correctly.
For rich text, Framer expects a structured format that supports headings, paragraphs, lists, links, and inline emphasis. If your source system stores HTML, you will need to parse the HTML and emit the equivalent structured format. Several open-source libraries handle this conversion. For Markdown sources, the conversion is more direct because Markdown maps cleanly to the Framer rich text structure.
Image and File Fields
Image and file fields store URLs that point to publicly accessible resources. The most reliable pattern is to upload assets to a CDN like Cloudflare R2, AWS S3, or Bunny CDN, then store the resulting URL in the Framer field. Uploading directly into Framer asset storage is supported but has tighter size limits.
For migrations from WordPress, where images are stored in the WordPress media library, the standard pattern is to download each image, re-upload to your chosen CDN, and rewrite the URLs in the Framer entry. Skipping this step results in broken images if the source WordPress site goes offline later.
Common Integration Patterns
Three integration patterns cover most real-world use cases.
Pattern One: Bulk Import
You have a large amount of existing content and you want to move it into Framer once. Write a script that reads from your source, transforms each record into the Framer schema, and calls the create endpoint in batches. Use exponential backoff on retries to handle transient errors. Log the source ID, target Framer ID, and timestamp for each successful import so you can resolve issues later.
For a typical migration of one thousand blog posts from WordPress, the import takes thirty minutes to two hours depending on rate limits and asset handling. Run the import on a development project first to validate the schema mapping, then re-run on production.
Pattern Two: Two-Way Sync
Editors work in a primary CMS like Notion, Sanity, or Contentful and you want the published content to appear in Framer for rendering. The cleanest implementation uses webhooks from the source CMS to trigger sync jobs. When an editor publishes a post, the webhook fires, your sync service fetches the latest version from the source, and writes it to Framer through the API.
For two-way sync where editors might also update content directly in Framer, you need a conflict resolution strategy. The simplest approach is to designate one system as the source of truth and treat changes in the other system as overwrites. More complex approaches use last-modified timestamps or merge logic, but the simple approach handles most real-world scenarios.
Pattern Three: Webhook-Driven Automation
An event in a third-party tool creates a new Framer entry. Examples include a new podcast episode publishing in Buzzsprout creating a new entry in the Framer Podcast Episodes collection, or a new Stripe customer creating a new entry in a Customers collection. The pattern uses a thin serverless function as the glue between the source webhook and the Framer API.
Most teams build these on Vercel, Cloudflare Workers, or Netlify Functions. The function receives the webhook payload, transforms it into the Framer schema, and calls the create endpoint. Total round-trip time is usually under a second.
Rate Limits and Error Handling
The Framer API rate limits are generous for typical use cases but real. Plan for occasional 429 responses on bulk operations and implement exponential backoff. The standard pattern is to retry after the duration specified in the Retry-After response header, doubling the wait time on each subsequent failure up to a maximum of sixty seconds.
Other error responses follow standard HTTP semantics. A 400 means your request payload is malformed. A 401 means your token is invalid or expired. A 404 means the resource does not exist. A 422 means the request was understood but the data failed validation, often because of a required field being missing or a field value not matching the schema. A 500 means a server-side issue and is usually transient.
Logging and Observability
For production integrations, log every API request with the timestamp, endpoint, response code, and request duration. When something goes wrong with a sync at 2am, you will be glad you have the logs. Tools like Axiom, Logtail, and Datadog all work well for this kind of structured logging.
Building a Custom Admin UI
Some teams want an editing experience tailored to their workflow rather than the default Framer CMS editor. The API makes this possible. Build a small Next.js or React application that authenticates against the API and presents a custom form for creating and editing entries. The custom UI can enforce business rules, prepopulate fields based on context, or surface preview links to the rendered Framer page.
This pattern is most common in agencies managing multiple Framer sites for clients, where a unified admin panel across all clients beats logging into each Framer workspace separately. It is also useful for teams with non-technical content authors who would benefit from a more constrained editing experience.
Practical Examples
Here are three specific scripts that solve common problems.
- WordPress to Framer migration: A Node.js script that reads the WordPress REST API, transforms each post to the Framer schema, uploads images to Cloudflare R2, and creates entries via the Framer API.
- Notion sync: A serverless function on Vercel that listens for Notion database changes and syncs published pages to a matching Framer collection.
- Stripe customer mirror: A webhook receiver that creates or updates a Customers collection entry in Framer every time a Stripe customer is created or updated.
Each of these is a few hundred lines of code at most. The API is small and the patterns are well understood.
Frequently Asked Questions
Is the Framer CMS API publicly available?
Yes, on Pro and higher Framer plans. Authentication uses personal access tokens generated from your workspace settings. The free tier does not include API access.
What programming languages can I use?
Any language that can make HTTP requests. The API is REST over JSON, so JavaScript, TypeScript, Python, Ruby, Go, and PHP all work. Most published examples use TypeScript because Framer is TypeScript-friendly and the type definitions help catch schema errors at compile time.
Can I update content in real time?
Updates through the API take effect immediately in the CMS, but Framer rebuilds and redeploys the published site asynchronously. Typical rebuild times are thirty seconds to two minutes depending on site size. For real-time content like live blogs or scoreboards, a static rebuild may not be the right architecture.
Where do I get help if I get stuck?
The official Framer developer documentation covers the API in detail. The Framer Discord has an active developer channel where the platform team and other developers answer questions. For agency-grade integrations, our team at Framer Websites builds custom Framer CMS API integrations as part of larger engagements.
Need a custom Framer CMS API integration built for your team? Talk to Framer Websites about a scoped engagement, or browse our pricing options for full-site builds.