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: 258 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.
One place this is really painful is developing custom features using an LLM. I had some great scripts set up which would push updated code to Onshape using the API. I've managed to burn through my monthly limit in less than 1/2 a month. I'm back to scripts that rely on copy/paste/commit in the browser. This approach is very brittle and depends on the browser focus. To me it makes zero sense. If anything this is more of a drain on servers to do things this way.
Somehow my almost 1000 git commits since turned into 2504 api calls since each API powered Onshape Commit involved a GET and POST to push the .fs file, and then two GETs to check the Feature Studio contents response and the featurespecs response (is this necessary?). So in less than a month I've burnt through a year's API usage????
@Vajrang_Parvate Any possibility that there can be a better way to manage these resources? I'd love to have MCP integration within Onshape so that any LLM that can communicate that way can easily read the Onshape monitor and profiling tools and commit .fs changes. As it was, even with my scripts which could commit FeatureScript updates, I had to either manually cut and past notices back to Codex, or get it to scrape the browser window (not very reliable) to get feedback to Codex.
Simon Gatrall | Product Development, Engineering, Design, Onshape | Ex- IDEO, PCH, Unagi, Carbon | LinkedIn
Simon: just so I understand what you're getting at: are you saying that API for committing .fs is inefficient (requiring more client-side calls than necessary) OR are you saying that Onshape is counting client-side API calls incorrectly?
We have gone to great lengths to make sure the API counting is accurate, so if it's the latter, please send in a support ticket with additional details if you may have and we'll get that looked into asap.
SVP, Onshape Product and R&D
@Vajrang_Parvate
Codex wrote the scripts to commit FeatureScript to Onshape documents. I didn't look too carefully at how it was doing it since it worked so much better than copy/paste in the browser. I'm not sure if all the calls that it's using are needed. It seems like the initial GET and POST are required, and the subsequent GETs are there to check that it worked, but I don't fully understand the API. Perhaps I should understand it better.
More my points:
Follow up questions: how do I get my API allowance increased? Where do I go if I'm willing to pay, or can I get some sort of help here? I don't want to upgrade to Enterprise to do this.
Simon Gatrall | Product Development, Engineering, Design, Onshape | Ex- IDEO, PCH, Unagi, Carbon | LinkedIn
@S1mon well, you can make a public app and publish it to onshape's appstore which one and only function would be to resend your api calls to its endpoint to onshape api, it would basically need to expose one single endpoint which would resend every call to it to cad.onshape.com/api/vXX/… and send in response whatever onshape responding to it. Sinse you already vibe-coded some stuff I assume the above should be doable for you as well. But then everybody will be able to use that app and load your server to bypass these api limitations
@Konst_Sh
I was starting to think about that. I also started investigating building an App which would be an MCP host, but that seemed a bit beyond the scope of what I really wanted to do at the moment, but I may reconsider.
Simon Gatrall | Product Development, Engineering, Design, Onshape | Ex- IDEO, PCH, Unagi, Carbon | LinkedIn
@S1mon: You don't need to be an Enterprise user; the paid API plans are available for purchase for Standard and Professional users as well. https://www.onshape.com/en/contact-sales and they'll get you sorted.
I would strongly recommend "taking ownership" of code that you're generating with any AI tool - be it client side code that's calling Onshape API or FeatureScript. You should know and fully understand what that code is doing since it is operating on your behalf with your Onshape account keys.
@Konst_Sh: Submitting an App in the Onshape App Store with the sole purpose of bypassing Onshape's API limits, or enabling end users to bypass those limits, will not get very far. This is documented here https://onshape-public.github.io/docs/app-store/ and in the API Agreement (shown on first login to the dev portal).
SVP, Onshape Product and R&D
@Vajrang_Parvate I was almost sure that couldn't be 100% legal
@Vajrang_Parvate
Part of my point about the API limits and the lack of tooling is that instead of using the API, it was actually more useful today for me to get Codex to write tooling for Chrome's new Devtools MCP and Playwright. In addition to getting a more stable sync/commit featurescript updates to Onshape, this gives me good access through the DOM to gather regeneration times, and run profiling on multiple part studio tabs automatically. It seems odd to me that Onshape charges for API calls, but it's entirely possible to automate a lot of things through the browser that aren't even available through the API.
Simon Gatrall | Product Development, Engineering, Design, Onshape | Ex- IDEO, PCH, Unagi, Carbon | LinkedIn