Skip to main content
Let’s explore how the GitHub GraphQL API can give you precise, efficient access to repository and workflow data—avoiding the extra fields and multiple requests common with the REST API.
A presentation slide titled "GitHub GraphQL API" with a large blue teardrop-shaped graphic on the right that says "Demo." The slide is branded with a small "© Copyright KodeKloud" notice.

Why GraphQL over REST for GitHub data

REST endpoints often return large JSON payloads containing many fields you don’t need, which increases bandwidth and parsing overhead. GraphQL lets you request exactly the fields you want and compose nested data in a single request. Key benefits:
  • Select only the fields you need.
  • Fetch nested related objects in one request (avoid multiple REST calls).
  • Receive responses exactly shaped to your query, reducing bandwidth and parsing.

Example: REST workflow runs (problem statement)

A typical GET to list workflow runs returns many fields—even if you only care about the workflow name and its status. HTTP request (example):
Truncated JSON response (example):
If you only need name, status, and conclusion, the remainder of this payload is wasted. GraphQL fixes that by letting you select only the fields you want.

GraphQL examples

Example: list organization members (name + avatar) — GraphQL:
REST equivalent:
Example: fetch a pull request with commits, comments, and reviews in one nested GraphQL query:
Contrast with REST, which typically requires multiple calls:

Making a GraphQL request to GitHub

Endpoint:
Typical headers:
You send a JSON payload containing the GraphQL query (and optional variables). Example: request rateLimit plus repository default branch and the latest commit metadata: GraphQL query:
Variables (JSON):
Send the above GraphQL query + variables as the body of your POST to /graphql. The response will include only requested fields and a rateLimit object. GraphQL also returns a cost that indicates how many request points the query consumed.
GraphQL queries have a computed request cost. Large nested queries cost more tokens. Unauthenticated requests have much lower rate limits; you will likely hit the unauthenticated rate limit quickly for public repositories. Use an authenticated token to get higher limits and more headroom for expensive queries.

Example: large nested query (cost demonstration)

Complex nested query against the public kubernetes/kubernetes repository:
If you run this query without a token you may see an error like:
With a valid token the query will succeed but may take several seconds; the rateLimit object will show the cost used by the query.

Best practices and summary

  • Use GraphQL when you need precise control over response fields or to aggregate nested related data in a single request.
  • Always monitor the rateLimit object and the query cost to avoid surprises.
  • Authenticate your requests (use a PAT or app token) to increase rate limits and handle more expensive queries.
  • Keep queries focused (limit first: values and the depth of nested selections) to reduce cost and latency.

Watch Video