Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
New Onshape API Limits
Alex_Kempen
Member Posts: 255 EDU
In case you missed it, Onshape updated their API Limits policy in the most recent update (October 10th, 2025). Onshape has always had an Annual API Call limit, but the exact amount was previously undocumented.
Unfortunately, it seems very hard to imagine developing and testing apps of any size while staying within these limits. It's also a major limitation for anyone wanting to use the API for any sort of personal tooling or automation. For example, I can no longer use the tool I have which updates my FeatureScripts to the latest std version for fear of running out of API calls.
- On the EDU side, 2,500 requests spread evenly out across the year comes out to just 6.85 requests per day.
- The limit is annual, so if you run out in January you're SOL for the rest of the year.
- There's no documented way to see your current usage, so you have to track it yourself.
- Although you can buy more requests, there isn't any transparency about pricing, and as an EDU user developing free tools for robotics teams, I'm frustrated by the prospect of having to start spend money just to maintain my existing development efforts.
Ultimately, it's very disappointing having to suddenly jump through hoops and re-architect major portions of my apps (or break out my credit card) just to meet these new, seemingly arbitrary requirements.
FRC Design Mentor - Team 1306 BadgerBots
Comments
We're in the same boat. I've been spending the past 2 months doing a complete refactor of some pretty major business applications in order to make this work without increasing expenses by 5 figures a year. We also have a tool for updating custom features and derived PS to the latest version and it's quite expensive, even with some form of caching implemented.
I agree that a major oversight in this pricing structure is development testing. We have an entirely custom framework built around Onshape's API but now unit testing any of that will need to be done very differently, probably with some premade API calls stored in a DB.
Having a way to track this information ourselves would also be great.
chadstoltzfus@premiercb.com
Hi Alex,
The APIs cost real money in compute resources, so you can understand why we need to cap usage (especially for free users). Given no constraints, we have seen users with API call behavior that is not sustainable for us, e.g. we have seen users make the same call over and over again to retrieve the same data, or hitting the API endpoints without limiting the frequency of the calls.
To your specific points:
We're working on adding a section to the product that allows every user (or company admin) to monitor their own usage - coming soon. Meanwhile, as you pointed out - you can certainly keep track of your API calls on the calling side as well.
API calls made by publicly visible apps in the Onshape App Store using OAuth2 credentials don't count towards the limits - that's documented on the screenshot you posted. If your Apps are of universal appeal and provide value to other others outside of your own personal context, you can work through https://onshape-public.github.io/docs/app-store/ to make the Apps public.
For developers who are considering creating an App in our App Store, please get in touch (onshape-developer-relations@ptc.com) - you don't need to be limited by the posted API limits.
If you are part of an EDU Enterprise (or other paid plan), you get access to higher API limits, with options to purchase more.
SVP, Onshape Product and R&D
from commercial point its clear why the limits exist, but would be nice to have some official client libraries for api interaction which would ensure best practices and ensure low server workload by caching or something. Current API testing and exploration process given how undocumented some of the endpoints are could consume pretty good amount of those limits.
caching is interesting.
Couldn't we store the results in the browser and then use an event that the data changed? A simple cache validation method so we don't keep asking for the same stuff?
@billy2 my api exploration workflow relies on polyglot notebooks, even in-memory cache wouldn't help here that much since I make edits to client library rebuild project, reload notebook to update assemblies - and at this point in-memory cache would be lost. How would you use the browser here?
@Konst_Sh I've been storing peoples stuff on their computers for awhile. When a client shows up, I establish a socket to my server. I can now store information in mongo or just put it in there browser, I chose their browser. It's now persistent, they can leave and when they come back I can show them the last state without contacting OS's api and building something to show.
One thing about pinging OS all the time is you get fresh stuff all the time. I've been thinking about the data state on OS and has anyone made any changes to data I'm interested in? You could register an event with OS and have them notify you (or your server, because it's always listening) and get a fresh set of data only when it's changed.
I don't know how many event handlers OS is willing to let me generate nor can I setup an event handler that detects a specific data change that I'm interested in. I don't know if I could get OS to behave and give me a notice when there's been a change to the data I'm interested in.
I've never liked ringing OS's bell a million times, I've never been shut off and didn't know there was a limit to requests.
@Konst_Sh I just read about polyglot notebooks and I have no idea how many request something like this will generate.
I added redis to my server with the idea I could duplicate a faster search than calling OS's api all the time.
What I'm worried about is hanging a parametric model on a website with a button that allows an stl download. Will that cause something to melt?
@billy2 once the app is done and tested we can improve the number of calls in different ways, but the exploration of unfamiliar endpoints is where you will need fresh data. Take a sketch info endpoint or drawings - they were not documented, the polymorphic class structure is often pretty hard to deduce from json alone - thats where a good amount of calls limit will be spent, and it will be a barrier for newcomers
@Konst_Sh Your app sounds interesting. Most useful info from OS requires a call to get a list to iterate through to get more stuff. Not sure how that pattern effects your polymorphic class structure. Good luck.