# How to Connect an API to a UI Design in 2026 (5 Ways)

> Use a Figma plugin or the REST API to pull a snapshot of real data into frames while you design. Use Figma variables when the data only changes text values. Use ProtoPie Connect to drive a prototype from an external service. Use code components in Framer or a custom front end when the data must update live. Use a runtime file such as ExodeUI when the design itself must respond to values your app passes in, with the API call safely outside the file.

*We make ExodeUI, which keeps API calls in your app code and lets the design react to the values. It is one of five approaches here; for a static design snapshot, a Figma plugin is simpler.*

Updated November 2026. Source: https://www.exodeui.com/connect-api-to-design/

Designers want real data in their work because lorem ipsum hides the problems: long names break the layout, zero states look empty, and loading states get forgotten. The constraint is that a design file should never hold an API key. So the question is not how to call the API from Figma, but where the data enters and what it is allowed to change.

## Quick picks

- Real content in your Figma frames: **Figma plugins and REST API**
- Data that only changes text values: **Figma variables**
- A prototype driven by a live service: **ProtoPie Connect**
- A site that fetches data itself: **Framer code components**
- A design that reacts to values from your app: **ExodeUI**

## The 5 ways to get real data into a design

### Figma plugins and the REST API

Best for: Pulling a snapshot of real content into frames while you design
Platforms: Figma
Price: Plugins vary; some free, some paid. The REST API is available with Figma accounts
Output: Populated frames in the design file

A plugin can read a JSON endpoint and write the values into text layers, so you design with real names, prices and edge cases. The data is a snapshot: it does not update by itself, and it should never include credentials in the plugin code. This is the most practical way to test a layout against reality without building anything.

Pros: Real content inside the design file; No app or prototype needed; Easy to re-run when the data changes

Cons: Snapshot only, not live; Requires a plugin or a small script

### Figma variables

Best for: Switching text, numbers and themes from a data source
Platforms: Figma
Price: Included with paid Figma plans; limits vary
Output: Values applied across the file

Variables are good for a small, known set of values: plan names, prices, a user's name. They are not a database. If the data changes often or has many rows, a plugin that populates frames is more practical than maintaining variables by hand.

Pros: Native and easy to switch between modes; Good for themes and plan comparisons; No code for the designer

Cons: Not built for large or changing datasets; Manual updates

### ProtoPie Connect

Best for: A prototype that is driven by an external service or device
Platforms: ProtoPie with the Connect bridge
Price: ProtoPie has a free plan and paid plans; check current limits
Output: A prototype controlled by external events

ProtoPie can receive messages from an external service, which lets a prototype respond to real events: a sensor, a second screen, a backend push. It is the closest thing to a live-data prototype without writing a front end, and it is aimed at testing flows rather than shipping them.

Pros: Live external events in a prototype; Good for hardware and multi-screen demos; No production build needed

Cons: Not a production runtime; Setup is more involved than a plugin

More: [ProtoPie alternatives](https://www.exodeui.com/best-protopie-alternatives)

### Framer code components

Best for: A published site that fetches and displays live data
Platforms: Browser
Price: Free plan; paid site plans to publish
Output: A hosted website with real data

Framer lets you add code components that fetch data at runtime, so the published site shows live values. That moves the work from design to front end, and it is the right choice when the page itself is the product page. It is not a way to get live data inside a Figma file.

Pros: Truly live data in a published site; No separate app needed; Design and site stay together

Cons: Requires JavaScript for the component; Limits on data fetching and secrets

### ExodeUI

Best for: A design that reacts to values your app passes in
Platforms: Browser and desktop editor; runtimes for web and mobile
Price: Free Community plan; Professional $29/month
Output: An open .exode file with inputs your code sets

ExodeUI keeps the API call where it belongs: in your app. The app fetches the data and passes values into the animation as inputs, and states such as loading, empty, error and success live in the file. The designer can test those states with sample values, and a developer wires the real data once.

Pros: States for loading, empty, error and success; No credentials in the design file; Same file on web and mobile

Cons: The app still writes the API code; Not a data-fetching tool

More: [Data-driven animation tools](https://www.exodeui.com/best-data-driven-animation-tools)

## Never put an API key in a design file

A Figma file, a prototype or a published design can be shared and inspected. Tokens placed there leak. The safe pattern is always the same: the request happens in code you control, and the design receives values. If a plugin needs data, run it locally with a personal token and do not commit the token into the plugin.

## Real data exposes the states you forgot

Once real values arrive, the interesting designs are the failures: no results, a 400-character name, a price that is not available, a slow response. Design those before you connect anything. A component that only handles the happy path is not ready for an API, no matter how good the default state looks.

## Frequently asked questions

### Can I connect an API directly to Figma?

Only through a plugin or the REST API, and the result is a snapshot written into frames or variables. Figma does not fetch live data by itself, and you should not store API keys in the file.

### How do I show live data in a prototype?

Use ProtoPie Connect to drive the prototype from an external service, or build a small front end that fetches the data. Prototypes are for testing the flow, not for production.

### What is the safest way to use real data in design?

Fetch it in code you control, keep credentials out of the design file, and pass values into the design. Use a snapshot for layout exploration and a real integration for behaviour.

### How do I design for empty and error states?

List every state the data can produce: loading, empty, partial, error, success and too much data. Draw each one before integration, because developers will not invent them for you.

### Can an animation react to live data?

Yes. In ExodeUI the app passes values as inputs, and the file switches states and animates accordingly. In code-based tools you write the same logic by hand.

## Related

- [Data-driven animation tools](https://www.exodeui.com/best-data-driven-animation-tools)
- [Dashboard data animation tools](https://www.exodeui.com/best-dashboard-data-animation-tools)
- [MCP servers for design](https://www.exodeui.com/best-mcp-servers-for-design)
- [ProtoPie alternatives](https://www.exodeui.com/best-protopie-alternatives)
- [State machine animation tools](https://www.exodeui.com/best-state-machine-animation-tools)