GitHub API Endpoints Used by resume.github.com: A Complete Technical Guide

The resume.github.com application consumes five distinct GitHub REST API endpoints—users, repos, search issues, organizations, and starred repositories—to generate client-side résumés entirely without server-side infrastructure.

The open-source project resume/resume.github.com creates elegant, data-driven résumés for any GitHub user by aggregating public profile data. Understanding which GitHub API endpoints power this tool reveals how to build similar zero-backend applications that leverage GitHub's public REST API for real-time data visualization.

Overview of the Client-Side Architecture

Unlike traditional web applications that rely on a backend database, resume.github.com operates entirely in the browser. The core logic resides in js/githubresume.js, which orchestrates parallel API calls to GitHub's public REST API using jQuery's $.getJSON method with JSONP callbacks (?callback=?) to bypass cross-origin restrictions. All data fetching, parsing, and rendering happens client-side using Mustache templates stored in the views/ directory.

Complete List of GitHub API Endpoints

The application calls five specific GitHub API endpoints to construct a comprehensive developer profile. Each endpoint serves a distinct purpose in the résumé generation pipeline.

User Profile Endpoint

Endpoint: https://api.github.com/users/:username

This endpoint retrieves core identity information including the user's display name, avatar URL, bio, location, blog link, and public repository count. In js/githubresume.js at line 57, the application calls this endpoint to populate the header section of the résumé with personal branding elements.

Repositories Endpoint

Endpoint: https://api.github.com/users/:username/repos?per_page=100

To build the project portfolio section, the application fetches all public repositories with pagination support (adding &page=n for subsequent requests). Lines 62-68 in js/githubresume.js handle this recursive fetching, collecting up to 100 repositories per page until all public repos are retrieved. This data powers the language statistics and repository cards displayed in the employment history section.

Search Issues Endpoint for Merged Pull Requests

Endpoint: https://api.github.com/search/issues?q=type:pr+is:merged+author=:username

Rather than using the GraphQL API or complex repository traversal, the application leverages GitHub's search API to find merged pull requests authored by the user. This endpoint, called at lines 80-86 in js/githubresume.js, returns contribution data that the application renders as "Open Source Contributions" in the résumé, providing concrete evidence of collaborative development activity.

Organizations Endpoint

Endpoint: https://api.github.com/users/:username/orgs

To display professional affiliations and community involvement, the application queries the organizations endpoint at lines 98-99 in js/githubresume.js. This returns a list of organization avatars and names that appear in the résumé's sidebar or footer section, indicating the user's ecosystem participation beyond individual repositories.

Starred Repositories Endpoint

Endpoint: https://api.github.com/users/:username/starred?per_page=100

This endpoint serves a unique opt-out mechanism rather than display data. Lines 108-112 in js/githubresume.js recursively check if the user has starred the resume/resume.github.com repository. If found, the application proceeds with résumé generation; otherwise, it displays an opt-out message. This clever use of the starred endpoint enables privacy-conscious users to prevent their profile from being displayed without requiring authentication or database storage.

How the API Calls Are Orchestrated in githubresume.js

The data fetching pipeline in js/githubresume.js follows a specific sequence to optimize load times and respect the opt-out preference.

First, the script parses the ?username= query parameter from the URL (lines 1-15). Before initiating heavy data transfers, the github_user_starred_resume function (lines 101-147) verifies whether the target user has starred the repository. This check uses the starred endpoint with pagination to handle users with extensive star lists.

Once the opt-in is confirmed, the application fires parallel requests to maximize efficiency:

• github_user fetches the core profile (line 57)
• github_user_repos recursively pulls all public repositories (lines 60-75)
• github_user_issues gathers merged PRs via the search API (lines 78-95)
• github_user_orgs retrieves organization memberships (lines 97-99)

All requests utilize JSONP (?callback=?) to circumvent CORS restrictions inherent in browser-based API calls. After the raw JSON responses arrive, the code transforms them into Mustache view objects and injects HTML fragments from the views/ directory (including resume.html, job.html, contrib.html, and org.html).

Modern Implementation Using Fetch API

While resume.github.com relies on jQuery for legacy browser support, you can replicate the same endpoint logic using modern JavaScript. Below are equivalent implementations using the fetch API and async/await syntax.

Fetching User Profiles and Organizations

// Retrieve basic user profile
async function fetchUserProfile(username) {
  const response = await fetch(`https://api.github.com/users/${username}`);
  return response.json();
}

// Retrieve organization memberships
async function fetchUserOrgs(username) {
  const response = await fetch(`https://api.github.com/users/${username}/orgs`);
  return response.json();
}

Paginated Repository Fetching

async function fetchAllRepositories(username) {
  const perPage = 100;
  let page = 1;
  const allRepos = [];

  while (true) {
    const url = `https://api.github.com/users/${username}/repos?per_page=${perPage}&page=${page}`;
    const response = await fetch(url);
    const repos = await response.json();
    
    allRepos.push(...repos);
    if (repos.length < perPage) break;
    page++;
  }
  
  return allRepos;
}

Searching Merged Pull Requests

async function fetchMergedPullRequests(username) {
  const perPage = 100;
  let page = 1;
  const allPRs = [];

  while (true) {
    const query = encodeURIComponent(`type:pr is:merged author:${username}`);
    const url = `https://api.github.com/search/issues?q=${query}&per_page=${perPage}&page=${page}`;
    
    const response = await fetch(url);
    const data = await response.json();
    
    allPRs.push(...data.items);
    if (data.items.length < perPage) break;
    page++;
  }
  
  return allPRs;
}

Checking Starred Repositories for Opt-Out

async function hasStarredResume(username) {
  const perPage = 100;
  let page = 1;

  while (true) {
    const url = `https://api.github.com/users/${username}/starred?per_page=${perPage}&page=${page}`;
    const response = await fetch(url);
    const repos = await response.json();
    
    if (repos.some(repo => repo.full_name === 'resume/resume.github.com')) {
      return true;
    }
    
    if (repos.length < perPage) break;
    page++;
  }
  
  return false;
}

These modern implementations mirror the logic found in js/githubresume.js while utilizing contemporary JavaScript patterns that avoid jQuery dependencies and JSONP callbacks.

Key Files in the Repository

Understanding the complete architecture requires examining how the API data flows through the application layer. The following files constitute the entire data pipeline:

File	Purpose	Key Function
js/githubresume.js	Core orchestration script containing all API endpoint definitions and jQuery-based JSONP calls.	github_user, github_user_repos, github_user_issues
views/resume.html	Mustache template for the main résumé layout, populated with data from the users and repos endpoints.	Template rendering
views/job.html	Template for individual repository entries, receiving data from the repos endpoint.	Repository display
views/contrib.html	Template for merged pull request contributions, populated from the search issues endpoint.	Contribution display
views/org.html	Template for organization membership cards, using data from the orgs endpoint.	Organization display

These components work in concert to transform raw JSON responses from the five GitHub API endpoints into the polished, printable résumé format that the application generates.

Summary

• resume.github.com generates résumés entirely client-side by consuming five specific GitHub REST API endpoints.
• The primary data sources are the users, repos, search/issues, orgs, and starred endpoints, all accessed via JSONP in js/githubresume.js.
• The application implements a unique opt-out mechanism by checking if the user has starred the resume/resume.github.com repository before rendering.
• All API responses are processed through Mustache templates located in the views/ directory to produce the final HTML résumé.
• Modern implementations can replace the legacy jQuery/JSONP approach with standard fetch API calls, though CORS restrictions may require proxy solutions for browser-based requests.

Frequently Asked Questions

Does resume.github.com use authentication when calling GitHub API endpoints?

No, the application makes unauthenticated requests to the public GitHub REST API. According to the source code in js/githubresume.js, all calls use jQuery's $.getJSON with JSONP callbacks (?callback=?) to bypass cross-origin restrictions. While this approach avoids authentication complexity, it subjects the application to stricter rate limits (60 requests per hour per IP) compared to authenticated requests.

Why does the application check starred repositories before generating a résumé?

The starred repository check serves as an opt-out privacy mechanism. Before fetching profile data, the code in lines 108-112 of js/githubresume.js paginates through the user's starred repositories looking for resume/resume.github.com. If the repository is not found in the star list, the application displays an opt-out page instead of the résumé. This clever approach allows users to control their visibility without requiring account creation or database storage on the application's side.

How does resume.github.com handle API pagination for users with many repositories?

The application implements recursive pagination logic in js/githubresume.js (lines 62-75) to handle users with extensive repository lists. For the repositories endpoint, it requests 100 items per page (per_page=100) and increments the page parameter until the response contains fewer than 100 items, indicating the final page. The same pagination strategy applies to the search issues endpoint (lines 80-86) for fetching merged pull requests and the starred check (lines 108-112) for the opt-out verification.

Can these GitHub API endpoints be used with the modern Fetch API instead of jQuery?

Yes, all five endpoints used by resume.github.com can be accessed using the modern fetch API, though with important caveats. While the original implementation in js/githubresume.js relies on jQuery and JSONP to circumvent CORS restrictions, modern browsers can use standard fetch requests for most endpoints if running in a Node.js environment or through a CORS proxy. However, direct browser-based fetch calls to api.github.com will encounter CORS errors unless the GitHub API explicitly allows the origin, which is why the JSONP approach remains necessary for purely client-side browser implementations without server intermediaries.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}