Monitor GitHub for leads: what the API allows

Someone filed an issue on a repo you don't own, three weeks ago, titled something close to what you sell. Nine people reacted with a thumbs up. Two more commented "same problem here." Then, four days ago, someone posted the actual resolutio

Someone filed an issue on a repo you don't own, three weeks ago, titled something close to what you sell. Nine people reacted with a thumbs up. Two more commented "same problem here." Then, four days ago, someone posted the actual resolution: "we ended up paying for a tool to handle this, it does exactly what's described above." Thirteen people watching that thread just learned who to call next time, and it wasn't you.

That's the same shape of signal you already watch for on Reddit and Hacker News: a stranger, in public, describing the exact gap your product fills, with a paper trail of who else is reading along. If you sell to developers, GitHub is arguably a better source of it than either, because nobody files an issue by accident. The person writing it already tried the built-in way, already searched for a plugin, and is now describing their exact requirements to whoever's watching. So you open GitHub's API docs to wire the same alert. The first thing you learn is that "GitHub's API" isn't one door. It's two, with different locks.

GitHub's REST search finds issues, not discussions

GitHub's REST Search API lists endpoints for code, commits, issues, labels, repositories, topics, and users. Issues search covers pull requests too, and it runs globally: query a phrase and you get matches from any public repo, not just ones you follow. That's the useful half of the story, and it's the half most "monitor GitHub" advice stops at.

The general REST rate limit gives an authenticated user 5,000 requests an hour for ordinary endpoints, but search runs on its own, tighter meter: 30 requests a minute for every search endpoint except code search, which needs a token and still only allows 10 a minute. Unauthenticated callers get 10 a minute across the board. Run the math on a keyword list and the ceiling is generous for a handful of terms polled every few minutes, and tight the moment you try to watch a real list the way you would on Reddit.

Code search is the one endpoint worth ruling out on purpose. It matches source files, not conversation, so it never surfaces a buying-intent sentence no matter how narrow the query gets. The 10-a-minute cap on it is a non-issue if you were never going to spend a request there.

Discussions sit behind a separate, points-priced door

Here's the part the endpoint list doesn't say out loud: Discussions aren't searchable through REST at all. To search them you need the GraphQL API's guide to Discussions, which routes through the same top-level search field issue queries use, with type set to DISCUSSION instead of ISSUE.

GitHub didn't build one search with two content types. It built one search for issues and a second, harder one for discussions, and left you to notice the seam.

GraphQL doesn't count requests, it counts points: the cost of a call is calculated from how much the query actually asks for, then billed against a budget of 5,000 points an hour for a normal user or 10,000 for someone inside a GitHub Enterprise Cloud organization. A cheap query might cost one point. A query that pulls a discussion's full comment tree costs more. That means your Issues monitor and your Discussions monitor draw down two unrelated budgets, in two unrelated query languages, and "one GitHub integration" is really two builds wearing one label.

Neither search reaches you across repos you don't own

The other gap is push. GitHub does ship webhook events for Discussions, named discussion and discussion_comment, but the docs mark both "currently in public preview and subject to change," and a webhook only fires for the repo it's installed on, by whoever administers that repo. If you're watching a competitor's repo or a popular tool in your category, you don't administer it, so that door was never open to you in the first place.

The honest posture is scheduled polling against the two budgets above, not a live feed. That's a real step down from Hacker News, where anyone can query the public Algolia-backed search API with no token and no ask, and it's closer to the two-tier access GitHub's own ecosystem has quietly settled into: an open read for issues, a metered read for everything conversational.

Replying inside someone else's issue is Reddit's room problem, wearing code

Say you find the thread. GitHub's Acceptable Use Policies are specific about what happens next: "the primary focus of the content posted in or through your account to the service should not be advertising or promotional marketing," promotional material is only sanctioned inside your own README or project description, and separately, "you may not advertise in other users' accounts, such as by posting monetized or excessive bulk content in issues."

One honest reply to a thread you actually read isn't the thing either policy targets. The scripted version, dropped into every matching issue the week you find them, is exactly the pattern that gets you removed on Reddit and the pattern Product Hunt's community guidelines name outright: automated, bulk, and identical across threads, whichever platform is reading it.

What's actually left to do on GitHub

Three things survive the two-door problem, and all three are inside the rules. Poll REST issue search on a schedule for your keyword combinations, since it's genuinely global, free with a token, and the 30-requests-a-minute ceiling covers a real list if you space the calls out and narrow noisy terms with GitHub's own search qualifiers rather than one bare keyword. Run the GraphQL discussion search as a separate, smaller job against its own points budget, since discussion volume per repo tends to run well under issue volume anyway. And when a thread is live, reply once, as someone who read the whole thing, in the repo's own comment section rather than a DM the maintainer never asked for. It's the same discipline that keeps Discord communities open to founders instead of closed to them.

Budget the engineering time honestly, too. Two query languages, two rate-limit models, and a webhook feature still marked preview is a heavier build than the single search box GitHub's landing page implies, closer to standing up two small integrations than one. For a team with an engineer to spare and a product that lives natively on GitHub, that cost is worth paying. For a two-person team already running a Reddit and HN monitor, it's a third system to babysit for a channel that, issue by issue, produces fewer buying-intent threads a week than either of the other two.

None of that closes the gap between GitHub and a platform built to hand you a feed. It just means the read is on you, the same way it was before GummySearch shut down over Reddit's own access terms and took a shortcut with it. GitHub never offered that shortcut to begin with, which is the closest thing to good news in this whole comparison: there's no tool to lose, because there was never a version of this that ran on autopilot.

● FAQ

Can you use GitHub's API to monitor for buying-intent posts?

Yes, with two different tools for two different content types. GitHub's REST search endpoint covers issues and pull requests globally, with no blanket commercial-use ban in its docs the way Product Hunt's API has, but it caps authenticated requests at 30 a minute and returns at most 1,000 results per query. Discussions aren't in that endpoint at all, so monitoring GitHub actually means running two separate queries against two separate budgets.

Is GitHub Discussions searchable the same way Issues are?

No. GitHub's REST Search API lists endpoints for code, commits, issues, labels, repositories, topics, and users, and Discussions isn't one of them. To search Discussions you use the GraphQL API's top-level search field with type set to DISCUSSION, which is a different query language billed against a different budget.

What are GitHub's actual rate limits for this kind of monitoring?

REST search runs 30 requests a minute for authenticated users on every search endpoint except code search, which is capped at 10 a minute and requires authentication outright; unauthenticated search requests are capped at 10 a minute across the board. GraphQL, which is what Discussions search runs on, works differently: 5,000 points an hour for a normal authenticated user, 10,000 for someone inside a GitHub Enterprise Cloud organization, with each query's cost calculated from how much data it asks for rather than counted as one flat request.

Is it against GitHub's rules to reply to someone's issue with your product?

It depends on how and where. GitHub's Acceptable Use Policies say the primary focus of anything you post shouldn't be advertising, restrict promotional material to your README or project description, and separately ban advertising in other users' accounts, including posting monetized or excessive bulk content in issues. A single honest reply to a thread you actually read isn't what that line targets. A scripted reply dropped into every matching issue the week you find them is.

Does Shadow Inbox monitor GitHub?

No. Shadow Inbox watches Reddit and Hacker News, with Quora and LinkedIn in beta. GitHub isn't on the roadmap yet, partly because of the two-endpoint, two-budget split above, and partly because most repos layer their own contributing guidelines over GitHub's platform-wide rules, so what counts as compliant varies repo by repo in a way Reddit's subreddit rules and Product Hunt's forums don't.