We recently found some 429 response code when using REST API. I’m not sure if we’re being rate-limited and what limit should we keep in.
I also wonder whether there are different rate-limit in different endpoints (for example GET file & GET image).
I’ve read this article An alternative approach to rate limiting ,but didn’t find the precise qps limit number.
I am also curious about the rate limit, especially for the get IMAGE endpoint. Very weird it seems nowhere to be defined in exact numbers…
I’m trying to figure this out too. I seem to be encountering an issue when building our icon library at exactly 900.
Its returning 429 for me for way lower API request numbers. Maybe it depends on the endpoint. I understand the need for rate limiting, some documentation about this would have been really nice…
1 Like
@MichaelF @Ross_Moody You can ask Figma support about this. I don’t think the API team checks the community forum often so it would be probably faster.
ok, I contacted support and received an answer including rate limits which I am allowed to share here, including the following preface:
these limits are subject to change. Another point of clarification is that they are dependent on the type of authentication used, so if someone is using OAuth the rate limits are different and are for the entire application, not per user. For context, this complexity is what has prevented us from publishing these more broadly in the past.
and here are the rate limits I received:
FILE_COST = 50; // Equates to 120 req/min and 24000 req/day per user
IMAGE_COST = 200; // Equates to 30 req/min and 6000 req/day per user
VERSION_COST = 100; // Equates to 60 req/min and 12000 req/day per user
COMMENT_COST = 20; // Equates to 300 req/min and 60000 req/day per user
WEBHOOK_COST = 20; // Equates to 300 req/min and 60000 req/day per user
TEAM_COST = 20; // Equates to 300 req/min and 60000 req/day per user
PROJECT_COST = 20; // Equates to 300 req/min and 60000 req/day per user
FILE_IMAGE_COST = 20; // Equates to 300 req/min and 60000 req/day per user
SELECTION_COST = 20; // Equates to 300 req/min and 60000 req/day per user
RECENT_FILES_COST = 10; // Equates to 600 req/min and 120000 req/day per user
Hope this helps other folks like me to at least get an idea of might be possible wrong if she/he hits a ‘rate limit exceeded’ 429 
6 Likes
What do those figures “= XX” mean? FILE_COST = 50 — is it the price $50 for “Equates to 120 req/min and 24000 req/day per user”? What does it mean?
Are those limits for OAuth 2 / SSO authorization on a per-user basis? It also contradict to statement “so if someone is using OAuth the rate limits are different and are for the entire application, not per user”?
-
These figures mean that you have an X amount of virtual “credits” or “points” that you can use to interact with the API within a specified timeframe. And every API interaction has a cost that takes those credits from a user. Judging by the numbers provided, you have 6000 credits per minute and 1 200 000 credits per day. So you can for example access 120 files in a minute, spending 50 credits per file. Alternatively you can render 30 images in a minute but you won’t have any credits left to do anything else like access files or comments within the same minute. Same with daily limits.
-
In the “per application” scenario, it is implied that you are using a personal access token, thus your whole application is a single user and has the limits of a single user. An application cannot access the API without a user access token. It’s always the user interacting with the API through the application.
1 Like
Following up question I asked above.
From the limits described above we see that there are only request limits, but nothing related to the size of requested assets (files, nodes, etc.).
We tested our solution on real design files from our Design department which has a lot of assets. We ran some tests in December and April - it had been working and we had successfully received JSON responses of as much as ~280-320Mb per request over the /v1/files/[file_key] endpoint.
But now on those requests over the same endpoint, we started getting an error from CloudFlare (Figma REST API side), that response is too big and we need to make it smaller. In the limits above there is no any word about those size limits - only requests per period of time.
We count the number of requests it is not exceeded more than 15 per day/per hour/per min. In the information above we can make as much as 120 req/min and 24000 req/day per user for files.
We also tried /v1/files/[file_key]/nodes in order to assemble the same file by node ids in this file. So we use depth 1 to get all children’s node ids and ask for 500 node ids per each request. We also make random delays of 2-10 between those requests. But it failing for no reason after downloading ~48Mb of data from the file (JSON format), when the same file size in .jig format is ~60Mb (binary tree format, compressed data).
And again — in both cases looks like there is a size of the response limit, but no word about it in provided limits.
How can we find information about it? How to resolve it? What would be the correct approach for big Figma Files (JSON responses) in that scenario?
We are testing it on a paid User account (Professional Plan Annual).
1 Like
I would suggest you to contact Figma support with this issue. The forum is primarily run by community so you wouldn’t be able to get a definitive answer here regarding the Figma’s servers.
We got feedback from the Figma Technical Support team. There is a limit of 55sec to proceed with response over GET file and GET images endpoints, it will send an error after.