Figma and CodeWords: the API reads, it does not write

The most important fact about automating Figma is a constraint: the REST API reads file contents, it does not write them. Modifying a design programmatically means a plugin or a widget running inside Figma, which is a different thing to build and a different thing to distribute.

Once you accept that, the useful projects become clear. They are about getting information out — what the design system contains, what is being used, what has changed — and about connecting that to everything downstream.

What we'll cover

• Read and write are different systems
• What the Figma REST API reaches
• Connecting it to CodeWords
• Seven automations worth building
• Design tokens, and the honest version of sync
• Naming, which determines what is possible
• Handoff, which is mostly about context
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

Read and write are different systems

The REST API reads. File structure, components, styles, variables, comments, and versions. It renders images of any node. It does not change the document.

Plugins write. Code running inside Figma with access to the document, which is how anything that modifies a design works. Writing one is a separate project with its own distribution question.

Webhooks notify. File updates, comments, library publishes, and similar events, on plans that include them.

Comments are the exception. You can post a comment through the REST API, which is the one write available and the right channel for anything an automation wants to say about a file.

The practical consequence: build automation that reports, exports, and connects. If the requirement is genuinely to modify designs, that is a plugin, and it is worth being clear about that before anybody plans a timeline.

What the Figma REST API reaches

File contents as a node tree, including every layer with its properties, which is comprehensive and large.

Specific nodes can be fetched individually, which is far cheaper than retrieving a whole file.

Images can be rendered from any node at various scales and formats, which is how automated exports work.

Components and styles can be listed for a file or a published library, which is the basis of any design system reporting.

Variables cover the modern token model on plans that include them, and they are the right source for anything tokens-related.

Comments can be read and posted.

Versions can be listed, giving the file's named history.

Projects and teams can be enumerated, which is how automation finds files without hard-coded links.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which file or library, and what should come out of it.
3. Authorize the connection with a Figma token that has access to the relevant team.
4. Describe the exceptions: a component that has been renamed, a node that no longer exists, a file that has grown too large to fetch whole.
5. Run it against a library you know well and check the output against what you expect to find.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Token extraction into code. Colours, spacing, and typography from variables into whatever format your codebase consumes. The clearest win available and the one most teams build first.

Component inventory reporting. What the library contains, what is used where, and what nothing references. Design systems accumulate components nobody has used since the quarter they were added.

Detached instance reporting. Where the design system is being worked around, which is the most useful signal a design system team can get and the hardest to gather by hand.

Asset export on publish. Icons and illustrations rendered and delivered to the repository or the asset store when the library is published, so engineers are never waiting on an export.

Change digests. What changed in the library this week, in readable form, for the people who consume it rather than the people who make it.

Comment routing. Comments mentioning specific people or topics routed to where they work, since Figma comments are easy to miss and often contain decisions.

Handoff records. When a file is marked ready, assemble the links, the exported assets, and the relevant tokens into the ticket, so the engineer starts with everything.

Design tokens, and the honest version of sync

Everybody wants design and code to stay in step. It is worth being precise about what is achievable.

One direction works well. Figma variables are the source, code is generated from them, and the generation runs when the library publishes. This is reliable and it is what most teams should build.

Two-way sync does not. Code cannot write back to a Figma file through the REST API, and even with a plugin, resolving a conflict between a designer's change and an engineer's is a judgement nobody has automated satisfactorily.

Generate, do not edit. The generated token file should be produced by the automation and never hand-edited, or the next run silently reverts somebody's work.

Open a merge request rather than committing. A token change is a change to the product's appearance, and it deserves the same review as any other.

Report what changed in words. "Three colours changed, one spacing value removed" is reviewable; a diff of a generated file is not.

Handle removal carefully. A token disappearing breaks whatever used it, so report removals prominently rather than letting them merge with everything else.

Naming, which determines what is possible

The same lesson as any system built on convention, and it applies unusually strongly here.

Consistent component naming is what makes inventory reporting meaningful. Slash-separated hierarchies group properly; ad hoc names do not.

Variable naming determines the generated code. The token names in the codebase come from the names in Figma, so a careless name becomes a careless API.

Frame naming decides exports. Automated asset export depends on being able to find things by name.

Do not encode meaning in colour or position. It is invisible to anything reading the file.

None of this is technical work. It is a convention agreed by the design team, and it is the difference between automation that works and automation that needs a hand-maintained mapping.

Handoff, which is mostly about context

The moment a design becomes engineering work is where most of the avoidable back-and-forth happens, and very little of it is about the pixels.

Link the file and the specific frame, not the project. A link to a file with ninety frames is a link to a search.

Export the assets in advance. Icons and images at the required scales, in the repository, before anybody asks — this is the request that interrupts a designer most often.

Name the tokens used. Which colour, which spacing scale, so the engineer uses the system rather than reading values off the design.

Say what is not designed. Empty states, error states, and loading behaviour are the usual omissions, and naming them as open questions is more honest than letting them be discovered in review.

Attach the version. Designs change after handoff, and a reference to the version that was handed over settles the question of what was agreed.

An automation assembling these into the ticket when a frame is marked ready does not replace the conversation. It removes the part of the conversation that is fetching things.

Building it so it survives

Fetch nodes, not whole files. A large Figma file is a very large response, and requesting specific nodes is dramatically cheaper.

Match on node identifiers where you can, since they survive renaming and names do not.

Handle renames deliberately. Report a component that has disappeared rather than treating it as deleted, because most of the time somebody renamed it.

Post findings as comments. The one write the API allows is also the most useful place for an automated observation, since it appears in context.

Report the outcome. What was exported, what changed, and what could not be found.

Limits worth knowing about

No write access to file contents through the REST API. This is the constraint that shapes everything.

Rate limits apply, and large file requests are expensive against them.

Very large files are slow to fetch and the response can be unwieldy, which is the argument for node-level requests.

Variables are plan-dependent, so token automation may not be available on every tier.

Webhook availability depends on the plan, and polling for file version changes is the fallback.

Image rendering is asynchronous — you request, then retrieve — so exports need to handle waiting.

What to build first

Token extraction: variables into a generated file in your codebase, opened as a merge request when the library publishes, with a plain-language summary of what changed. It uses only read access, it removes a recurring manual transcription, and it makes design changes visible to engineering in the place where engineering works.

Two habits make the difference. Summarise the change in words at the top of the merge request, since a diff of generated tokens is unreviewable. And call out removals separately, because a removed token breaks whatever used it and it should not slide through as one line among forty.

Frequently asked questions

Can automation modify a Figma file?

Not through the REST API, which is read-only for file contents. Modifying a design requires a plugin running inside Figma, which is a separate project. The exception is comments, which the API can post.

Can design and code stay in sync automatically?

In one direction, reliably: Figma variables generate code. The reverse is not available through the API, and conflict resolution between a designer's change and an engineer's is a judgement rather than a merge. Build the one-way version and be honest that it is one-way.

How do I find components nobody uses?

Inventory the library and search the files that consume it for instances. It is the most useful report a design system team can have and it is tedious to produce by hand, which is exactly the shape of thing worth automating.

Why is fetching a file so slow?

Because you are retrieving the entire node tree, which for a mature design file is enormous. Fetch the specific nodes you need instead — the difference is usually large enough to change what is practical.

What makes a file automatable?

Consistent naming, mostly. Slash-separated component hierarchies, deliberate variable names, and named frames for anything exported. It is a design team convention rather than technical work, and nothing else substitutes for it.

Should token changes merge automatically?

No. A token change alters the product's appearance and deserves review. Open a merge request with a readable summary, and flag removals prominently since those are the ones that break things.

How do I know when a library has changed?

A webhook on library publish where your plan supports it, otherwise poll the file version. Publishing is the right trigger rather than every file update, since designers save constantly and most saves are not intended for consumption.

What should an automated handoff include?

A link to the specific frame rather than the file, exported assets already in the repository, the token names used, the version handed over, and an explicit note of what has not been designed. It removes the fetching, not the conversation.

How do I stop designs changing silently after handoff?

Record the version at handoff and report subsequent changes to that frame. Designers continue working, quite reasonably, and the problem is only that nobody downstream is told.

Related reading

• Miro and CodeWords
• Canva and CodeWords
• CodeWords integrations and templates