Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect GitHub's Retry-After Header and other best-practices #16

Open
shahidhk opened this issue Jan 22, 2017 · 0 comments
Open

Respect GitHub's Retry-After Header and other best-practices #16

shahidhk opened this issue Jan 22, 2017 · 0 comments

Comments

@shahidhk
Copy link
Contributor

ref: https://developer.github.com/guides/best-practices-for-integrators/#dealing-with-abuse-rate-limits

Quoting:

  • Make authenticated requests, or use your application's client ID and secret. Unauthenticated requests are subject to more aggressive abuse rate limiting.
  • Make requests for a single user or client ID serially. Do not make requests for a single user or client ID concurrently.
  • If you're making a large number of POST, PATCH, PUT, or DELETE requests for a single user or client ID, wait at least one second between each request.
  • When you have been limited, use the Retry-After response header to slow down. The value of the Retry-After header will always be an integer, representing the number of seconds you should wait before making requests again. For example, Retry-After: 30 means you should wait 30 seconds before sending more requests.
  • Requests that create content which triggers notifications, such as issues, comments and pull requests, may be further limited and will not include a Retry-After header in the response. Please create this content at a reasonable pace to avoid further limiting.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant