Server returned HTTP response code: 403

Hi All

I am getting the below error when I am trying to run a Selenium Script integrated with CI tool Jenkins through GitHub.

Error Message: java.lang.RuntimeException: Server returned HTTP response code: 403 for URL:

Error Message: java.lang.NullPointerException

Note # This error is not always appearing. The script will run without an error for almost 20 mins. Then when I try to re execute, this error will be triggered and script will no longer execute. It will take around 1 hour or more for the script to start working again. 

I had tried the link which was mentioned in the error, but it was redirected to a page which gave very vague information pasted below.

  "message": "API rate limit exceeded for (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
  "documentation_url": ""

Could someone help me debug the issue and avoid reoccurence?

The answer is right there in the documentation_url field. It points you to the Developer API documentation on rate limiting, where it states:

For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the user making requests.

 I hope that helps!

Thanks for the response.

I saw that documentation, but whats confusing me is that my collegues who are working from some other locations are never facing this issue. But for me I am getting the error sometimes in morning even if I havent run any code the same day. I wonder whether this is some internet cache issue? Any suggestions?

Since you’re using unauthenticated requests, the rate limiting is by IP address. So if someone else in your office or location is also accessing GItHub’s API, then you’re sharing that 60 requests per hour. If your colleagues are in locations where they’re the only one accessing GitHub’s API (such as a deserted coffee shop), then it would make sense that they might not run into the rate limit.

Again, the solution is there in the documentation. Authenticated requests have a higher rate limit. So if you can rewrite your script to use authenticated requests, then that should ameliorate the issue.