How to Connect an API to a UI Design in 2026 (5 Ways)
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.
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.
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.
Quick picks by job
| If you need | Use |
|---|---|
| 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 |
How we compared them
- Where the API call happens, and whether secrets stay out of the design file
- Whether the data is a snapshot or live
- How much layout has to respond to the data, not just text
The 5 ways to get real data into a design
1. 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 and cons
- Real content inside the design file
- No app or prototype needed
- Easy to re-run when the data changes
- Snapshot only, not live
- Requires a plugin or a small script
2. 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 and cons
- Native and easy to switch between modes
- Good for themes and plan comparisons
- No code for the designer
- Not built for large or changing datasets
- Manual updates
3. 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 and cons
- Live external events in a prototype
- Good for hardware and multi-screen demos
- No production build needed
- Not a production runtime
- Setup is more involved than a plugin
4. 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 and cons
- Truly live data in a published site
- No separate app needed
- Design and site stay together
- Requires JavaScript for the component
- Limits on data fetching and secrets
5. 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 and cons
- States for loading, empty, error and success
- No credentials in the design file
- Same file on web and mobile
- The app still writes the API code
- Not a data-fetching tool
You have read the list. The one we make is one click away.
Free Community plan. One open .exode file that runs in React, Vue, Svelte, Angular, Solid, React Native, SwiftUI and Flutter.
Also worth a look
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.