Reddit API Pagination: The after Cursor and Getting Past the 1000-Item Ceiling (2026)

Reddit pagination trips up almost everyone the first time, because it does not work like the paginated APIs most developers learned on. There are no page numbers, no total count, and no offset.

TL;DR: Reddit listings are cursor-paginated. Each response returns up to 100 items plus a top-level after token, which is a fullname like t3_1tws1w7. Pass it back as after to get the next page, and stop when after is null. Two gotchas we confirmed live on 2026-07-12: limit caps at 100 (asking for 200 returns 400), and you must pass the fullname, not the bare id, or you silently get page one again. Forward paging exhausts at about 1000 items per listing (we counted 949 for r/python new, 959 for r/webdev), so completeness past the ceiling needs time-windowing, search, historical dumps, or an index that stores history.

This is an independent, third-party tutorial. It walks the whole model with copy-paste Python, states the exact mechanics we verified live, and maps the four real strategies for getting complete data once the listing runs out. If you are new to the read endpoints, start with the Reddit API Python tutorial and the guide to getting a Reddit API key, then come back here for paging.

A quick mental model: cursors, not pages

Before any code, fix the mental model, because most Reddit pagination bugs are really a page-numbering assumption in disguise. The API does not have pages. It has a stream of items and a bookmark. Every request hands you the next chunk of the stream plus a bookmark that says "you are here," and your next request says "give me what comes after this bookmark." That is the entire contract.

• No page numbers. There is no page=2 and no offset. Asking for "page 5" is not a thing the API understands.
• No total count. A response never tells you how many items exist, only whether there is a next one.
• One bookmark forward, one back. after moves toward older items, before moves toward newer ones.
• The bookmark is an item, not a position. It is the fullname of a specific post, so it stays correct even as new posts arrive at the top of the feed.

This is cursor-based pagination, and Reddit is not unusual in using it. It is the same approach GitHub's REST API and most high-volume APIs adopted, because offset pagination drifts the moment the underlying list changes, as the Nordic APIs pagination guide explains. Hold this model and the rest of the post is detail.

How pagination works in the Reddit API

In practice, cursor pagination means every listing response carries a top-level after token that names the last item in the batch, and you feed that token back on the next request. When there is nothing left, after comes back null. Reddit documents this in its own API listing reference. The shape is identical whether you are paging a subreddit feed, a user's history, or a search result.

Here is one live request against a managed REST path. The response is a posts array plus a top-level after:

curl -s "https://api.redditapis.com/api/reddit/posts?subreddit=python&sort=new&limit=100" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); print('items:', len(d['posts']), '| after:', d['after'])"

Run that and you get items: 100 | after: t3_1tws1w7. The after value is your cursor for page two. Nothing about the first call tells you how many pages exist, because cursor pagination does not know: it only knows whether there is a next item. That is the mental shift. You loop until the cursor dries up, not until you reach a known page count. The same model applies to paging a search query, and it is why the data API overview describes every listing endpoint the same way.

What the after cursor actually is

The after token is not an opaque blob and it is not a number. It is a Reddit fullname: the two-character type prefix t3_ for a post (a "link"), followed by the base36 id of the item, for example t3_1tws1w7. Reddit documents the prefixes in its fullnames glossary: t1_ is a comment, t3_ is a post, t5_ is a subreddit.

Every post object you get back carries both an id (1tws1w7) and a name (t3_1tws1w7), and the listing's after equals the name of the last post in the batch. That detail is the single most common pagination bug, which we reproduced live on 2026-07-12. If you take the bare id and pass it as after, Reddit ignores it and hands you page one again. We paged r/python new, took the last post's id 1uleil4, and requested the next page two ways:

# WRONG: bare id is silently ignored, you get page one again
curl -s "https://api.redditapis.com/api/reddit/posts?subreddit=python&sort=new&limit=25&after=1uleil4" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); print('first id:', d['posts'][0]['id'])"

That returned the same first id we started with. Passing the fullname t3_1uleil4 instead returned a genuinely new page with zero overlap. If your loop seems to run forever or your cursor "keeps coming back null," check that you are passing the fullname. This is exactly the confusion in the r/redditdev "Reddit APIs Pagination" thread, where the poster is stuck on which value to send. The rule is simple: read after from the response and pass it straight back, unmodified. Do not rebuild it from the id, because the response hands you the correctly formatted cursor already.

The 100-per-page cap, and why limit=200 fails

Reddit caps a single listing request at 100 items. The default when you omit limit is 25, so the first thing to do at any real volume is set limit=100 to cut your request count by four. Asking for more does not get you more. We sent limit=200 on 2026-07-12 and got a hard 400:

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://api.redditapis.com/api/reddit/posts?subreddit=python&sort=new&limit=200" \
  -H "Authorization: Bearer YOUR_API_KEY"

The body is {"error":"limit must be an integer between 1 and 100"}. There is no bulk mode, no limit=1000 shortcut, and no batch endpoint that returns a whole subreddit in one call. Complete data is always many requests glued together with the cursor.

The practical consequence is arithmetic. To pull 1000 items you make at least 10 requests. To pull 10,000 you make at least 100. Every one of those counts against your rate limit, so limit=100 is not a nicety, it is the difference between 10 requests and 40 for the same data. The table below is the whole caps-and-ceiling picture in one place.

Parameter	Value	Notes
Default limit	25	Applied when you omit limit
Max limit	100	limit=200 returns HTTP 400
Cursor param	after	A fullname like t3_<id>, not a page number
Backward cursor	before	Walk toward newer items
Listing ceiling	~1000 items	after goes null; measured 949 for r/python new
Requests for 1000 items	10+	At limit=100

Paginating a full listing in Python

Putting it together, a correct pagination loop reads after from each response, passes it back, and stops when after is null or when it hits a page guard you set. Always guard your loops, because a bug or a hostile feed should never spin forever. Here is a copy-paste loop that pages a subreddit new feed at 100 per request:

import requests

BASE = "https://api.redditapis.com/api/reddit"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY", "Accept": "application/json"}

def paginate_subreddit(subreddit, sort="new", max_pages=5):
    posts, after, pages = [], None, 0
    while pages < max_pages:
        params = {"subreddit": subreddit, "sort": sort, "limit": 100}
        if after:
            params["after"] = after          # pass the fullname straight back
        r = requests.get(f"{BASE}/posts", headers=HEADERS, params=params, timeout=30)
        r.raise_for_status()
        data = r.json()
        batch = data.get("posts", [])
        posts.extend(batch)
        after = data.get("after")            # None means the listing is exhausted
        pages += 1
        if not batch or not after:
            break
    return posts, after

items, last_after = paginate_subreddit("python", max_pages=3)
print(f"collected {len(items)} posts, last cursor: {last_after}")

Three things make this loop correct, and each one maps to a bug you would otherwise hit:

• It sets limit=100, so every call does maximum work and you make a quarter of the requests you would at the default 25.
• It reads after from the response rather than constructing it, which avoids the bare-id bug entirely.
• It has a max_pages guard, so a runaway or looping feed cannot hang your job.

Swap sort="new" for hot, top, or controversial to page a different ordering, and add "t": "year" for the top and controversial sorts to set the time window. The Node.js tutorial shows the same loop with Promise batching if you work in JavaScript, and the same structure paginates a user's post history if you swap the endpoint.

The ~1000-item ceiling: what we measured live

Here is the part the "just loop with after" answers leave out. The loop does not run forever, and it does not return the whole subreddit. Reddit caps listing depth, so after eventually comes back null well before you have every post. We ran the loop live on 2026-07-12 across three listings at limit=100, following the cursor until it went null, and counted the unique items:

• r/python new: 949 unique posts over 10 requests, then after was null.
• r/webdev new: 959 unique posts over 10 requests, then null.
• search python sorted by new: only 244 unique posts over 3 requests, then null.

Both subreddits land at the classic roughly-1000 native listing ceiling, and neither is the full subreddit; r/python has posted far more than 949 items in its history. This is not a bug in any client. It is Reddit's listing depth cap, and it passes through every path that reads native listings, whether you use the raw .json endpoint, a wrapper, or a managed REST layer. It is the same wall this r/DataHoarder poster hit with saved posts, which cap at 1000 for the same reason:

Just had the massive sinking feeling the moment I realized I can't view over 1000 saved posts.

r/DataHoarder·u/DrJosh999

Reddit Saved Posts Limit

00

Open on Reddit

If your goal is monitoring or a recent sample, the ceiling never bites, because you rarely need more than the latest few hundred items. If your goal is a complete archive of an active subreddit, forward pagination alone will silently under-deliver, and you need one of the strategies below.

Why search paginates differently, and stops sooner

Search is a listing too, so it also returns an after cursor and pages the same way. But search depth is shallower than a subreddit feed, which surprises people building keyword pipelines. In the same 2026-07-12 run, paging a search for python sorted by new exhausted at only 244 unique items over 3 requests, far short of the ~1000 a subreddit new feed reaches.

The takeaway is that you cannot page one broad search to completeness. The fix is to narrow and repeat:

• Scope the search to a single subreddit so each query surfaces a deeper slice of a smaller pool.
• Tighten the query so fewer, more relevant items come back per window.
• Slide a date range across the period you care about, keeping each pull under the depth cap.

This is the pattern the search API tutorial uses, and it is what this r/redditdev poster is reaching for when their after "keeps coming back null" on a comment listing. Comments paginate on the same cursor model but through a different surface, the more and morechildren expansion, which the comments tutorial covers in full. If you are pulling both posts and their comments, budget for two different pagination shapes, not one.

Four strategies to get complete data past the ceiling

Once you accept that a single forward pass caps at roughly 1000 items, "get all posts from a subreddit" becomes a strategy question, not a loop question. There are four honest ways past the ceiling, and each fits a different job. Picking the wrong one is why so many Reddit data projects quietly ship with holes in the dataset.

• Forward pagination. Page new with after until it runs out. Perfect for the latest few hundred items and for ongoing polling. It caps at ~1000, so it is not an archive tool.
• Multi-sort and time-windowing. Page new, then hot, then top with each t value (hour, day, week, month, year, all). Each sort surfaces a partly different 1000-item slice, so the union covers more of the subreddit than any single feed. It still will not be exhaustive on a huge subreddit, but it widens coverage cheaply.
• Search across date ranges. Scope a search to the subreddit and slide a date window so each pull stays under the depth cap. Good for keyword archives and topic monitoring, weaker for a full post-by-post dump.
• A historical index or dump. For the genuine back catalog, pull from an archive that already stored the subreddit's history, the way Pushshift did and its successors like PullPush and the community academic-torrent dumps still do. Our guide to Pushshift alternatives ranks the current options.

The multi-sort approach is what this DataHoarder poster is groping toward when they try to grab an entire subreddit with a scraper and end up pulling in items from outside it:

r/DataHoarder·u/d0pe-asaurus

Anyway to backup an entire subreddit?

00

Open on Reddit

For the historical route, the community still leans on bulk dumps rather than the live API, because the live API cannot reach that far back through pagination:

r/pushshift·u/Watchful1

Separate dump files for the top 40k subreddits, through the end of 2024

00

Open on Reddit

Most real pipelines combine two of these: forward polling for freshness plus a historical source for the archive. Founders building lead-gen and research pipelines on Reddit data run into exactly this seam, as this builder describes ingesting two years of history to make the dataset useful:

Anthony Yim

@anthonyyim

I messed up bad! I missed all the stocks that are related to AI bottlenecks like $MU or $BE The signs where there all along So I built a pipeline to ingest Reddit data for past 2 years to systematically track Reddit gossip It works First mention of $MU here: https://t.co/tdg… Show more

Pagination gotchas that silently break your loop

The dangerous pagination bugs do not throw errors. They return plausible-looking data with gaps, and you find out weeks later that your dataset is short. These are the ones we have hit or reproduced, in rough order of how often they bite:

• Bare id instead of fullname. Pass t3_..., not the bare id, or you re-request page one. The number one cause of "infinite" loops, covered above.
• A deleted anchor. If the post your cursor points at gets deleted, the next page can come back empty or wrong. Keep the last several cursors, not one, and fall back if the newest anchor vanishes.
• Duplicates across pages. On a fast-moving new feed, items can shift between requests and appear twice. Deduplicate by id as you collect, never trust the batch to be disjoint.
• Forgetting limit=100. Leaving limit at the default 25 quadruples your request count and burns your rate limit four times as fast for the same data.
• Treating a null after as an error. A null cursor is the normal, expected end of a listing, not a failure. Break the loop, do not retry.

The deleted-anchor failure is subtle and real. Pollers that store one fullname and re-request from it an hour later break when that post is removed, exactly as described in the r/redditdev "Cant use deleted post to paginate" thread. That thread also independently confirms the cursor is a fullname, since the poster stores "the newest post as a fullname" in their database. A managed endpoint that returns a stable after on every call sidesteps the single-point-of-failure cursor.

Cost and rate limits when you paginate at volume

Because completeness is always many requests, pagination is where your rate limit and your bill actually get spent. The current Reddit developer platform meters read traffic per authenticated client, and the rate-limits guide covers the live ceilings; the practical point for paging is that request count, not data size, is what you are rationing. At limit=100, the math is linear:

• 1000 items: about 10 GETs, roughly $0.02 on a $0.002-per-call managed path.
• 10,000 items: about 100 GETs, roughly $0.20.
• A daily 1000-item sweep: about 300 GETs a month, roughly $0.60.

The native .json and OAuth paths are free in dollars but cost engineering time in auth, retries, and an IP pool to survive datacenter 403s, and they still stop at the ceiling. A managed REST endpoint prices per call instead, at $0.002 per GET, with the first $0.50 of credit free at signup and no card required. Those are standard published figures; model your own numbers with the cost calculator and the pricing page, because at low volume the free path can be the right call.

Native json, PRAW, and managed REST for pagination

All three common paths use the same after cursor, but they differ in how much of the loop, the retries, and the ceiling workarounds you write yourself. The differences matter most when you page at volume:

• Raw .json endpoint. Hands you the cursor and nothing else. You write the loop, the retries, the deduping, and the datacenter-IP handling, and you still hit the ceiling. Free, maximum control, maximum plumbing.
• PRAW. Wraps the loop in Python generators, so subreddit.new(limit=None) pages for you until the ceiling. Convenient, but it hides the cap that is about to bite you, and it inherits the same OAuth setup and IP constraints.
• Managed REST. Returns a stable after on every call and handles auth and retries, so your job is the loop and the strategy, not the plumbing.

The REST versus PRAW breakdown and the PRAW versus managed REST comparison go deeper on the tradeoffs, and the authentication guide covers the OAuth setup the first two paths require. For a video walkthrough of pulling Reddit data end to end, this independent tutorial covers the scraping route many developers reach for when the API path frustrates them:

Whichever client you choose, the pagination model is identical, so the code in this post ports directly. The only thing that changes is how much of the retry and ceiling handling you write yourself.

What developers keep running into in 2026

The recurring pattern in public developer chatter is that people expect page numbers, get a cursor, and then discover the ceiling only after their dataset ships short. The demand for programmatic Reddit access is loud right now, driven by AI pipelines that treat Reddit as a primary source. This widely-shared thread about free agent access captures the appeal:

your agent can search Twitter, Reddit, and GitHub for free, zero API keys, zero billing

Isra

@israfill

your agent can search Twitter, Reddit, and GitHub for free - zero API keys, zero billing 😳 agent-reach is trending on github with 23K stars. it lets your AI agent read Twitter posts, browse Reddit threads, search GitHub repos, watch YouTube videos - all without paying for a htt… Show more

The tension in that thread is the whole story of this post. Free, unauthenticated access is appealing until you hit the ~1000 ceiling and the datacenter IP filter, at which point "just scrape it" quietly becomes "I have a partial dataset and cannot explain the gaps." The developers who ship complete Reddit pipelines are the ones who understood the cursor, respected the ceiling, and picked a completeness strategy on purpose. The r/redditdev archive is full of the same realization arriving late, from "time_filter is very unsatisfactory" to "way to paginate through ALL subreddits", and the answer is always the same: forward paging for freshness, a historical source for depth. The subreddit discovery guide helps you scope which feeds are even worth paging.

Verdict: when to loop, when to window, when to buy the index

Reddit pagination is a small, precise contract once you see it clearly:

• Read after from every response and pass it back unchanged as a t3_ fullname.
• Set limit=100 so each call does maximum work.
• Stop when after is null, and never retry a null cursor.

That loop is correct and it is enough for monitoring, sampling, and any job that needs the latest few hundred items, which is most jobs. It is ten lines of code and it will never let you down inside the ceiling.

The judgment call is completeness. The moment your job needs more than roughly 1000 items from a listing, forward paging is the wrong tool, and the honest options are multi-sort and time-windowing for breadth, search across date ranges for keyword archives, and a historical index or dump for the full back catalog. Most durable pipelines run two lanes at once: poll new for freshness, pull from an index for depth. Decide which lane your project needs before you write the loop, not after you notice the gaps.

If you want the loop without the plumbing, the managed Reddit data API returns a stable after on every call, handles the auth and retries, and keeps an index so completeness is a query instead of a terabyte download. You can sign up for the first $0.50 of credit free with no card, read the pagination and listing docs, and page your first subreddit in a couple of minutes. This site is an independent, third-party tool and is not affiliated with Reddit.