What the Figma variables API actually costs
Figma's Variables REST API only runs on Enterprise, and the upgrade is billed on every seat. That quickly adds several thousand euros a year.
Most design system teams reach the same point sooner or later: a token change made in Figma should reach the build without anyone copying values by hand. Figma's own answer is the Variables REST API. The catch is the plan it requires, and how that plan is billed.
This article compares two routes from Figma variables into a build: the REST API, and a plugin that writes DTCG 2025.10 files into the company's own Git repository. The short answer is that the API is priced per seat, not per pipeline. Because it exists only on Enterprise, its real cost is the Enterprise uplift on every paid seat, plus an adapter the team has to build. For a mid-sized team that is several thousand euros a year before the first token reaches the build.
Route 1: The Variables REST API is an Enterprise feature, billed on every seat
Figma's developer documentation is direct about access: the Variables REST API "is
available to full members of Enterprise orgs". Reading variables needs a token with the
file_variables:read scope. Writing them needs file_variables:write and edit access to
the file.
A plan applies to the whole organisation, not to the one person or machine that calls the API. When the organisation moves to Enterprise, every Full and every Dev seat moves to the Enterprise rate with it. The pipeline needs one token. The invoice covers everyone.
The Enterprise uplift grows with every designer hired
At Figma's published euro list prices, billed annually, a Full seat costs €55 a month on Organization and €90 on Enterprise. A Dev seat costs €25 and €35. Collab seats cost €5 on both plans, and viewers cost nothing on either. Teams on Professional start lower still, at €16 for a Full seat, so their jump is larger.
Take a concrete team on the Organization plan: 25 Full seats for designers, 10 Dev seats for engineers who inspect designs and 4 Collab seats, at prices as of October 2026.
| Seat type | Seat count | Seat price Organization | Seat price Enterprise | Organization total | Enterprise total |
|---|---|---|---|---|---|
| Full | 25 | €55 | €90 | €1,375 | €2,250 |
| Dev | 10 | €25 | €35 | €250 | €350 |
| Collab | 4 | €5 | €5 | €20 | €20 |
| Total | 39 | €1,645 | €2,620 |
The difference is €975 a month, or €11,700 a year, and €875 of it comes from the Full seats alone. Every designer added later costs another €35 a month, while the pipeline the uplift pays for stays exactly the same size.
The API returns Figma JSON, so the team owns an adapter
The REST API does not return design tokens. It returns Figma's internal model: variables keyed by ID, values keyed by mode ID, colours as RGBA floats between 0 and 1, and aliases as a reference to another variable's ID. The model is also narrower than DTCG: Figma variables hold four types (colour, number, string and boolean), so a dimension loses its unit and composite tokens such as shadows or typography have no variable at all.
"VariableID:1:3": {
"name": "color/bg/primary",
"resolvedType": "COLOR",
"valuesByMode": {
"1:0": { "r": 1, "g": 1, "b": 1, "a": 1 },
"1:1": { "type": "VARIABLE_ALIAS", "id": "VariableID:1:7" }
}
}
A build tool such as Style Dictionary cannot use that as it stands, because the step that turns a token into platform code starts from token files, not from a design tool's internal model. Someone has to write an adapter that turns slash names into groups, IDs into token paths, floats into colour values and modes into themes. That code belongs to the team, and its cost depends on the number of tokens and target platforms.
The adapter also has to keep pace with Figma. The REST API changelog records changes it would have absorbed: personal access tokens capped at 90 days from April 2025, and new rate limits from November 2025. Each one is maintenance on code that only exists because of the API.
Route 2: A DTCG plugin with Git sync runs on the existing plan
The second route turns the direction around. Designers author tokens as DTCG 2025.10 inside Figma, in every type the format defines, and the plugin maps them onto Figma variables. The files live in the company's Git repository, which is the source of truth, not the design tool. Figma becomes one consumer of the tokens rather than their owner, so the pipeline depends on an open standard instead of on one vendor's API. Figma's Plugin API reads and writes variables without an Enterprise plan, so nothing about the Figma subscription changes.
The build then reads ordinary files from Git. Style Dictionary reads DTCG directly, so there is no adapter, and every token change arrives as a commit that is reviewed like code. The alias from the example above becomes a path a person can read:
{
"color": {
"bg": {
"primary": { "$type": "color", "$value": "{color.neutral.900}" }
}
}
}
The added cost is the plugin licence, which depends on the people who edit tokens rather than on the Figma seat count. For the example team, with a licence of €199 a month covering five token editors, the two routes compare like this:
| Per month | API route on Enterprise | Plugin route on Organization |
|---|---|---|
| Figma licences | €2,620 | €1,645 |
| Plugin licence | none | €199 |
| Adapter build and upkeep | not priced | none |
| Total | €2,620 plus adapter | €1,844 |
The plugin route costs €776 a month less, which is €9,312 a year. That is about 30% of the API route's licence bill, and the unpriced adapter only widens the gap.
Pipeline cost should not scale with headcount
The useful question for any token pipeline is what its price is attached to. On the API route it is the Figma seat count, so the pipeline costs more with every designer hired and with every change to Enterprise seat prices. On the plugin route it is the people who edit tokens, a group that is usually small and grows slowly.
That makes Enterprise a decision to take on its own merits. The plan sells real things: seat assignment through SCIM, guest access controls, and unlimited modes through extended collections where Organization stops at 20 per collection. A company that needs those gets the API with the plan, and the comparison narrows to adapter work against a plugin licence. Where none applies, the upgrade buys an API the build does not need.
Figma API or DTCG plugin: pros and cons side by side
Price is the largest difference between the two routes, but not the only one. They also disagree on which data model designers work in, and on where the tokens live.
| Figma Variables REST API | DTCG plugin with Git sync | |
|---|---|---|
| Advantages | • Syncs on a schedule or webhook, with nobody opening Figma • No tool or vendor beyond Figma | • Works on any paid Figma plan • Designers author every DTCG type in Figma, mapped to variables by the plugin • Git is the source of truth, every change reviewed like code • Figma consumes the tokens instead of owning them, so the pipeline depends on an open standard • No tool lock-in: the files are standard DTCG, so tools can be switched at any time • No adapter: build tools read DTCG directly • Git access set up centrally, with the target branch set individually • Licence follows token editors, not Figma seats |
| Disadvantages | • Enterprise on every paid seat • Tokens stay in Figma's own model, limited to four types • An adapter from that model to DTCG, built and maintained by the team • Tokens live in the Figma file, outside Git review • Every REST API change lands on the team's code | • One more tool, with its own licence |
What if the company already pays for Figma Enterprise?
Does the CI job need its own Figma seat?
Do developers need a plugin seat on the plugin route?
The Figma Variables REST API documentation is the primary source for the plan and seat requirements, and Figma's pricing page for the seat prices used here. The plan comparison in Figma's help centre lists what Enterprise adds, the REST API changelog records the changes named above, and the DTCG 2025.10 Format module defines the files the plugin route writes.


