Use GitHub Sponsors Like Patreon: Gate Features and Check Sponsorships

On a recent episode of Coffee with Developers, we heard from cURL founder Daniel Stenberg about what it’s like to run a popular open source project, and the challenge of monetising it. Some survive on donations from sponsors, others on income from paid features or enterprise-level customers, or perhaps revenue from adverts.

Daniel’s experience raised an interesting question: could we use GitHub’s API to build a Patreon-style membership system that gives sponsors access to exclusive features?

Before we start, we’ll say GitHub’s sponsorship API is still relatively new, and it’s far from perfect. It will, however, handle payment infrastructure, so that’s one big weight off of our mind before we get going.

If you’d like to skip to the end and check out the code for yourself, check out the GitHub Sponsors Feature Gate Example repository to see how it works.

The Complete Process

So before we get started, here’s the complete flow for our system, from start to finish:

1. User signs in with GitHub (OAuth) → You get their access token
2. Store the token (session/database) → Retrieve it when needed
3. Check sponsorship (GitHub GraphQL API) → “Does this user sponsor me?”
4. Process the response → Determine sponsor status
5. Expose to frontend → Return isSponsor: true/false
6. Render UI → Show full feature for sponsors, gate for everyone else

To keep this article concise, we’ll assume you have configured some sponsorship tiers on GitHub, and already completed steps 1 and 2, allowing users to log in to your application with their GitHub credentials.

If you haven’t already done this, we recommend either following the GitHub guide, or configure it along with a database using Supabase’s docs.

Note: Finally, before we get started, we should say that there is one key limitation in GitHub’s API, which is that you cannot check if a user has sponsored a specific project, and instead you can only check if they sponsor its creator (as sponsorships are user-to-user, not user-to-project).

Also, the API only returns one-time sponsors in API calls for 30 days after their sponsorship begins, and so we recommend storing sponsorship data in a database so it persists beyond this limit.

GitHub GraphQL

GitHub’s GraphQL API is incredibly underrated. Easy to use and reliable, we’re going to use it to ask “does the current (authenticated) user sponsor account X?” - where the viewer in GraphQL refers to the user identified by the token exchanged on login.

List Who the Viewer Sponsors

While the GitHub API is promising, it does have some funny quirks. When we first attempted this, we used the API field viewer.isSponsoredBy(accountLogin), which returns a boolean, but in practice it often returns false even when the user has sponsored you (see the one-time sponsorship bug mentioned above). So, instead list everyone the viewer sponsors and check if your account appears in that list.

Here’s the GraphQL query we send to GitHub:

query {
  viewer {
    login
    sponsorshipsAsSponsor(first: 100) {
      nodes {
        sponsorable {
          ... on User {
            login
          }
          ... on Organization {
            login
          }
        }
      }
    }
  }
}

This query essentially retrieves:
(a) viewer — the authenticated user (the person whose token we’re using)
(b) login — their GitHub username
(c) sponsorshipsAsSponsor — all the people/organizations this user sponsors
(d) sponsorable — the account being sponsored (could be a User or Organization), and
(e) login (inside sponsorable) - the GitHub username of the account being sponsored.

Check If They Sponsor You

The API returns an array of accounts the user sponsors in viewer.sponsorshipsAsSponsor.nodes. Each item has a sponsorable.login field containing the GitHub username of the account being sponsored. Simply iterate through this array and check if any sponsorable.login matches your account’s username - if it does, they’re a sponsor.

Note: Use the exact same username that appears in your GitHub Sponsors URL. For example, if your sponsors page is https://github.com/sponsors/your-username, then your-username is what you check against.

Server-side Check

Create a function that uses the GraphQL query from above to check sponsor status, passing in the githubToken to authorise the call:

async function checkIfSponsor(githubToken, founderUsername) {
  // Send the GraphQL query we defined earlier
  const response = await fetch("https://api.github.com/graphql", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${githubToken}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ query }), // The GraphQL query from above
  });

  const data = await response.json();
  const sponsorships = data.data?.viewer?.sponsorshipsAsSponsor?.nodes || [];

  // Check if your account is in the list
  return sponsorships.some(
    (sponsorship) => sponsorship.sponsorable?.login === founderUsername,
  );
}

This checkIfSponsor() function returns true if they sponsor you, false otherwise.

Exposing to the Frontend

The GraphQL check happens on your server (where you securely store the GitHub token), so finally we’ll create an API endpoint that calls checkIfSponsor and returns the result:

async function getSponsorStatus(req, res) {
  const githubToken = req.session?.githubToken; // From your auth system
  const isSponsor = await checkIfSponsor(githubToken, "your-github-username");
  res.json({ isSponsor }); // Frontend gets { isSponsor: true/false }
}

Your frontend calls this endpoint (e.g., GET /api/github/sponsor-status), stores the isSponsor value in state, where we can conditionally render features or elements based on their sponsorship status: show the feature if isSponsor is true, show a gate message or re-direct if false.

Extending the System: Tiered Sponsorships

The implementation above checks for any sponsorship, but you can extend it to support tiered access. The sponsorshipsAsSponsor query can return tier information (tier name, monthlyPriceInCents, isOneTimePayment), allowing you to gate features based on sponsorship tier or amount — just extend your GraphQL query to include these fields and check them in your logic, similar to how we check isSponsor.

Conclusion: Monetising Your Project with GitHub Sponsors

We’ve shown how you can use GitHub Sponsors to monetise your open source project by gating features behind sponsorship—similar to Patreon, but with GitHub handling all the payment infrastructure. By checking sponsorship status via GitHub’s GraphQL API, you can offer exclusive features to sponsors while keeping your codebase simple, and you can even extend this to support tiered sponsorships based on sponsorship amount or tier level.

This gives you a straightforward way to monetise your project without building payment infrastructure, GitHub handles the payments, and you just check who sponsors you. Don’t forget to visit the GitHub Sponsors Feature Gate Example repository to see the complete working code and let us know what you think on socials.