The V3 API mentions branches in its reference page

The ref in the URL must be formatted as heads/branch, not just branch.
For example, the call to get the data for a branch named sc/featureA would be:

GET /repos/:user/:repo/git/refs/heads/sc/featureA

Create a Reference

POST /repos/:user/:repo/git/refs

Parameters

ref

String of the name of the fully qualified reference (ie: refs/heads/master). If it doesn’t start with ‘refs’ and have at least two slashes, it will be rejected.

sha

String of the SHA1 value to set this reference to

So it should be possible to create a new branch, by naming a new '/heads' in the ref parameter.

Potherca points out to a working test, using the service of www.hurl.it (which makes HTTP requests)

• Find the revision you want to branch from.
  Either on Github itself or by doing a GET request from Hurl:

  https://api.github.com/repos/<AUTHOR>/<REPO>/git/refs/heads

• Copy the revision hash

• Do a POST request from Hurl to https://api.github.com/repos/<AUTHOR>/<REPO>/git/refs with the following as the POST body :

    {
        "ref": "refs/heads/<NEW-BRANCH-NAME>",
        "sha": "<HASH-TO-BRANCH-FROM>"
    }
  

  (obviously replacing the <NEW-BRANCH-NAME> with the name your want the new branch to have and the <HASH-TO-BRANCH-FROM> with, you know, the hash of the revision you want to branch from)

  You will need to use HTTP basic and fill in your Github credentials to access the Github API.

• Press the Send button and your branch will be created!

In 2022, you can also use gh api

gh api \
  --method POST \
  -H "Accept: application/vnd.github.v3+json" \
  /repos/OWNER/REPO/git/refs \
  -f ref='refs/heads/featureA'
 -f sha='aa218f56b14c9653891f9e74264a383fa43fefbd'

I have encountered the exact same problem. I did manage to acquire all the commits for all branches within a repository (probably not that efficient due to the API).

Approach to retrieve all commits for all branches in a repository

As you mentioned, first you gather all the branches:

# https://api.github.com/repos/:user/:repo/branches
https://api.github.com/repos/twitter/bootstrap/branches

The key that you are missing is that APIv3 for getting commits operates using a reference commit (the parameter for the API call to list commits on a repository sha). So you need to make sure when you collect the branches that you also pick up their latest sha:

Trimmed result of branch API call for twitter/bootstrap

[
  {
    "commit": {
      "url": "https://api.github.com/repos/twitter/bootstrap/commits/8b19016c3bec59acb74d95a50efce70af2117382",
      "sha": "8b19016c3bec59acb74d95a50efce70af2117382"
    },
    "name": "gh-pages"
  },
  {
    "commit": {
      "url": "https://api.github.com/repos/twitter/bootstrap/commits/d335adf644b213a5ebc9cee3f37f781ad55194ef",
      "sha": "d335adf644b213a5ebc9cee3f37f781ad55194ef"
    },
    "name": "master"
  }
]

Working with last commit's sha

So as we see the two branches here have different sha, these are the latest commit sha on those branches. What you can do now is to iterate through each branch from their latest sha:

# With sha parameter of the branch's lastest sha
# https://api.github.com/repos/:user/:repo/commits
https://api.github.com/repos/twitter/bootstrap/commits?per_page=100&sha=d335adf644b213a5ebc9cee3f37f781ad55194ef

So the above API call will list the last 100 commits of the master branch of twitter/bootstrap. Working with the API you have to specify the next commit's sha to get the next 100 commits. We can use the last commit's sha (which is 7a8d6b19767a92b1c4ea45d88d4eedc2b29bf1fa using the current example) as input for the next API call:

# Next API call for commits (use the last commit's sha)
# https://api.github.com/repos/:user/:repo/commits
https://api.github.com/repos/twitter/bootstrap/commits?per_page=100&sha=7a8d6b19767a92b1c4ea45d88d4eedc2b29bf1fa

This process is repeated until the last commit's sha is the same as the API's call sha parameter.

Next branch

That is it for one branch. Now you apply the same approach for the other branch (work from the latest sha).

There is a large issue with this approach... Since branches share some identical commits you will see the same commits over-and-over again as you move to another branch.

I can image that there is a much more efficient way to accomplish this, yet this worked for me.