Rate limiting overview

Like all software and platforms, Quickbase puts different limits in place to protect the infrastructure and users from disruptions and data loss.

Rate limits are thresholds for the number of transactions allowed in a certain time period, usually seconds. Rate limits can be applied by user, IP address, geographical location, and/or other identifying information.

When you build your app, it is important that you are familiar with rate limits and able to recognize what it looks like in your app when they are applied. It is also important that integrations and enhancements to your app that use APIs are built with proper error handling, retry, and backoff mechanisms.

Quickbase rate limits

Quickbase has two categories of rate limits:

• Fixed: These are limits that programmatically limit the number of transactions. Fixed rate limits apply to our RESTful APIs.

• Variable: These are limits that are enforced dynamically under certain circumstances. Quickbase may manually put them into effect, or they may go into effect automatically.

Note: In line with our terms of service, Quickbase reserves the right to rate limit, block, or throttle any traffic to protect the platform.

Rate limits can be applied at varying levels. They may be specific to:

• IP addresses

• Users

• Other identifying factors

Rate limits can be reached by integrations, custom interfaces, scripts, and almost all code languages. To simplify, this article refers to all of these as “code.”

General rate limits

Quickbase generally allows for 10-15 traffic requests/second to your apps. Design your Quickbase solutions so they can scale well as their usage grows.

Learn more in our blog post on scaling out your Quickbase apps

Quickbase’s Security and Site Reliability teams may proactively impose additional limits for apps receiving an unsustainable amount of traffic. Additional limits may also be imposed if Quickbase suspects apps are under attack or the source of an attack.

General rate limit error messages

If your apps exceed the general rate limits, or additional rate limits imposed by Quickbase for the sake of reliability and security, your end users will see an error message that lets them know that Quickbase is temporarily unavailable or that Quickbase is receiving too many requests.

These issues will usually resolve themselves within 5 minutes, and end users should be able to use the app as normal. If the issues last longer than 5 minutes, please open a support ticket that includes:

• The URL being visited

• Date/time (including timezone)

• Exact error code and error ID

Quickbase support can let you know what was happening that caused the issue and how it can be prevented in the future.

Note: In rare situations, the Quickbase platform may be experiencing issues that could result in a similar error message. The most recent information will be available on our service page.

Code Pages

Using code pages to store libraries and helper files is supported for low traffic use cases (learn more in the Extending Quickbase article). Low traffic is defined as less than 4 requests per second to all code pages in the app. If the traffic to your code pages exceeds 4 requests per second, users may see an error message and be blocked from accessing those pages.

API rate limits 

XML API limits

The Quickbase XML API has inbound limits of 10 requests/second/table. These limits are dynamically enforced.

RESTful API limits

For most endpoints, the Quickbase RESTful API has inbound limits of 100 requests per 10 seconds per user token. This more flexible limit allows builders to have steady streams of traffic with additional bursts. Some RESTful API endpoints have different limits, and those limits are included in the documentation for the endpoint.

Additionally, Quickbase has put automatic protections in place for when excessive failing API calls occur. For example, if a user token is revoked that is used in authentication by a script, that script will begin failing.

Handling API rate limits

First, be sure to follow best practices when using Quickbase APIs (both XML and RESTful) to extend the platform.

Learn more in the Extending Quickbase help article.

Backoff and retry

The first thing a piece of code should do is look for the retry-after header. If it is present, it can be relied on to inform you when to retry your request. To follow best practices, you should also make sure your code uses backoffs and retries when APIs return an error that is likely to succeed if you try again, or during other connectivity issues. This means that you set up your code to automatically try to make the call again after a certain amount of time.

How often you send retries will vary according to your app and the API call. It's important that your retry attempts back off incrementally, with each increment getting larger. Here is a simple illustration:

Keep in mind:

• Use retries only for HTTP 429, and exponential backoff and retry for connectivity issues any errors in the 500s (HTTP 500, HTTP 502, etc). It would not make sense to retry in the case of an HTTP 400 error, which generally means there is an issue with the request (like authentication, or a missing field).

• Carefully design retries to happen in exponential increments (this is the backoff). If APIs retry too frequently, you are at risk creating too much traffic that could result in denial-of-service (DOS).

You can look at RESTful API documentation to see a code example of backoff and retry.

Timeouts

While not directly rate limiting, builders and integrators should define a timeout for their tool that is appropriate based on the workflows. We recommend 15-90 seconds. For example, a custom interface likely will have a shorter timeout than a data integration, since users are waiting for progress. When a timeout occurs, integrations should have logic that determines what to do next based on the expected runtime of the operation. This can also be tightly coupled with the backoff logic.

Examples

Here are three examples and how a builder should handle timeouts:

• Date/time

• Request URL

• Response HTTP Code

• Response HTTP Text

• Cf-ray

• Tid

• qb-api-ray (RESTful APIs only)

• Source IP address