About rate limits for OAuth apps

OAuth apps act on behalf of a user, by making requests with a user access token after the user authorizes the app. For more information, seeAuthorizing OAuth apps.

The generation of these user access tokens is subject to a rate limit. Additionally, API requests made with these user access tokens are subject to rate limits.

Rate limits for signing in users

OAuth apps should always cache their tokens, and only rarely need to sign in a user. Repeatedly signing in a user can indicate a bug, most frequently seen as an infinite loop between the app and GitHub. If an app signs the user in ten times within one hour, the next sign in within the same hour will require re-authorization of the application. This ensures the user is aware that the app is minting so many tokens, and provides a break in what may be an infinite loop otherwise. This tensign in rate limit is distinct from the tentoken limit also enforced for OAuth apps. For information about the ten token limit, seeAuthorizing OAuth apps.

Rate limits for the API

GitHub sets a limit on the number of requests a OAuth app can make to the REST API within a specific time period. It also sets a limit on the point value of queries that a OAuth app can make to the GraphQL API within a specific time period. In addition to these primary rate limits, GitHub may also apply secondary rate limits. These limits help to prevent abuse and denial-of-service attacks, and ensure that the system remains available for all users.

For more information, seeRate limits for the REST API andRate limits and node limits for the GraphQL API.

Further reading

• Rate limits for the REST API
• Rate limits and node limits for the GraphQL API
• Rate limits for GitHub Apps