Reddit Bulk Fetch by ID: Hydrate Posts in One API Call

Bulk-fetching Reddit posts by ID means handing an endpoint a list of post fullnames you already have and getting all of those posts back in one call, instead of making a request per post. You pass a comma-separated list of t3_ fullnames, and the response is an array of full post objects with their titles, authors, scores, and comment counts. This is the endpoint you reach for whenever you already hold the IDs and just need the current data behind them: hydrating IDs off a stream, backfilling an archive, or re-checking scores in a dedup pipeline. This guide shows the whole path in copy-paste Python.

Not affiliated with Reddit Inc. redditapis.com is an independent third-party REST proxy for Reddit's API. This tutorial is vendor-neutral: it shows the native /by_id/names.json path and a managed REST option side by side so you can pick what fits your job.

---

TL;DR: To hydrate many Reddit posts at once, call GET https://api.redditapis.com/api/reddit/by_id/t3_abc123,t3_def456, which returns a posts array for up to 100 comma-separated t3_ fullnames in a single authenticated request. That one call replaces up to 100 separate per-post requests, so it is faster and lighter on your rate limit. An unknown or deleted id is simply absent from the result, so compare the IDs you asked for against the name values that came back. The native equivalent is https://www.reddit.com/by_id/t3_abc123,t3_def456.json, free but rate-limited and 403-blocked from many cloud IPs. A managed endpoint returns the same posts through a clean pool and one bearer token for $0.002 per call (pricing).

---

What you will build:

• A single by_id call that turns a list of t3_ fullnames into full post objects
• A batcher that chunks more than 100 IDs into one call per 100
• A dropped-ID diff that tells you which fullnames Reddit no longer serves
• The native reddit.com/by_id/...json comparison and its 403 and rate-limit pitfalls

---

What the by_id Endpoint Does

The by_id endpoint takes a list of post fullnames and returns the posts behind them in one response. A fullname is Reddit's global identifier for a thing: a short type prefix plus the base-36 id you see in a URL. For posts the prefix is t3_, so the post at reddit.com/r/redditdev/comments/abc123/... has the fullname t3_abc123. You already have these on every object a search or listing hands you, because each post carries both a short id (abc123) and a name (t3_abc123). The job of by_id is to take those name values and give you the current data behind each one.

The call itself is one authenticated GET with the fullnames in the path, comma-separated:

One call, up to a hundred posts

Up to 100 fullnames come back per call, which is the whole reason the endpoint exists. If you are holding a set of IDs, you do not want to spend one HTTP request per id to learn what happened to each. You want to hand over the batch and get the batch back. The endpoint is deliberately narrow: it takes t3_ post fullnames and returns posts. A t1_ comment id or a t5_ subreddit id is rejected at the request boundary, because the post shape and the comment shape are different and mixing them would hand you an array you cannot iterate cleanly.

The distinction between by_id and a search is worth holding in your head. A search answers "which posts match this query"; by_id answers "give me the current state of these exact posts I already know." You use search to discover IDs and by_id to hydrate them, and most real pipelines do both in sequence: discover once, then re-hydrate the same IDs on a schedule as their scores and comment counts change.

---

The N Plus One Problem

The reason bulk fetch matters is the request-per-post trap, the same shape backend engineers call the N plus one problem. If you have 100 post IDs and hydrate them by calling a single-post endpoint in a loop, you make 100 HTTP requests: 100 sequential round trips, 100 hits against your per-minute rate ceiling, and 100 chances for one to time out and complicate your retry logic. Every one of those costs is linear in the number of IDs, so the loop that felt fine on 10 posts falls over on 10,000.

by_id collapses that into one request for every 100 posts. The difference is not a micro-optimization; it is the difference between a pipeline that fits inside a rate limit and one that does not.

A request per ID versus one batched call

The grid makes the tradeoff concrete. A per-id loop is 100 GETs, 100 units of rate-limit pressure, and 100 round trips to hydrate 100 posts. The by_id path is one GET, one unit of pressure, and one round trip for the same 100 posts. The one place the loop looks simpler is error handling, because each call maps to exactly one id and a 404 tells you that specific post is gone. by_id trades that for a set difference: it drops missing IDs silently, so you learn what is gone by comparing what you asked for against what came back. That is a few lines of code, covered below, and a fair trade for cutting your request count by two orders of magnitude.

Developers hit this exact wall on Reddit's API constantly. One asked how to update the recorded score of a database of submissions without querying a single object every couple of seconds, which is the per-id loop failing under its own weight:

r/

r/redditdev·u/naht_a_cop

[praw] GET multiple objects by 'thing_id' in 1 query?

00

Open on Reddit

The answer to that question is by_id. It is built for exactly the periodic-refresh job: you keep a table of IDs, and every so often you re-hydrate them in batches of 100 to pick up new scores and comment counts.

---

One Call Hydrates a Hundred IDs

Here is the whole hydration call. You join your fullnames with commas, put them in the path, attach one Authorization: Bearer header, and read the posts array off the response:

import os
import requests

API_KEY = os.environ["REDDITAPI_KEY"]
BASE = "https://api.redditapis.com"
HEADERS = {"Authorization": f"Bearer {API_KEY}"}

def hydrate(fullnames):
    ids = ",".join(fullnames)
    resp = requests.get(
        f"{BASE}/api/reddit/by_id/{ids}",
        headers=HEADERS,
        timeout=60,
    )
    resp.raise_for_status()
    return resp.json()["posts"]

wanted = ["t3_1abd8hb", "t3_1avv96a", "t3_1cw07hd"]
posts = hydrate(wanted)

for p in posts:
    print(f"[{p['upvotes']:>6} up, {p['comments']:>4} com] r/{p['subreddit']}: {p['title']}")

The response carries a posts array, and each element is a full post object with the same shape as any listing: id and name (the fullname), title, author, subreddit, permalink, url, upvotes (the net score), comments (the comment count), upvote_ratio, text (the self-post body), created_utc, and the moderation flags like over_18, stickied, and locked. Note the field is upvotes, not score, and comments is the count, not the comment tree. That naming is stable across every read endpoint, so code that reads a search result reads a by_id result without changes.

If all you have is a short id like abc123 rather than a full t3_abc123, prefix it before you call. Building the fullname is a string join, not another request:

def to_fullname(short_id):
    return short_id if short_id.startswith("t3_") else f"t3_{short_id}"

short_ids = ["1abd8hb", "1avv96a"]
posts = hydrate([to_fullname(s) for s in short_ids])

This is the step people expect to be harder than it is. The demand to pull Reddit data without fighting the access layer for every read is a constant refrain, and hydrating a known set of IDs is the cleanest version of it:

Alvaro Cintas

@dr_cintas

your ai agent doesn't need a single paid api to browse the internet anymore 🤯 it's called agent-reach. one pip install and your agent can read twitter posts, browse reddit threads, search github, and watch youtube - without paying for a single api subscription. what your http… Show more

One call in, a batch of full posts out. The only thing left to handle well is scale and the posts that are no longer there.

---

Batch More Than a Hundred IDs

The 100-fullname ceiling is a per-call limit, not a total. When you hold more than 100 IDs, you chunk them into groups of 100 and make one call per chunk. A managed endpoint rejects a call carrying more than 100 fullnames rather than quietly truncating it, so the chunking is not optional politeness, it is how you avoid a rejected request. Here is the batcher:

def chunked(seq, size=100):
    for i in range(0, len(seq), size):
        yield seq[i:i + size]

def hydrate_all(fullnames):
    out = []
    for batch in chunked(fullnames, 100):
        out.extend(hydrate(batch))
    return out

# 250 IDs become 3 calls (100 + 100 + 50), not 250
all_ids = [f"t3_{s}" for s in load_my_ids()]
posts = hydrate_all(all_ids)
print(f"hydrated {len(posts)} of {len(all_ids)} requested")

The arithmetic is the point. A per-id loop over 250 IDs is 250 requests; the batcher is 3. Across a table of 10,000 IDs it is 100 requests instead of 10,000, which is the difference between a job that finishes inside your rate window and one that spreads across an hour of backoff. Reddit's own listing depth caps at 1,000 posts per feed, so re-hydration by known id is often the only way to keep a larger archive current after the live feed has moved past it.

The hydration pipeline, end to end

The pipeline above is the shape of nearly every real by_id job. You collect fullnames from wherever they arrive (a search, a listing, a stream, a database), batch them into 100s, call by_id per batch, then diff and store. The state you carry between steps is just the list of IDs, so it parallelizes cleanly: independent batches can run concurrently up to your rate limit, and the diff step catches anything that fell out.

The pattern is old and well worn. Developers have been feeding multiple fullnames into by_id for years, sometimes tripping over the exact comma-separation contract this endpoint standardizes:

r/

r/redditdev·u/mattgwwalker

[PRAW] Getting multiple submissions using by_id

00

Open on Reddit

---

The Dropped-ID Contract

Here is the one behavior that separates a correct by_id pipeline from a broken one: the response is not guaranteed to match your request. When a fullname points at a post that was deleted, removed, or never existed, Reddit does not return an error or a null placeholder for it. It simply leaves that post out of the array. Ask for 100, and if 4 are gone, you get 96 posts back with nothing to flag the 4 that vanished.

That means you cannot assume posts[i] corresponds to wanted[i], and you cannot trust len(posts) == len(wanted). The correct pattern is a set difference between the fullnames you asked for and the name values that came back:

def hydrate_with_diff(fullnames):
    posts = hydrate(fullnames)
    returned = {p["name"] for p in posts}
    missing = [fn for fn in fullnames if fn not in returned]
    return posts, missing

wanted = ["t3_1abd8hb", "t3_1avv96a", "t3_deleted99"]
posts, missing = hydrate_with_diff(wanted)
print(f"got {len(posts)} posts, {len(missing)} gone: {missing}")

Treat the missing list as authoritative: those posts are no longer available through the API, whether they were removed by a moderator, deleted by the author, or belong to a suspended account. For a dedup or archive job, that is a signal worth recording, because a post dropping out of by_id is often the first machine-readable sign that it was taken down. Building the diff also makes your pipeline idempotent: re-running the same batch returns the same live posts and the same missing set, so a retry never double-counts or silently skips.

This is the subtle failure that bites teams who assumed a one-to-one mapping. If you index posts positionally against your request list, a single dropped id shifts every entry after it, quietly corrupting your data with no error to warn you. Key on name, diff the sets, and the shift is impossible.

---

What Developers Build on Bulk Hydration

by_id is rarely the whole job. It is the refresh step inside a larger pipeline, and three jobs cover most of what teams build on it. Knowing which one you are doing tells you how often to re-hydrate and how to treat the dropped IDs.

Stream hydration is the first. A live pipeline (a keyword monitor, a mention tracker, a subreddit firehose) surfaces IDs faster than it can afford to fetch each one individually. You buffer the incoming fullnames, batch them, and hydrate in groups of 100, which keeps your request count flat even when the stream spikes. The IDs arrive over time; the hydration happens in efficient batches.

Backfill is the second. You have a stored set of post IDs (from an old scrape, a partner feed, or a listing you paged through months ago) and you need the current data behind them. Reddit's live listings only reach back so far, so re-hydrating known IDs is the way to refresh an archive after the feed has scrolled past. One call per 100 IDs turns a backfill that would be thousands of single requests into a short, rate-friendly batch job.

Dedup and score-refresh is the third. You keep a table of posts you have already seen and periodically re-check their scores, comment counts, and removal status. This is precisely the "update the recorded score of a database of submissions" job from r/redditdev earlier, and by_id is the tool built for it: hydrate the batch, update your rows, and use the dropped-ID diff to mark posts that have since been removed.

All three share the same skeleton, and all three break in the same way if you skip the dropped-ID diff. Build that diff once and reuse it everywhere.

---

The Native reddit.com/by_id Path (and Its Limits)

Reddit exposes by_id directly. Append .json to the by_id path and you get the same data unauthenticated: https://www.reddit.com/by_id/t3_abc123,t3_def456.json. It is free, needs no developer app, and is the right tool for a quick hydration from your own machine. Here is the native call:

import requests

URL_TMPL = "https://www.reddit.com/by_id/{ids}.json"
HEADERS = {"User-Agent": "by-id-tutorial/1.0 (by u/your_username)"}

def hydrate_native(fullnames):
    ids = ",".join(fullnames)
    resp = requests.get(URL_TMPL.format(ids=ids), headers=HEADERS, timeout=30)
    resp.raise_for_status()
    children = resp.json()["data"]["children"]
    return [c["data"] for c in children]

posts = hydrate_native(["t3_1abd8hb", "t3_1avv96a"])
for p in posts:
    print(f"[{p.get('score', 0)} up] {p['title']}")

The native response is a standard Reddit listing: a data.children array where each child wraps a post under a {"kind": "t3", "data": {...}} envelope, so you reach the post fields at child["data"] and the score lives under score rather than a flattened upvotes. The dropped-ID behavior is identical: a missing fullname is simply absent from children, so you apply the same set diff.

Two things limit the native path in production. First, the rate ceiling: 60 requests per minute unauthenticated is fine for a handful of batches and tight for a service. Second, and more disruptive in 2026, the IP filter. Reddit blocks a large share of cloud and datacenter IP ranges, so the same call that works from your laptop returns 403 from an AWS, GCP, or DigitalOcean box no matter how clean your headers are. This is the single most common reason a correct hydration script fails on a server. A quick way to confirm it is to run the identical script locally: if it works on your laptop and 403s on the box, you have an IP filter, not a code bug. The managed path trades the dollar cost of the call for a clean pool, one bearer header, and a flat posts array. For the broader access picture, see the authentication and OAuth guide and the rate-limits reference.

---

What It Costs at Volume

Bulk hydration has a cost shape that rewards batching. The native .json path is free in dollars but costs engineering time: an IP pool to dodge 403s, OAuth-app upkeep, and the rate-limit backoff you maintain. A managed REST path prices per call instead, at $0.002 per GET (pricing), with the first $0.50 of credit free at signup and no card required.

The number that matters is calls, not IDs, and batching is what keeps it low. Hydrating 10,000 IDs is 100 by_id calls, roughly $0.20 in GETs, because each call carries up to 100 fullnames. The same 10,000 IDs through a per-post loop would be 10,000 calls, both far slower and 100 times the request volume against your rate limit. That is the whole argument for by_id in one line: the price and the rate-limit cost both scale with your call count, and batching cuts your call count by up to 100x. Model your real numbers with the cost calculator before you commit, and cross-check the per-operation detail on the pricing page.

---

Verdict

For a one-off hydration of a couple of IDs from your own machine, the native reddit.com/by_id/...json path is the right answer: free, no OAuth, and you can paste the code above and have posts in two minutes. The moment hydration becomes a recurring job (a stream buffer, a nightly backfill, a dedup refresh) the math flips to batching, because a per-post loop is one request per id and by_id is one request per hundred. The pipeline is small and the same every time: collect fullnames, chunk into 100s, call by_id per chunk, and diff the returned name values against what you asked for so a dropped post never shifts your data. The native path does the fetch for free until the 60-per-minute ceiling and the cloud-IP 403s push the job onto a managed pool. Start with the free path, measure how often you re-hydrate, and move to a managed endpoint like https://api.redditapis.com/api/reddit/by_id/... when the limits bite. The comments guide covers hydrating a post's discussion, the search tutorial covers discovering the IDs in the first place, and the pagination guide covers paging a listing into the IDs you then hydrate. Grab a free key and run the batch call.