#stenerali_api
proper spearBOT
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- stenerali_docs, 1 day ago, 6 messages
- stenerali_api, 5 days ago, 13 messages
sonic gateBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1240368832569282613
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
static carbon
It's measured by read (50 per second) and write (100 per second) based on the API key that's used. So even if a platform is making requests on behalf of a Connect account, they would still only be able to do 100 writes per second accross any number of Connect accounts
upper blade
😬. What mechanism is best to see if we're approaching that limit or not? Is the implication that we can use multiple api keys across parts of the application to buffer the limits?
static carbon
No, you wouldn't make the requests with different API keys. You should build systems that operate within those limits. For context, even with the rate limit, you can do 3.6 million requests per hour, which should be more than sufficient for virtually all use-cases
We don't surface your API rates anywhere, so you would need to calculate that on your own ahead of time, or build a rate checker into your workflow
upper blade
100 /sec = 6000 / min = 360'000 / hr = 8'640'000 / day though. How do you get to 3'600'000 / hr?
static carbon
Sorry, I'm reading that from an internal doc. I think they might mean that with the 100 per second on write and 50 per second on read, you could do 150 per second total, but I'm not sure what that calculates out to specifically.
In any case, what are you building that might run into those rate limits?
upper blade
Looking at Workbench, I can see we're currently making around 34mm API requests a week. which averages out at about 4.8mm a day. Which implies about 56% capacity. Is that a fair analysis?
static carbon
Got it. Yeah, that logic seems sound, though obviously the average is not really the metric that counts, as I assume you have peaks and troughs where more/less than 56% of the overall rate limit is happening throughout each day
upper blade
ok, this was helpful. I appreciate the info.
static carbon
Sure thing!