Appwrite is now available as a DigitalOcean 1-click app! Click to install! 🚀

Rate Limits

Some of Appwrite's API endpoints have a rate limit to avoid abuse or brute-force attacks against Appwrite's REST API. Each Appwrite route documentation has information about any rate limits that might apply to them.

Rate limits only apply to Client SDKs. Rate limits do not apply when accessing Appwrite with a Server SDK authenticated using an API key.

You can check the returned HTTP headers of any API request to see your current rate limit status:

HTTP/1.1 200
Date: Mon, 01 Jul 2013 17:27:06 GMT
Status: 200
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 56
X-RateLimit-Reset: 1372700873

The headers tell you everything you need to know about your current rate limit status:

Header Description
X-RateLimit-Limit The maximum number of requests that the consumer is permitted to make per hour.
X-RateLimit-Remaining The number of requests remaining in the current rate limit window.
X-RateLimit-Reset The time at which the current rate limit window resets in UTC epoch seconds.

If you need the time in a different format, any modern programming language can get the job done. For example, if you open up the console on your web browser, you can easily get the reset time as a JavaScript Date object, You can also read more about Unix Time.

new Date(1372700873 * 1000) // => Mon Jul 01 2013 13:47:53 GMT-0400 (EDT)

Once you go over the rate limit you will receive an error response:

HTTP/1.1 429
Date: Tue, 20 Aug 2013 14:50:41 GMT
Status: 429
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1377013266
    "message": "Too many requests",
    "code": 429

Service Abuse

To protect the quality of service from Appwrite, additional rate limits may apply to some actions. For example, rapidly creating content, polling aggressively instead of using webhooks, making API calls with a high concurrency, or repeatedly requesting data that is computationally expensive may result in abuse rate limiting.

It is not intended for this rate limit to interfere with any legitimate use of the API. Your normal rate limits should be the only limit you target.

If you are exceeding your rate limit, you can likely fix the issue by caching API responses and using webhooks for data polling.

If your application triggers this rate limit, you'll receive an informative response:

HTTP/1.1 429
Content-Type: application/json; charset=utf-8
Connection: close
    "message": "Too many login attempts",
    "code": 429

Disable Rate Limits

During development, you may need to frequently make requests to certain endpoints to test your code. You can temporarily disable rate limiting to prevent triggering rate limits during development. Disable rate limiting using the _APP_OPTIONS_ABUSE environment variable. Make sure to re-enable rate limiting in production environments.

Learn more about environment variables