Skip to main content

Quotas

Within our platform, we employ two types of quotas: static and dynamic. Both serve their unique purposes in maintaining a balanced usage pattern. Here's a brief overview:

  • Static Quotas: Fixed limits set on various domain entities like users, endpoints, repositories, and API keys. Static quotas are established once and typically remain consistent over short durations. For instance, a limit might be set on the number of API keys an organization can generate or how many users can be registered.
  • Dynamic Quotas: Pertains to the rate of usage or the number of calls and requests an organization can make within a set timeframe. As detailed in the 'Quotas Per Plan' section, these quotas adjust based on time or usage patterns, ensuring flexibility and optimal system performance. Examples include the number of API calls an organization can make daily or the rate of these calls.

By distinguishing between static and dynamic quotas, we provide a clear structure for organizations to understand their constraints and potential. This clarity enables easy planning, whether you're configuring initial settings or scaling operations.

Static Quotas​

Understanding the needs of your API and matching them to your plan quotas is key for your successful API management while effectively utilizing our services. This guide is designed to provide you with an overview of the quotas offered in each plan.

Metrics Subject to Quotas​

Workspace Endpoints​

When creating or updating an endpoint in our platform you will need to process it until it is finally deployed. Our platform maintains your endpoints in this edit mode and latest working state in Workspace. Any endpoints developed and stored within the RAW Platform are referred to as your web endpoints. Available in all plans.

Deployed endpoints​

These are all your deployed endpoints. They are available in Catalog and ready for consumption.

Repositories​

If you are working in a team and you want version control, shareability and sustainability in your work, you will be very interested in our platform integration with GitHub. This metric refers to your GitHub repositories hosting your RAW projects and endpoints that you can create and maintain though our platform. Available in Business Plan.

Users​

You can always invite other users in your organization and accelerate your collaboration. These are the active users within your organization. Available in all plans.

API Keys​

If you want to allow access to your endpoints only by the authorized parties you will need to define specific access keys. These are your API keys which grant access to your endpoints. Associate API keys with endpoint scopes to ensure secure consumption only by authorized parties. Available in Pro and Business plans.

Static quotas per plan​

The following table shows in detail the available quotas for each metric in each plan.

PlanStarterProBusiness
Web endpoints183603600
Deployed endpoints61201200
GitHub repositories--60
Users312600
API Keys0600600

Adjusting your quotas​

If you are not sure about the quotas that fit your API or you would like quotas tailored to your needs, please reach us at support@raw-labs.com. We will be more than happy to help you! In any case we encourage you to explore the opportunities that a higher plan can offer and unlock the full potential of your platform.

Dynamic Quotas​

Rate limits, or dynamic quotas as they're often called, are vital mechanisms in maintaining the performance and stability of web platforms. Imagine you're developing an application that gets suddenly popular. The influx of requests can overwhelm your resources, potentially causing disruptions or degraded performance for all users. That's where rate limits come in – they're akin to traffic signals in a city, guiding the flow and ensuring smooth operations.

For our platform, rate limits are applied per organization. This design choice acknowledges the varying demands within an organization. Instead of setting a cap per individual, we provide an aggregate limit. This allows for flexibility; if one user has a high-demand day, others might not, ensuring the collective needs of the organization are met without hitting the ceiling.

But we also recognize one size doesn't fit all. While our limits are set based on extensive data and feedback, we understand organizations evolve and might need adjustments. Whether you're just starting out or scaling up, we encourage you to explore our plans, each crafted to cater to a range of needs. And should you require more, we're open to discussions and adjustments.

In essence, our quotas are engineered for resilience and fairness, ensuring that regardless of your subscription tier, your experience remains optimal.

Analysis​

Dynamic Quotas Per Plan​

To accommodate diverse operational scales and requirements, we've formulated several subscription plans. Each is characterized by its own quota, which is meticulously designed for the typical use-cases it caters to. Here's an in-depth look:

Starter Plan​
  • Daily Quota: Users on the Starter Plan are entitled to make up to 2,000 API calls each day.
  • Burst Capacity: A distinct feature of this plan is the burst capacity of 5 calls. This means that in a short time frame, you can make up to 5 calls in rapid succession. However, after this burst, the quota system will only allow 1 call every 43 seconds to ensure that the daily limit isn't prematurely exhausted.
  • Replenishment: Tokens are replenished at a rate of 1 token every second. But since a call requires 43 tokens, you'll need to wait for the token bucket to accumulate the needed tokens before initiating another burst.
Pro Plan​
  • Daily Quota: Subscribers of the Pro Plan can make up to 10,000 calls daily.
  • Burst Capacity: This plan comes with a burst capacity of 10 calls. In simpler terms, you can initiate 10 successive calls without any hindrance. After depleting this burst, you'd have to wait approximately 8.6 seconds between each call to avoid hitting the limit.
  • Replenishment: The system replenishes at 7 tokens per second. Given that a call necessitates 50 tokens, after a full burst, it takes about 7.1 seconds to accumulate enough tokens for the next call.
Business Plan​
  • Daily Quota: Business Plan users have a robust allowance of up to 1,000,000 calls per day.
  • Rate Consistency: Unlike the other plans that offer burst capabilities, the Business Plan operates at a consistent pace: users can make 12 requests every second, equating to nearly 1,040,000 calls daily. This consistency ensures a predictable and steady flow of requests without any periodic pauses.

Custom-made Quotas​

As your needs grow, so can your plan with us. If you ever hit a limit or feel you need more room to operate:

  • Upgrade Your Plan:Simply switch to a higher-tier plan to get more resources and additional features.
  • Talk to Us: If our standard plans don't quite fit, reach out to our support team at support@raw-labs.com. We're here to discuss custom solutions tailored for your needs.

Your success is our priority, and we're always here to help you get the most out of our platform.

Developer Guidelines​

This section is tailored for developers, offering insights into our rate-limiting mechanism and practical examples for seamless integration.

Understanding Rate Limiting with the Redis Token Bucket Algorithm​

We enforce rate limits at the organization level using the Redis Token Bucket algorithm. This mechanism ensures equitable resource distribution among our users, but it's essential to understand its intricacies for a seamless integration.

Redis Token Bucket Algorithm Breakdown:

  • Every organization is endowed with a "token bucket" possessing a set capacity.
  • Each incoming request consumes one or more tokens.
  • Tokens are replenished at a specified rate. If the bucket contains tokens, the request is processed. If the bucket is devoid of tokens, the request is denied until tokens are replenished.

For instance, the Starter Plan has a quota of up to 2,000 calls per day. Given our rate-limiting mechanism, this translates to one call per 43 seconds. This means that each call would consume 43 tokens and the replenish rate would be 1 token per second.

API Response Headers: Insights and Analysis​

Every API response comes with a set of headers that exhibit your rate limit status:

X-RateLimit-Burst-Capacity: 215
X-RateLimit-Requested-Tokens: 43
X-RateLimit-Replenish-Rate: 1
X-RateLimit-Remaining: 172

Here's a breakdown of each header:

  • X-RateLimit-Requested-Tokens: Specifies the number of tokens consumed by the last request. For Starter Plan this is 43, which translates to 43 tokens being consumed for each call.
  • X-RateLimit-Burst-Capacity: Reveals the number of requests an organization can make in a single burst. For Starter Plan the value for this attribute is 215. This means that 215/43=5 calls can be made in a single burst.
  • X-RateLimit-Replenish-Rate: Indicates the rate at which tokens are replenished to the bucket. A value of 1 suggests one token is replenished every second. Assuming an empty bucket, shortly after a full burst, a new call can be made every 43 seconds.
  • X-RateLimit-Remaining: Displays the number of requests an organization can still make in the current time frame. Using the Starter Plan as a reference, after initiating a request when the bucket is full, then it would show 215-43=172.

Should an organization surpass its allocated rate limit, it will be met with a 429 Too Many Requests HTTP status code. It's prudent to delay further requests until the rate limit undergoes a reset.

Common Scenarios and Best Practices​

Every organization has its unique demands and operational patterns. But over the years, we've identified common scenarios and gathered best practices to guide you in getting the best from our system:

  • Peak Traffic Periods: If you anticipate a surge in traffic – perhaps due to a product launch or marketing campaign – consider spreading out your requests or upgrading to a higher tier with a more generous dynamic quota.
  • Ensuring Continuous Operation: Keep an eye on the X-RateLimit-Remaining header. If it approaches zero, it's a cue to adjust your request pattern, ensuring you don't hit a wall.
  • Handling Rate Limit Exceeded Responses: Implementing a retry mechanism with exponential backoff can be effective. If a request is rate-limited, wait for a specified duration, then retry. Each subsequent rate-limited request should extend the wait time before the next retry.
  • Monitoring and Alerts: Regularly monitor your usage. Set up alerts to notify when you're close to exceeding your quota. This proactive approach ensures smooth operations and gives you ample time to adjust or upgrade your plan.

Need Further Assistance or Custom Limits?​

Understanding quotas and how they impact your organization's operations is crucial. If you find yourself uncertain about any technical aspects or need a tailored quota that better suits your specific needs, don't hesitate to reach out. Our dedicated support team is here to assist and answer any questions you might have. Contact us to ensure you're getting the most out of our platform.