Having spent a considerable portion of this quarter conducting a technical evaluation of various literature review and academic discovery platforms for our internal research security framework, I have naturally gravitated towards a deep analysis of ResearchRabbit's operational parameters. My focus, given my background, is on the stability, predictability, and contractual understanding of the service's API, as this is a critical dependency for any enterprise integration.
I am currently parsing their API documentation regarding rate limiting, and I believe I may have encountered either an ambiguity in their specification or, more likely, a fundamental misunderstanding on my part. The documentation states a limit, but the units and enforcement window seem open to interpretation. I am seeking clarification from the community to ensure my risk assessment and integration design are based on a correct interpretation.
The core of my confusion lies in the following points as extracted from the public documentation:
* The stated limit is "X requests per hour per user."
* There is no explicit mention of whether this is a rolling hour window or a fixed clock hour.
* More critically, it is unclear if the "per user" refers to the authenticated ResearchRabbit user account under which the API token is issued, or if it refers to the end-user of *our* application who might be leveraging a shared backend service token. The distinction is vital for architectural design.
For instance, if we have a single service account performing automated literature surveillance for multiple internal researchers, does the rate limit apply globally to that service account's token? This would create a contention point and a potential single point of failure for our compliance workflow. Conversely, if the limit is truly per end-user, it implies a more complex token management strategy on our end, tying each user's activity to a distinct ResearchRabbit account.
My immediate questions for those who have operated at scale are:
* What is the practical enforcement mechanism you have observed? Is the 429 response returned predictably?
* Has anyone successfully negotiated or clarified a different rate-limiting structure under an institutional or enterprise agreement?
* Are there documented best practices or official clarifications from ResearchRabbit on architecting a multi-tenant application against their API?
Understanding this is not merely a technical curiosity; it is a prerequisite for my vendor security review and business continuity planning. A misjudgment here could lead to service degradation during a critical audit period, which is an unacceptable operational risk.
—at
—at
Oh, the "per hour" window thing is tricky. I've been burned by that with other APIs before. It's often a rolling window but they rarely say.
Could you share the exact wording? Sometimes the real limit is in the HTTP headers they send back, like `X-RateLimit-Reset`. You might have to test it with a few quick calls to see.
The "per user" part of that limit is just as important. If your integration uses a single service account, it's one user. It doesn't matter how many researchers you have behind it.
That rolling vs. fixed hour ambiguity is a classic cheap-out. Means you have to treat it as a rolling window or you'll get throttled. Write your calls to pace at something like `X / 3600` per second and add a jitter buffer. Good luck getting them to clarify.
Check the response headers on your first 403. That's your real spec.
SQL is enough