Admin API Throttled?

[Jim_Roth]

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

I’ve got a couple of apps where I’m calling the Admin API for things like user statistics, token usage, etc., which are very valuable to an enterprise for managing users and usage. This has been working just fine for WEEKS.

However, as of yesterday, I’m getting 429 errors on virtually every call. Not every call, mind you, because it appears to be hit or miss.

Is there something going on with the Admin API? I see no online information in the documentation about API limits, so if that has been imposed, it has not been communicated.

Steps to Reproduce

My app calls the Admin API, I get a 429 error. I used Cursor to create a small test for me.

Test Results Summary

The comprehensive test revealed some very important findings:

What’s Working:

• /teams/members (GET) - SUCCESS (389ms)

• /teams/filtered-usage-events (POST) - SUCCESS (234ms)

What’s Failing:

• /teams/daily-usage-data (POST) - 429 RATE LIMITED (160ms)

Key Findings

1. Rate Limiting is REAL: The /teams/daily-usage-data endpoint is definitely hitting 429 errors

2. Endpoint-Specific: Not all endpoints are rate limited - some work fine

3. Fast Response Times: Even failed requests are fast (130-160ms), indicating the API is responding quickly but rejecting due to rate limits

4. Mixed Results: Some endpoints work while others don’t, suggesting different rate limits per endpoint

This Confirms Your Issue

The 429 errors you’re experiencing are NOT discrete - they’re widespread and endpoint-specific. The /teams/daily-usage-data endpoint is consistently returning 429 errors, which explains why your application is having issues.

Expected Behavior

What’s it’s been doing for weeks: return data.

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.38 (user setup)
VSCode Version: 1.99.3
Commit: fe5d1728063e86edeeda5bebd2c8e14bf4d0f960
Date: 2025-10-06T18:18:58.523Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

No - Cursor works, but with this issue

[condor]

hi @Jim_Roth and thank you for the detailed bug report. Just to confirm, it occurs on each call to that API endpoint even when you do not call the endpoint for a while?

[Jim_Roth]

Correct. It seems to be hitting the rate limit VERY quickly. The reason I opened this bug is because I’ve not made a call since last night, and now it appears the tripwire is very sensitive. Almost immediately, the API is throwing 429, and I’m not making very many calls AT ALL. For the Token endpoint (/teams/filtered-usage-events), it’s really bad.

[Casey_Cantwell]

I also ran into this bug this morning. I gave cursor the error, and it implemented rate limiting techniques with retries, to get around it. My tools run dramatically slower, but at least work now.

[Jim_Roth]

Yeah, I’d like to understand what changed, because I’ve not had this problem until just yesterday.

[condor]

@Jim_Roth @Casey_Cantwell we introduced rate limits on all APIs.

You can find them listed now in our docs

Admin API | Cursor Docs

[Jim_Roth]

Dude. Seriously? Ex post facto notification? Y’all need to watch some marketing and PR Ted Talks, amigo.

Super duper not cool.

At.

All.

And not for nothing, you need to revisit and revise your throttles. They’re not reasonable. Enterprises need this data to manage their engagement with you. You’re not helping your business by hobbling others.

[condor]

Thank you for the feedback, I will pass this to the team. Apologies that we did not notify you.

What would be from your usage the required req/min? I would like to share that info with team as well.

[Jim_Roth]

At a minimum, 60 requests per minute for the /teams/filtered-usage-events and /teams/daily-usage-data. Those endpoints are the most useful, and being able to see how the teams are performing, along with token consumption, is extremely useful data.

[condor]

Yes I can understand how the data can be very useful. Would the same query of 20 requests per minute not give same result?

[Jim_Roth]

My pain point is the token usage data. I’ve reconfigured my code to honor the rate limits for token usage, and now it takes several minutes instead of a few seconds to retrieve token data. My default window is 7 days, but it still takes 3+ minutes or more to gather data.

Oddly enough, the teams-daily-usage endpoint is still performant, returning results very quickly. For some reason, the filtered-usage-events endpoint is super sensitive to rate-limiting and much, much slower than the teams-daily-usage endpoint. Considering the amount of money we’re spending, it’s very important to be able to track that spending and subsequently forecast based on usage. I’m looking at token usage over time, cost distribution by model, and individual token usage stacked by model. Good stuff, but now it’s painful to gather that data that only a few days ago was almost immediate.

Having said all that, maybe the filtered-usage-events endpoint works differently? Maybe you can shed some light on that.

[condor]

I will ask the team about the filtered-usage-events endpoint!

[Jim_Roth]

Well, here’s another new error(?):

Error loading usage data: API request failed: API error (400): Date range cannot exceed 30 days

Now we’re limited to 30 days of data?

From your documentation.

[condor]

Thank you also for the detailed error and screenshot, I have notified the team already.

[Jim_Roth]

Looks like the 90-day limit was reinstated.

[Jim_Roth]

I’ve refactored my app, so I’m no longer in dire straits, but it would be really nice if the filtered-usage-events endpoint wasn’t so darned slow.