HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
HackerNews
API
Learning & Reference2014–2026
HackerNews / API

API

Documentation and Samples for the Official HN API

206Distinct people
257Mentions
2Explicit recommenders
13.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Documentation and Samples for the Official HN API

GitHub

Where it is used

  • Hacker News Scraper & API — Hacker News Scraper & API: Stories, Who is Hiring uses the official Hacker News API to fetch HN data for its outputs. It relies on the HN Firebase API as part of those official APIs. Source
  • Haiker — Haiker uses the official Hacker News API to retrieve and display content from Hacker News within the app. Source

What people are saying

HN's Firebase-based API (https://github.com/hackernews/api) makes that easy, until you want to reconstruct the threads (i.e. who replied to who) and then it's annoying. For…

dang used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:23:53 PM UTC.

Mentions over time

HN mentions by year257 dated mentions

Observed mentions: 2014-10-07 17:49:07 UTC to 2026-10-31 21:56:35 UTC.

01020302014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 9 mentions; 3 submissions, 6 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 20 mentions; 4 submissions, 16 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 17 mentions; 3 submissions, 14 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 21 mentions; 6 submissions, 15 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 23 mentions; 4 submissions, 19 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 23 mentions; 3 submissions, 20 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 28 mentions; 4 submissions, 24 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 30 mentions; 6 submissions, 24 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 27 mentions; 3 submissions, 24 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 19 mentions; 0 submissions, 19 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 17 mentions; 0 submissions, 17 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC936
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC909
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC20416
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC17314
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC21615
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC14113
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC23419
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC23320
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC28424
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC30624
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC27324
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC19019
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC17017

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
Hacker News API Overview In partnership with Firebase, we're making the public Hacker News data available in near real time. Firebase enables easy access from Android, iOS and the web. Servers aren't left out. If you can use one of the many Firebase client libraries, you really should. The libraries handle networking efficiently and can raise events when things change. Be sure to check them out. Please email api@ycombinator.com if you find any bugs. URI and Versioning We hope to improve the API over time. The changes won't always be backward compatible, so we're going to use versioning. This first iteration will have URIs prefixed with https://hacker-news.firebaseio.com/v0/ and is structured as described below. There is currently no rate limit. For versioning purposes, only removal of a non-optional field or alteration of an existing field will be considered incompatible changes. Clients should gracefully handle additional fields they don't expect, and simply ignore them. Design The v0 API is essentially a dump of our in-memory data structures. We know, what works great locally in memory isn't so hot over the network. Many of the awkward things are just the way HN works internally. Want to know the total number of comments on an article? Traverse the tree and count. Want to know the children of an item? Load the item and get their IDs, then load them. The newest page? Starts at item maxid and walks backward, keeping only the top level stories. Same for Ask, Show, etc. I'm not saying this to defend it - It's not the ideal public API, but it's the one we could release in the time we had. While awkward, it's possible to implement most of HN using it. Items Stories, comments, jobs, Ask HNs and even polls are just items. They're identified by their ids, which are unique integers, and live under /v0/item/<id>.json. All items have some of the following properties, with required properties in bold: Field Description id The item's unique id. deleted true if the item is deleted. type The type of item. One of "job", "story", "comment", "poll", or "pollopt". by The username of the item's author. time Creation date of the item, in Unix Time. text The comment, story or poll text. HTML. dead true if the item is dead. parent The comment's parent: either another comment or the relevant story. poll The pollopt's associated poll. kids The ids of the item's comments, in ranked display order. url The URL of the story. score The story's score, or the votes for a pollopt. title The title of the story, poll or job. HTML. parts A list of related pollopts, in display order. descendants In the case of stories or polls, the total comment count. For example, a story: https://hacker-news.firebaseio.com/v0/item/8863.json?print=pretty { "by" : "dhouston", "descendants" : 71, "id" : 8863, "kids" : [ 8952, 9224, 8917, 8884, 8887, 8943, 8869, 8958, 9005, 9671, 8940, 9067, 8908, 9055, 8865, 8881, 8872, 8873, 8955, 10403, 8903, 8928, 9125, 8998, 8901, 8902, 8907, 8894, 8878, 8870, 8980, 8934, 8876 ], "score" : 111, "time" : 1175714200, "title" : "My YC app: Dropbox - Throw away your USB drive", "type" : "story", "url" : "http://www.getdropbox.com/u/2/screencast.html" } comment: https://hacker-news.firebaseio.com/v0/item/2921983.json?print=pretty { "by" : "norvig", "id" : 2921983, "kids" : [ 2922097, 2922429, 2924562, 2922709, 2922573, 2922140, 2922141 ], "parent" : 2921506, "text" : "Aw shucks, guys ... you make me blush with your compliments.<p>Tell you what, Ill make a deal: I'll keep writing if you keep reading. K?", "time" : 1314211127, "type" : "comment" } ask: https://hacker-news.firebaseio.com/v0/item/121003.json?print=pretty { "by" : "tel", "descendants" : 16, "id" : 121003, "kids" : [ 121016, 121109, 121168 ], "score" : 25, "text" : "<i>or</i> HN: the Next Iteration<p>I get the impression that with Arc being released a lot of people who never had time for HN before are suddenly dropping in more often. (PG: what are the numbers on this? I'm envisioning a spike.)<p>Not to say that isn't great, but I'm wary of Diggification. Between links comparing programming to sex and a flurry of gratuitous, ostentatious adjectives in the headlines it's a bit concerning.<p>80% of the stuff that makes the front page is still pretty awesome, but what's in place to keep the signal/noise ratio high? Does the HN model still work as the community scales? What's in store for (++ HN)?", "time" : 1203647620, "title" : "Ask HN: The Arc Effect", "type" : "story" } job: https://hacker-news.firebaseio.com/v0/item/192327.json?print=pretty { "by" : "justin", "id" : 192327, "score" : 6, "text" : "Justin.tv is the biggest live video site online. We serve hundreds of thousands of video streams a day, and have supported up to 50k live concurrent viewers. Our site is growing every week, and we just added a 10 gbps line to our colo. Our unique visitors are up 900% since January.<p>There are a lot of pieces that fit together to make Justin.tv work: our video cluster, IRC server, our web app, and our monitoring and search services, to name a few. A lot of our website is dependent on Flash, and we're looking for talented Flash Engineers who know AS2 and AS3 very well who want to be leaders in the development of our Flash.<p>Responsibilities<p><pre><code> * Contribute to product design and implementation discussions\n * Implement projects from the idea phase to production\n * Test and iterate code before and after production release \n</code></pre>\nQualifications<p><pre><code> * You should know AS2, AS3, and maybe a little be of Flex.\n * Experience building web applications.\n * A strong desire to work on website with passionate users and ideas for how to improve it.\n * Experience hacking video streams, python, Twisted or rails all a plus.\n</code></pre>\nWhile we're growing rapidly, Justin.tv is still a small, technology focused company
Read the full README on GitHub

What Hacker News says

17 sources
dang·Oct 31, 2026Recommendation phrase
HN's Firebase-based API (https://github.com/hackernews/api) makes that easy, until you want to reconstruct the threads (i.e. who replied to who) and then it's annoying. For years* I've wanted to replace that API with one we operate ourselves, which will simply return a JSON version of any HN URL. I've finally started working on this! Perhaps my favorite thing about LLMs is how they make projects possible which would otherwise not have gotten started. Edit: perhaps I should explain what I mean by that last bit. The way I want this new API to work is (1) HN should use it internally to generate HTML pages, and (2) there can't be any regressions - nothing should change in the web version. This is a pain to get right, as it's easy subtly alter the details, and it's annoying to regression-test everything. Also, (3) with a design like this, it i
Read the rest
s easy—and critical not to—leak data that ought to remain private (e.g. people's IP addresses) This is the sort of pain and annoyance that LLMs are amazing at taking care of. I get to focus on the parts I want to think about—the design and (yes) the code—and have a tireless assistant do the gruntwork and review. Without this I don't think I'd have gotten around to working on it. * (edit: over a decade in fact - see collapsed reply)
In HackerTube: YouTube built from videos recommended by HN
$ wget -4 https://github.com/HackerNews/API Resolving github.com (github.com)... 140.82.114.4 Connecting to github.com (github.com)|140.82.114.4|:443... failed: Network is unreachable. $ git clone https://github.com/HackerNews/API Cloning into 'API'... remote: Enumerating objects: 142, done. remote: Counting objects: 100% (53/53), done. remote: Compressing objects: 100% (21/21), done. remote: Total 142 (delta 38), reused 32 (delta 32), pack-reused 89 (from 2) Receiving objects: 100% (142/142), 67.87 KiB | 668.00 KiB/s, done. Resolving deltas: 100% (39/39), done. Seems to work fine. > Ipv5 would share routing tables, DHCP, DNS, NAT, and various middleboxes with ipv4 Which is great, but all of these things are 4 bytes only. You need a separate set of tables etc for the longer addresses. Also v6 already shares all of the
Read the rest
se things and works with them instantly when working with 4-byte addresses, so this isn't new. > Then those get patched or replaced to support longer addresses. Importantly, the upgraded versions easily support ipv4 too, so there's no reason not to upgrade. Yes, like with v6. I would expect people to find endless excuses to never do the patch or replace part or to just refuse to configure their gear to enable longer addresses, like they do with v6. All this leaves me wondering why this approach is bad when v6 came up with it but good when you came up with it.
In Google Hits 50% IPv6
> I asked AI to scrape HN comments Did the AI use the API? (linked at the bottom) https://github.com/HackerNews/API > All this really got me thinking, with a sufficient amount of data, you could eventually make something that looks completely believable and relevant to a conversation that is taking place. I've seen a few similar attempts, and after a while many (hopefully most) are detected, flagged and banned.
In Ask HN: Danger or Fun? encoding secret messages into HN comments

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.