Permit access without OAuth token


The REST API v3 permits access without an OAuth token, with tighter rate limit restrictions. Are there plans to do the same with the GraphQL API?

Without this capability integrators must force users through the OAuth flow immediately. This is not ideal for certain experiences. Here are a couple applications that I cannot move to GraphQL unless I force users to login immediately:


@jdanyow this question has come up a few times, and I’m not sure if there’s a definitive answer. I’ve asked internally about it, and will let you know what I find out.

In the meantime, I’d love to understand a bit better what queries you would want to run without authenticating for the and apps.

Is there any way that you could work around the constraint by generating a token (or tokens) of your own that you use for the queries that are currently unauthenticated using the REST API?


Both apps run on GitHub pages and utilize the GitHub REST API v3. Neither has any back-end services except for what amounts to a proxy to the GitHub access_token API for completing the OAuth flow. This service is so lightweight and infrequently used that I’m able to run it on the Azure/Heroku free tier. GitHub pages and the GitHub API do all the heavy lifting. uses the Gist related APIs in REST v3. It’s an application for authoring and running GitHub Gists. Users can create public or secret GitHub Gists without logging in. When the application saves a Gist, the query string is updated with the id, enabling sharing (example). If the user chooses to login, the Gists are saved under their own account. The application is an alternative to Fiddler/Plunker/CodePen. It’s fully functional without logging in and free for me to operate because of static file hosting and APIs GitHub offers. Forcing users to login before a Gist can be loaded would kill adoption of this app. It’s used to embed runnable code examples in blogs, in stackoverflow Q&A, and to supply running examples of bugs/features/designs when posting GitHub issues. is a commenting widget. It’s a lightweight alternative to Disqus/LiveFyre/etc. When you view a blog post that uses for commenting, it searches for a GitHub issue associated with the blog post using the REST v3 issue search API. If a matching issue is found, the GitHub issue comments are loaded and displayed. If an issue is not found, one will be created the moment a user submits a comment (followed immediately by saving the user’s comment). To submit a comment the user needs to go through the OAuth flow (as expected). Scroll to the bottom of this blog post to see the comments widget in action. This app would have been impossible to create without anonymous API access. Users are not going go through the OAuth flow just to view comments on a blog. Of the two applications, this one would benefit the most from the GraphQL API because I will be able to search for the issue that matches the blog, load the comments and load the viewer/user all in one request. I have a branch where I’ve converted to the GraphQL API but I can’t deploy this without anonymous access.

tldr; useful apps can be created on the GitHub platform well within anonymous API access rate limits. It would be a shame if GraphQL is a step backwards in this regard.


That makes a lot of sense, @jdanyow, thanks for elaborating. Since this is running without a backend server, creating an auth token for yourself would not be a viable workaround, as there would be nowhere to store it.

I’ll let you know what I find out!


@jdanyow Alright, I have a little bit of clarity on this. The GraphQL team has anonymous access to the GraphQL API on their list of things they definitely want to do, but it’s not high enough on their list right now that they could promise (or even estimate) an ETA.

As an aside, people were really interested in hearing your use cases—these are really cool examples!

This brings me back to one of your very first comments:

Here are a couple applications that I cannot move to GraphQL unless I force users to login immediately

Is there something particular pushing you to want to move these to GraphQL quickly (some constraint or trade-off that is making the REST API painful)?

#6 wouldn’t benefit much from the GraphQL API.

On the other hand, GraphQL would enable utterances to load a lot less data in a single round trip (issue search, issue comments, user, content). Here’s the query I’d use to streamline the app:

In the current version I have to make 4 REST API calls to achieve the same thing and the data transferred is much larger due to the inclusion of unneeded props.


hey @kytrinyx - just checking in. Any updates on this?


@jdanyow This one hasn’t changed in the past couple of months. We’re tracking the request, and are interested in hearing more unauthenticated use cases but, at this time, we’re not actively prioritizing anonymous requests.


My usecase is very similar, I have a public facing app with no backend. The only difference is my app has been built from the ground up with the graphql v4 api (without checking that I can’t make unauthenticated requests), so I can’t publish it at this time.

(Tangent, mad props @jdanyow, looks awesome!)


I need this feature too. Working on some decentralized platform with community plugins support. Plugins are simply Github repos forked from the main one. In client there will be “store” tab with list of all plugins available to install. To do so I fetch forks using Github API. I don’t need all of the data returned from /repos/:user/:name/forks, will be better to have only url and description in response. Less data to download to client - faster execution, less data to upload to client (from your side) - less resources, cheaper execution. Win-win :slight_smile:



@Secretmapper thanks!


I need this too. I was quite excited to try GraphQL, but now I have to go back to REST because of this. Wish I realized earlier.

My current use case:
I want to build a UserVoice-style feature prioritization app that’s based on Github issues and uses reactions for votes.
Obviously, it wouldn’t make much sense to expect website visitors to log in before they can read the roadmap!
And I also have no backend except an auth proxy, so generating an access token is not an option. It would be if I could generate a read-only access token I guess (then I could just use a dummy user, but that’s quite a hack).

But literally, everything I’ve ever built on the Github API ever (I’ve been using it since 2012) requires anonymous access as well. I can’t think of a single case where it would be an acceptable flow to ask visitors to log in immediately.

I really hope you guys reconsider, all other APIs that did this declined tremendously. For example, there used to be tons of apps built on the Twitter API, ever since they locked out unauthenticated users there are now way fewer, and even those that exist are way less used. Same with Instagram. Unless that’s the goal: to turn developers away and conserve resources?


Hey all!

I’m Nick, the Engineering Manager for the team responsible for our GraphQL API - some of you have probably seen me around and/or have been frustrated at me in the past when a request hasn’t moved quickly, or when we push back (like in this issue!) on adding a feature.

When we created the GraphQL v4 API, one of the first things we wanted to do was throw out all of the assumptions that we’d made for our REST v3 API, and start fresh. On top of that, we knew that it wasn’t going to be a super straightforward task to distill all of GitHub’s public surface into a GraphQL schema that worked for every use case from the beginning, so we decided to start small and build it out piece by piece in coordination with our users.

One of the pieces of the REST API that we did not want to launch with immediately was anonymous requests - not because we wanted to push away anybody who needed that feature, but because we weren’t happy with the user experience that customers had while doing unauthenticated requests with the REST API, and figured it’d be even worse with GraphQL. Unfortunately, as everyone on this thread knows all too well, that removes a use-case that a significant amount of people used the REST v3 API for!

If anything, as has been said previously, we’re not blocking anonymous access because we’re worried about any additional load - for the most part, if people could port their REST queries over to GraphQL, we’d expect that it would actually decrease the number of requests and transferred data!

Instead, we’ve not implemented this because we don’t feel like we’ve nailed the end-to-end experience around rate limiting, permissions, and overall API quality as an anonymous user. If I had unlimited resources and time to do everything, I would absolutely love to sit down and craft a GraphQL API that serverless/zero-storage apps could use, but so far a myriad of other components of the API have taken priority over this.

I care deeply about making sure that as many people as possible can use our APIs to provide deep and rich integrations on top of our platform, but doing that with a userbase the size of GitHub means meeting a nearly infinite number of requirements, so we have to pick and choose.

The REST API’s isn’t going anywhere anytime soon, and neither is anonymous access to it. Over time, I’m optimistic that we can fold this access method into the GraphQL API one way or another while providing an improved user experience.


Waiting for this been a long time, can’t switch to Graphql API in my SPA because of this. @nickvanw Thanks for the explanation. hope it release not too late.


@nickvanw thanks for the info. Just wanted to let you know that we’re in the very early pilot testing phase of a new feature on that allows users to report documentation and product feedback via GitHub issues. All our documentation content is open source on GitHub. We would have loved to have used GraphQL v4 for the feedback feature but requiring a sign-in to view the issues wasn’t an option for us.

Here’s a few links to pages that have feedback (scroll to bottom):

Next year this will roll out across all topics on This is an example of a more widely used, non-hobby-project scenario using anonymous API access. I didn’t mention it when I originally opened this thread because it wasn’t clear whether we were going to use the GitHub API directly.

Happy Holidays :smile:




We are integrating our website to show pinned projects on our public organization and to list “help wanted” issues (etc.) in various sections of our open source project’s website so as to promote participation / contribution. Requiring our otherwise anonymous community to login to our open source page’s website introduces too much friction. Unfortunately, this is all new dev and it would have been ideal for us to integrate with your v4 API, but we’ll have to go with the v3 and undo that work later if github introduces anonymous access to v4.


I use the v3 API to check latest release in a repository and show an update notification in my open source app, I’d like to use v4 because the previous API sends tons of unnecessary data, but requiring auth just doesn’t make sense here.

Here’s the query I want to use:

repository(owner: "chylex", name: "TweetDuck") {
  releases(first: 1, orderBy: { field: CREATED_AT, direction: DESC }) {
    edges {
      node {
        tag {
        releaseAssets(first: 1, name: "TweetDuck.Update.exe") {
          edges {
            node {


I too had the use case for adding a github release based download manager for my FOSS

  repository(owner: "AllanWang", name: "Frost-for-Facebook") {
    releases(first: 20, orderBy: {field: CREATED_AT, direction: DESC}) {
      nodes {
        tag {
        releaseAssets(first: 5) {
          nodes {

I take it that the only work around now is to create a separate account to make a token, just to be 100% sure that none of our own account data is leaked? At that point, the token will more or less be exposed. Plus with the rate limits, we may have to cycle through multiple tokens just to get this working


I have many demo apps without a backend which use anonymous access with V3 and I’d like to port them to GraphQL to reduce the payloads.