Hacker News API: Search, Comments, Users & Who Is Hiring
Pricing
from $0.12 / 1,000 item returneds
Everything public on Hacker News through its two official APIs: keyword search over 2007-present, the six feeds, full comment trees flattened with depth, user profiles, and the monthly Who Is Hiring thread parsed into structured jobs. Plus a monitor that bills only new hits. No API key.
What to read. search runs keyword searches over everything Hacker News has indexed since 2007. feed pulls one of the six ranked lists (front page, new, best, Ask, Show, jobs). items returns specific stories and their whole comment trees. users returns profiles. whoIsHiring parses the monthly "Ask HN: Who is hiring?" thread into structured jobs. monitor returns only what is new since your last run. Inputs belonging to the other modes are ignored, not errors.
One Algolia query per entry, e.g. ["web scraping", "rust"]. Results are deduplicated across keywords and every row lists the keywords that matched it in matchedKeywords. Leave empty for "everything the other filters allow". Used by search and monitor.
[]date returns newest first and is the order to use when you are pulling a window of time. relevance returns Hacker News search's own ranking, which is not time-ordered.
Which ranked lists to pull, in Hacker News's own order. front is the top 500 stories, new the newest 500, best the top 200; ask, show and jobs are as long as Hacker News currently lists, which is often far shorter (28 and 31 on the day this was built). The free feed-summary row carries the real length. Used by feed.
[ "front"]How far down each feed to go. 30 is one front page.
Specific Hacker News item ids, e.g. ["4058874"]. Used by items.
[]Item links instead of ids — https://news.ycombinator.com/item?id=4058874 or https://hn.algolia.com/api/v1/items/4058874. The id is read out of the link; the page is never fetched.
[]Hacker News usernames, e.g. ["pg"]. Case-sensitive. Used by users.
[]Also return each user's most recent stories and comments as ordinary rows. They come from one search request, not from resolving the account's whole submission history — pg alone has 15,565 submissions.
Which of the three monthly threads to parse. All three are posted by the same account on the first working day of the month.
Which months' threads to parse, e.g. ["2026-09", "2026-08"]. Matched against the (Month YYYY) in the thread's own title, not against when it was posted — the August 2026 thread went up on the 3rd. Leave empty and Months back is used instead.
[]How many recent threads to parse when Months is empty. 1 is the current month's.
How far back the monitor looks when it has no stored state yet.
What the very first monitor run against an empty store does. emit-all returns and bills up to Max items; every later run bills only what is new. baseline-only returns nothing, bills nothing, and writes the baseline so the next run has something to compare against.
Only items posted on or after this. Accepts a date (2026-01-01), a full timestamp (2026-01-01T12:00:00Z) or a relative window (7d, 30d, 12h). A relative window means the same thing on every run of a schedule.
Only items posted on or before this. Same formats as From. A plain date covers the whole day.
Only stories with at least this many points. Hacker News does not publish comment scores, so this cannot be applied to a comments-only search — ask for it and you get a free invalid-input row explaining why, and the rest of the query still runs.
The most paid rows this run may return. 0 means "everything the filters allow", up to the 5,000-row run ceiling. Free summary and diagnostic rows do not count against it.
Only stories with at most this many points. Useful for finding things that were posted and went nowhere.
Only stories with at least this many comments. Stories only, for the same reason as Minimum points.
Drop any row whose title, text or URL contains one of these. Applied before anything is charged, so excluded rows cost you nothing.
[]How many results to ask for per request. Bigger pages mean fewer requests. Hacker News search returns at most 1,000 results per query however you page it; past that this Actor walks backwards through time in slices and tells you in a free summary row when it still had to stop.
Return each story's whole comment tree as comment rows, with depth, parentId and storyId on every one. On by default in items mode, off by default in feed mode — a front page with comments is roughly 900 extra rows.
Cap on comment rows per story. 0 means every comment in the tree.
How deep into the reply tree to go. 1 is top-level comments only.
How many recent submissions to return per user, newest first.
Which of a user's submissions to return.
[ "story", "comment"]Parse these specific thread ids instead of looking them up by month.
[]Cap on postings read from each thread. A busy month is around 264 top-level comments.
Only postings whose first line carries a REMOTE token. Applied before the charge.
Only postings whose parsed salary reaches this. Roughly a quarter of postings state pay at all; the rest have no salary to compare and are excluded when you set this.
Only postings whose text contains one of these, e.g. ["rust", "golang"]. Applied before the charge.
[]Every job row carries a parseConfidence from 0 to 1. Postings below this are returned free as diagnostics with their full text, never as paid rows. On the September 2026 thread the score was bimodal: 247 postings at 0.6 or above and 17 at 0.2 or below, with nothing in between.
Return the comments that did not parse as free diagnostic rows carrying their full text, so you can see what the parser left behind. Never charged either way.
Add posterKarma, posterCreated, posterAccountAgeDays and posterTrust to every job row. One request per distinct poster, cached for the run. A failed lookup leaves the four columns null and never fails the row.
Also try to parse replies to postings. Off by default: of the 120 deeper replies in the September 2026 thread, exactly 2 looked like job posts. Replies are discussion.
Include text and textHtml on stories and comments. Turning it off keeps the rows small when you only want titles, scores and links.
Add the free summary rows: what this run was asked to do, how many hits each query had, how long each feed really is, how many postings parsed, and what the monitor saw. Never charged.
The named key-value store the monitor remembers previous runs in. Every scheduled run of the same monitor must use the same name. Letters, digits and dashes, 3–63 characters.
How many targets to work on at once. The Actor holds itself to 5 requests a second against the search API and 10 against the official API whatever you set here.
Stop after this many seconds. Rows already returned are kept and a free timeout row says what was left.
Minimum comment length
commentsMinLength
Optional
Drop comments shorter than this many characters. Applied before the charge, so a run that only wants substantial comments does not pay for one-word replies.