git-updater: Release Assets for private repo: Missing Access Token?


I tried using the “Release Assets” feature with a private repo. From the plugin update screen I can see it’s trying to fetch the correct file.

But it 404 fails. When I copy the URL to my browser, I can access and download it. Is it possible that the configured access token is not used here?

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 2
  • Comments: 20 (12 by maintainers)

Most upvoted comments

Here’s the answer from GitHub

I reviewed your cURL requests and see that you’re making a call to, > and not the GitHub API (

If you’re interested in getting the release for that repository, I recommend > using this endpoint specifying the release’s ID:

Here’s an example cURL request, where “123456” is a fictitious release ID:

curl -H “Authorization: token XXXXX” -IL “> ORG/REPO/releases/123456”

You could fetch the releases for a repository using this endpoint, where each > release includes an id field:

Here’s the accompanying cURL request:

curl -H “Authorization: token XXXXX” -IL “> ORG/REPO/releases”

I hope that helps, but let me know if you have any other questions!

That didn’t really help but I found a solution diving into the API again:

Assuming we already know the tag name (which is the case in Github Updater), we can access the release directly like this:

curl -s -H "Authorization: token XXXXX" ""

Which returns

    "url": "...",
    "assets": [
          "url": "",
          "id": 123456,
          "name": "",
          "label": "",
          "uploader": {
          "content_type": "application/zip",
          "state": "uploaded",
          "size": 1167766,
          "download_count": 9,
          "created_at": "2016-10-25T12:36:34Z",
          "updated_at": "2016-10-25T12:36:38Z",
          "browser_download_url": ""
        }, {
            # more assets

There can be multiple assets. You could apply the already defined naming scheme and filter, or simply take the first asset.

Now, the browser_download_url is the one we already know doesn’t work except in the browser (as the name suggests 😃).

However, I found this in the API docs:

To download the asset’s binary content, set the Accept header of the request to application/octet-stream. The API will either redirect the client to the location, or stream it directly if possible. API clients should handle both a 200 or 302 response.

curl -L -s -H "Accept: application/octet-stream" "" >

This works—heureka! 💡

  • -L: It’s important to follow the location because the actual file is hosted on S3.
  • -H "Accept: application/octet-stream": the header that tells GitHub to download rather than return a JSON response
  • Access token: I had to use the parameter version here. When I used -H "Authorization: token XXXXX", I got a Bad Request response from Amazon.

It’s probably a fair bit of work to implement but the approach should work. Until then you should add to the readme that asset downloading does not work for private repos for now.

Gave it a try with and it worked 👍

I think you’re going to like this.


Still cleaning up and working out the kinks.