Framer setup

The Framer connector creates CMS entries, flagged as drafts, in a collection in your Framer project. Framer excludes drafts from publishing, and BirchSeek never publishes or deploys your site — so nothing goes live until you press Publish in Framer.

Not available yet, for anyone. Framer publishes no REST API. The only supported client is Framer’s own Node SDK, which speaks a private frame format over a stateful WebSocket, so BirchSeek reaches Framer through a small internal bridge service that holds that SDK. That bridge is not running. Its address is a single deployment-wide setting, left blank, which switches the connector off for everyone rather than for particular accounts: the connection test cannot pass and a publish fails immediately, saying the bridge is unconfigured rather than half-working or blaming your key. That is why Framer is listed as planned on our integrations page rather than live - the connector is written and tested against the bridge contract, but we will not claim it works before it has been proven end to end against a real project. Everything below is what it will do, published now so you can judge whether it is worth waiting for. If you want to be an early user, get in touch.

Step 1 - create an API key

1. Open your project in Framer.
2. Press ⌘K and run open settings, or use the project menu, to reach Site settings → General.
3. Find the API Keys section, Create a key, name it BirchSeek, and copy it.

Two properties of Framer keys worth knowing:

• A key is bound to one project. If you publish to two Framer sites, you need two keys and two connectors.
• A key authenticates as the person who created it. If that person loses access to the project, the key stops working.

You also need the project URL — the https://framer.com/projects/YourSite--aabbccdd1122eeff3344 address from your browser’s address bar. If you work on a branch, include ?branch=…; BirchSeek reads it and writes to that branch rather than main.

Step 2 - map your collection’s fields

Like Webflow, Framer collections are built by you, so BirchSeek has to be told which field is which. Pick the collection first — the connection test lists the ones in your project — then map:

Setting	Required	Notes
Title field	yes	A Text field
Body field	yes	Must be a Formatted text field — this receives the article
Excerpt field	no	Text; receives the meta description
Date field	no	A Date field
Tags	no	See below — Framer has no free-form tag primitive
Owner field	no	A Text field of its own — see below
Blog path prefix	yes	e.g. /blog, or / if articles live at the site root

The owner field is how BirchSeek recognises its own entries. Nothing on a Framer CMS item records who created it, so if you add a Text field used for nothing else, BirchSeek writes the article’s id into it on every write and can then tell its own entries apart from ones you wrote by hand. Add it to the collection, leave it off your page design, and map it here.

Leaving it blank is safe, and it is the default. Without it BirchSeek will only ever update an entry whose id its own last publish returned — it never matches on the slug, so it can never touch an entry of yours that happens to share one. What you give up is recovery from a rare interruption: if a publish is cut off after Framer accepted the new entry but before BirchSeek recorded its id, the next run adds a second entry at that slug for you to delete. With the owner field mapped, BirchSeek finds the first entry, checks the field names this article, and updates it instead.

Tags need a deliberate choice, because Framer offers three different shapes and none of them is a plain tag list:

• Text — the tags are comma-joined into one text field. Simplest, always works.
• Option — a single-value enum. Framer cannot invent a new case at write time, so BirchSeek reads your field’s real options during the connection test and writes a tag only when it matches one. Anything else is left blank: losing a tag is better than losing the article.
• Reference — a multi-reference into a separate Tags collection. BirchSeek matches your tag names against existing items in that collection and links the ones it finds. It never creates tag items, because adding rows to your collection is not something a publishing tool should do unasked. This mode requires a multi-reference field; a single-value reference field cannot hold an article’s tags.

Step 3 - send a test

While the bridge is unconfigured this test cannot pass. It fails at once and names the missing bridge, rather than reporting a key or mapping problem you do not have. What follows is what it does once the bridge is up.

Send a test opens a real Framer session. Framer’s WebSocket handshake succeeds even with a bogus key, so nothing short of a real call proves anything: the test reports your project name, the collection, its fields, and where articles will appear once your site is published. It re-checks every field mapping, so a renamed or deleted field is caught here rather than inside a publishing job hours later.

What BirchSeek writes

Per article, one addItems call into your collection:

• slug, and the complete mapped field set
• the body as Markdown, ## Sources block and all, which Framer converts to its own rich-text blocks
• draft: true on create

The complete field set matters: Framer merges the fields you send rather than replacing the item, so anything BirchSeek omitted would keep a stale value from the previous run. Every mapped field is written on every run, including clearing one that now has no value.

On a refresh run the same item is updated in place, and the draft flag is not sent at all — so an entry you reviewed and un-drafted stays live rather than silently disappearing from your next publish.

Your mapped body field ends with a ## Sources block — once the bridge is up and this connector can run at all: a numbered list pairing each verified claim with the page it was checked against, converted into Framer’s rich-text blocks with the rest of the article. BirchSeek composes that body once, before any connector sees it, so every connector publishing to your own site writes the same block - there is nothing to append yourself. (A syndicated copy to dev.to, Hashnode or Medium carries the same block, and the canonical link back to your page besides. That copy is not covered by the project setting: those three platforms have no citation field of their own, so the body is the only place the evidence can travel.) The block is on by default, and there is no switch for it in the dashboard: it is a project setting called append_sources_section, and the only way to change it today is PATCH /v1/projects/{id} carrying the whole settings object, because that request replaces the object rather than merging into it.

Caveats

• BirchSeek never reports a live URL for Framer. The API returns an item id and a slug, never a URL, and the entry is not on your site until you publish the project. The connection test shows a predicted URL from your site’s production domain and blog path prefix so you can check the shape; it is never handed onward as the article’s canonical.
• No SEO fields. Framer’s CMS API exposes no canonical, no meta title and no meta description. Whatever SEO BirchSeek can set is limited to fields you created yourself and mapped — which is why the field mapping is explicit rather than inferred.
• Images in the article body are not carried over. A Framer image field needs an asset uploaded into Framer’s media library with explicit dimensions, so image blocks are skipped rather than emitted broken.
• Read-only collections. A collection owned by another Framer plugin cannot be written to. The connection test catches this and says so.
• Beta, and unpriced. Framer’s Server API FAQ says the API is “free of charge” during the beta, and that afterwards “exact cost is TBD, but we will likely charge for this API on a per-use basis, with a monthly free allowance” (read on 30 August 2026). Framer does not say whose account that usage is billed to. Our reading is that it lands on yours, because the key BirchSeek publishes with is one you created in your own Framer site settings, and sessions rather than requests are the billable unit. Check Framer’s current pricing before you rely on this; it is their number to set, not ours.

Troubleshooting

• “framer rejected the api key” - the key was revoked, or its creator lost access to the project. Create a new one.
• “no collection … in this project” - collection ids change when a collection is recreated. Pick it again from the connection test’s list.
• “framer session capacity” - Framer’s headless session pool is full, or the key hit its concurrent-session cap. Retried automatically with backoff.
• A field mapping error after a rename - Framer field ids change when a field is deleted and recreated. Re-run the connection test and re-pick the field.