Reddit's .json Endpoint Is Dead in 2026: Every Way to Still Pull Reddit Data

If you built anything on the old reddit.com/r/subreddit.json trick, the last two years have not been kind to you. The pattern that powered a thousand side projects, append .json to any Reddit URL and get clean structured data back with no key and no login, has quietly stopped being reliable. The requests still go out. The 429s come back. And the fix is not a bigger proxy list.

TL;DR: Reddit's public .json endpoints are not truly gone, but they are rate-limited, User-Agent gated, and unreliable at any real volume since Reddit tightened API access in mid-2023. Unauthenticated collectors hit 429 Too Many Requests fast, and r/redditdev is full of developers documenting the drop. There is no single drop-in replacement, there is a menu: the official Reddit Data API through an approved OAuth app, your own OAuth script, a managed third-party REST API, PullPush and Arctic Shift for historical data, community data dumps for offline archives, and headless scraping as the fragile last resort. This guide compares all six on volume, effort, cost, and reliability, then gives you a migration playbook for your broken .json scraper. This is a developer explainer, not legal advice. redditapis.com is an independent third-party not affiliated with Reddit Inc.

This is a practical migration guide. It explains exactly what changed, why the old trick stopped working, and every current route to still pull Reddit data in 2026, with the honest tradeoffs of each. By the end you will know which option fits your use case and how to move your code off the dead path without rebuilding your entire stack.

The illustration above is the entire trick in three moves, and that simplicity is exactly why so many projects leaned on it. No registration, no token, no client library. For years you could point any HTTP client at a Reddit listing, tack on .json, and parse the response. That era is effectively over for automated use, and understanding why is the first step to fixing it.

What Happened to Reddit's .json Endpoint in 2026

Reddit's public .json endpoints still exist, but in 2026 they behave like a locked door with a small mail slot: fine for the occasional single request, useless for anything that loops. Since Reddit began enforcing its Data API terms and rate limits in mid-2023, unauthenticated traffic to the append-.json paths gets a much smaller allowance than an authenticated OAuth client, returns 429 Too Many Requests quickly under load, and is filtered when it arrives with a blank or generic User-Agent. Nothing was announced as a formal shutdown of the .json path. It simply degraded until scrapers built on it stopped being dependable.

The clearest evidence is not a press release, it is the steady stream of developers on r/redditdev reporting the exact same symptom: a script that ran fine last year now gets throttled within a handful of requests.

r/redditdev·u/matheusAMDS

Requesting r/<subreddit>.json constantly gives me 429

00

Open on Reddit

That thread is one of many. Search r/redditdev and you find a recurring pattern going back to 2023: "rate limit on .json endpoints suddenly much lower," "new rate limit for JSON endpoint API," "requesting r/subreddit.json constantly gives me 429." The community consensus is consistent. The endpoint was never officially killed, it was tightened to the point where treating it as a free bulk data source no longer works.

One thread captures the moment the change landed for a lot of developers at once:

r/redditdev·u/barrycarey

Rate Limit On .json Endpoints Suddenly Much Lower?

00

Open on Reddit

Read the comparison above as a summary of the whole shift. The technical mechanics of the endpoint did not change much. What changed is the enforcement around it, and enforcement is what your scraper actually collides with. The next section explains the specific levers Reddit pulled.

Why the Old ".json Trick" Stopped Working

The .json trick stopped working because Reddit moved data access behind authentication and enforcement, and the public paths inherited the strictest, lowest-trust tier of that system. Three levers do most of the damage: unauthenticated requests get a small published rate allowance compared with an OAuth client, generic or missing User-Agent strings are filtered, and traffic that loops past the allowance gets 429 responses that escalate the harder you push. Add shared-IP effects from cloud hosts and the occasional interstitial challenge, and a naive loop over .json URLs falls over almost immediately.

The mechanism is worth understanding rather than guessing at, because it tells you which fixes are real and which are cargo-cult. Slowing your request rate helps at the margin, since the limit is per-window. Rotating a residential proxy pool helps for a while, since some limits key partly on IP. But neither changes the fundamental asymmetry: Reddit gives authenticated, approved clients a documented and materially higher allowance, and gives anonymous traffic the scraps. You are not fighting a bug, you are fighting a design decision.

Developers describe the collision in almost identical terms, a documented limit that the requests never seem to actually get:

Federico De Ponte

@fedeponte1

just spent 4 hours not building, just waiting &gt; hit reddit API &gt; 429 after 3 requests &gt; check docs: "60 requests per minute" &gt; [that's a lie] &gt; add exponential backoff &gt; still 429 &gt; try OAuth instead of basic auth &gt; same limit, different error message &gt… Show more

A blank User-Agent is the most common self-inflicted wound. Reddit's own guidance has long asked developers to send a unique, descriptive User-Agent that identifies the app and a contact, and default library User-Agents or empty strings are exactly the fingerprint the filters look for. A copied snippet that worked in 2022 can fail today for no reason other than the header it ships with. Setting a proper User-Agent is a minimum, though, not a cure, because the rate limits still apply once you authenticate the request or not. The Reddit API rate limits guide has the current published numbers, and the authentication guide shows the header and token setup that moves you into the higher tier.

The practical takeaway is blunt. The .json path is not a data pipeline anymore. If you need Reddit data in 2026, you need a real access route, and there are more of them than most developers realize.

Every Way to Still Pull Reddit Data in 2026: The Full Menu

There is no single replacement for the .json trick, but there is a full menu of six real routes, and the right one depends on whether you need live or historical data, your volume, and how much infrastructure you want to run. The options are: the official Reddit Data API through an approved OAuth app, your own OAuth script or web app, a managed third-party REST API, PullPush and Arctic Shift for historical queries, community data dumps for offline archives, and headless-browser scraping as a fragile last resort. Every one of them has a real tradeoff, and pretending otherwise is how developers pick the wrong one.

Use the menu above as the map for the rest of this guide. The first split to make is live versus historical. If you need what is on Reddit right now, this hour, you are in the API family: official, self-built, or managed. If you need what was posted last year, or a complete archive of a subreddit, you are in the dumps-and-archives family: PullPush, Arctic Shift, or torrents. Scraping sits off to the side as the option you reach for only when nothing else can give you what you need. The rest of the article works through each route in that order.

Option 1: The Official Reddit Data API (and the Approval Gate)

The official Reddit Data API is the canonical live-data route, and in 2026 it runs through an approval gate rather than instant self-service for anything beyond small personal use. You register an application in your Reddit account preferences, agree to the Data API terms, and, depending on your intended use and volume, request access under Reddit's current developer policy. Once approved you receive OAuth credentials, mint a token, and call documented endpoints with a published rate allowance that is far more generous than the anonymous .json path. It is the most legitimate route and the source of truth for live reads and writes.

The flow above is straightforward on paper. The friction is the approval step, which is not guaranteed and not always fast. Reddit's developer policy asks about your use case, and commercial, high-volume, or model-training use is treated differently from a hobby script. Some applications sail through, others sit without a response, and that uncertainty is the single biggest reason developers look at other routes. The Reddit Data API overview covers the approval process, the rejection patterns, and what to do if you cannot get in, and the how to get a Reddit API key guide walks the registration screen step by step.

Once you are through, the official API is capable and well documented. Reddit publishes its endpoint reference at reddit.com/dev/api, the official Data API wiki documents the access rules and free-tier limits, and the Data API terms spell out what you agree to. If your use is a fit and you have the patience for the gate, this is the route with the fewest surprises later.

Option 2: Build Your Own OAuth App

Building your own OAuth app is the do-it-yourself version of Option 1, and it is the right call when you want full control and are comfortable owning token refresh, retries, and rate-limit handling. Reddit supports several app types, and for server-side data collection the "script" type is the simplest: you get a client ID and secret, exchange them for a token, and send that token on every request. The published allowance for an authenticated client is materially higher than the anonymous .json path, which is the whole point of authenticating.

Here is the minimal token exchange for a script app, using nothing but curl:

# Exchange your script-app credentials for an OAuth token
curl -s -X POST "https://www.reddit.com/api/v1/access_token" \
  -u "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET" \
  -d "grant_type=password&username=YOUR_USER&password=YOUR_PASS" \
  -H "User-Agent: my-reddit-app/1.0 by u/your_username"

Once you have the token, every authenticated call goes to the oauth.reddit.com host with an Authorization header, and you send the same descriptive User-Agent every time:

# Use the token to read a subreddit's new posts
curl -s "https://oauth.reddit.com/r/redditdev/new?limit=25" \
  -H "Authorization: bearer YOUR_ACCESS_TOKEN" \
  -H "User-Agent: my-reddit-app/1.0 by u/your_username"

The self-built route trades convenience for control. You own the OAuth refresh loop, the backoff logic when you approach the limit, and the pagination. That is fine for a focused single-purpose collector and it gets tedious fast when you need many endpoints, DMs, writes, or high uptime. The Reddit API Python tutorial shows the same flow in code, and the REST versus PRAW comparison covers whether to hand-roll requests or lean on a client library.

Option 3: A Managed Third-Party REST API

A managed third-party REST API is the route for teams that want live Reddit data without owning the auth and rate-limit machinery. You send one authenticated request to a single REST surface, and the provider handles OAuth token refresh, retries, backoff, and pagination behind it, returning structured JSON. The tradeoff is control for convenience and time-to-first-result: you give up running your own OAuth loop, and in exchange you ship in an afternoon instead of a sprint.

A managed layer takes over the parts that make a self-built collector tedious:

• OAuth token refresh, so there is no re-auth job to schedule
• Rate-limit backoff, so a burst does not turn into a wall of 429
• Retries and pagination, so one call returns a complete page of structured data

The shape of a managed call is deliberately boring. One bearer token, one endpoint, structured data back:

# One authenticated request, structured JSON back, no OAuth loop to maintain
curl -s "https://api.redditapis.com/api/reddit/search?q=reddit+api&sort=relevance&limit=25" \
  -H "Authorization: Bearer YOUR_API_KEY"

That is the entire integration surface for a read. There is no separate token-exchange step to schedule, no refresh timer, and no per-window backoff code to write, because the layer in front absorbs it. redditapis.com is an independent third-party not affiliated with Reddit Inc, and what it offers is that operational shape: structured data through one documented endpoint, a single bearer token instead of a proxy fleet, and rate limits handled on the provider side. For reads, writes, and DMs, the full API documentation covers the endpoints, and you can compare plans on the pricing page or start with free credit at /signup. The PRAW versus REST comparison walks the migration from a client library to a REST call in code.

Managed is not automatically the answer. If your use is a single hobby script and you enjoy owning the plumbing, Option 2 is cheaper. Managed earns its keep when uptime, breadth of endpoints, or engineering time matters more than saving a few dollars a month.

Option 4: PullPush and Arctic Shift for Historical Data

For historical data, the live-API options do not help, and the community rebuilt what Pushshift used to provide. PullPush.io is the closest drop-in for querying historical comments and submissions by keyword, author, subreddit, and time range, and Arctic Shift offers higher throughput plus hosted dataset exports. Neither is Reddit-official, both are community-run, and that means you trade the certainty of a first-party API for coverage of the past that the official API simply does not offer at scale.

Historical data in 2026 comes from three community-run sources, each tuned for a different job:

• PullPush for on-demand queries by keyword, author, subreddit, and time range
• Arctic Shift for higher throughput and hosted dataset exports
• Community data dumps for an offline-complete archive you query locally

The split above matters because "historical" hides two different needs. If you want to query the past on demand, a few thousand comments matching a term across a date range, PullPush at pullpush.io is the fastest path and its query shape will feel familiar if you ever used Pushshift. If you need higher volume or want to pull down large slices, Arctic Shift, whose tooling lives at github.com/ArthurHeitmann/arctic_shift, is built for throughput and publishes dataset exports.

The honest caveat is reliability. Community services run on community budgets, and uptime is not an SLA. Plenty of developers run PullPush as their primary historical source and keep Arctic Shift as a fallback for exactly that reason. Even data-science practitioners planning projects treat the Reddit API and its ecosystem as one option among several data sources rather than a guaranteed pipeline.

Eyo Eyo, PhD

@Eyowhite3

Look beyond Kaggle in 2024 for data!!! Here are other platforms and ways to get data for your projects: Links are in the thread. 1. Public Repositories 📌World Bank 📌https://t.co/sXNk1Hlzho 2. Social Media APIs 📌Reddit API 📌Twitter API 3. Academic Datasets 📌UCI 📌IEEE

The mindset in that thread is the right one for historical data in 2026: know your options, do not assume any single source is permanent, and keep a fallback. The Pushshift alternatives guide benchmarks PullPush, Arctic Shift, the data dumps, and the official API head to head on historical depth, query latency, and reliability, so you can pick with numbers instead of vibes.

Option 5: Data Dumps and Archives

Data dumps are the offline-complete option, and they are the right choice when you need a large, static slice of Reddit history and would rather query a local file than hit any live service. The Watchful1 data dumps on Academic Torrents provide compressed monthly archives of comments and submissions, and Arctic Shift publishes Parquet exports on Hugging Face that you can query with SQL without downloading everything first. You trade freshness and setup effort for completeness and zero rate limits: once the data is on your disk or in a query engine, nobody throttles you.

Two archive sources cover most needs:

• The Watchful1 monthly dumps on Academic Torrents, compressed comments and submissions
• Arctic Shift Parquet exports on Hugging Face, queryable with SQL before you download everything

The dumps are not for live monitoring. They lag reality by design, and the full archives are large enough that you plan storage before you start. But for research, model training corpora, or any analysis where "everything up to last month" beats "the latest hundred posts," they are unmatched. You can browse the torrents at academictorrents.com and the hosted Parquet datasets at huggingface.co/datasets. For the AI-training angle specifically, where licensing and provenance become the real questions, the Reddit AI training data guide covers what changed and why bulk use is increasingly expected to run through a license.

A common and sensible pattern is to combine dumps with a live route: seed your database from an archive for historical depth, then keep it current with an API for the last mile. That gives you completeness and freshness without asking a single source to do both.

Option 6: Headless Browser and Proxy Scraping (the Last Resort)

Headless-browser scraping is the option of last resort, the one you reach for only when nothing else can give you the specific rendered data you need. You drive a real browser, let the page render, and parse the resulting HTML, optionally routing through residential proxies to spread the load. It can reach data that is awkward to get any other way, and it is the most fragile, highest-maintenance route on this list, and it sits against Reddit's automation terms, so it comes with real operational and compliance weight.

Scraping carries a maintenance bill that a documented API does not:

• Brittle HTML parsing that breaks on the next redesign
• A proxy fleet to run, rotate, and pay for
• Interstitial challenges that interrupt automated sessions

The cost profile above is why scraping rarely stays the answer. Markup changes silently break parsers, so you are always one redesign away from an outage. Interstitial challenges interrupt automated sessions. And you end up running and rotating a proxy fleet, which is its own infrastructure project with its own bills. The residential proxies guide is honest about when you actually need proxies and, more often, when you do not, and the scraping benchmarks post puts real throughput and error-rate numbers next to the API routes.

There is also the terms question. Scraping rendered pages sits against Reddit's automation limits in a way that a documented, authenticated API does not. This is a developer explainer and not legal advice, and the Is scraping Reddit legal guide covers the User Agreement, the Data API terms, and the relevant case law in detail. The short version: scraping is the route with the most moving parts and the most exposure, so treat it as the exception, not the plan.

Cost and Rate-Limit Reality Check

The routes differ enormously on the two numbers that decide whether a pipeline survives contact with production: allowed request rate and total cost of ownership. The anonymous .json path gives you the smallest rate allowance for the highest hidden cost in maintenance, an approved OAuth app gives you a much larger published allowance for the cost of running your own auth, and a managed REST API gives you a predictable rate for a predictable subscription while removing the plumbing entirely. Historical routes sidestep rate limits once the data is local but cost you freshness. Here is how the live routes stack up on request headroom.

Read the chart above as relative headroom, not exact quotas, since Reddit's published numbers change and depend on your approval tier. The shape is what matters: authenticating moves you from the smallest bucket to a much larger one, and that single move fixes most 429 problems that no amount of proxy rotation will. For the current published figures, the rate limits guide is the reference to keep open.

Cost is the other axis, and it is easy to get wrong because the cheapest sticker price is rarely the cheapest total. A self-built scraper looks free until you count the proxy bills and the engineer-hours spent babysitting broken parsers. The real comparison is money plus maintenance, and on that combined measure the routes sort differently than developers expect.

The distribution above is the argument against defaulting to "just scrape it." The visible cost of scraping is low and the hidden cost is high, while a managed API inverts that: a visible subscription and almost no hidden maintenance. Which profile you prefer depends on whether your scarce resource is dollars or engineering time. For most teams shipping a product, engineering time is the constraint, and that is the calculus that keeps pushing broken-.json refugees toward a documented API.

Migration Playbook: Fixing Your Broken .json Scraper

Migrating off a dead .json scraper is a five-step swap, not a rewrite, because the data you want has not changed, only the door you knock on has. The steps are: inventory exactly which endpoints your scraper hits, decide live versus historical for each, pick the matching route from the menu above, replace the fetch layer while keeping your parsing and storage, and add proper auth and a descriptive User-Agent. Done in that order, most scrapers migrate in a day, and you keep every downstream consumer that already depends on your data shape.

Work the playbook above one endpoint at a time. Start with the highest-volume path in your scraper, because that is the one hitting 429 hardest and the one whose fix buys the most stability. If it needs live data, an authenticated API call replaces the anonymous .json fetch with minimal change to the rest of your code, since the JSON shape is similar. If it needs historical data, point it at PullPush or a data dump instead. The parsing and storage you already wrote almost always survives the swap untouched.

For a walkthrough of the same migration in video form, including the approval-gate reality and the workaround routes, this covers the ground well:

The one habit to build in during migration is defensive request handling: send the descriptive User-Agent every time, respect the rate-limit headers the API returns (the Reddit API wiki documents them), and back off on 429 instead of retrying immediately. If you would rather not write that logic at all, a managed layer includes it, and the authentication guide shows the header and token setup for the self-built path. The Reddit search API tutorial is a good template for porting a keyword-monitoring scraper specifically.

Which Option Should You Choose? A Decision Framework

The right route falls out of three questions: do you need live or historical data, how much volume do you need, and is your scarce resource money or engineering time. Live plus low volume plus patience for the approval gate points to your own OAuth app. Live plus real uptime needs plus limited engineering time points to a managed REST API. Historical points to PullPush, Arctic Shift, or data dumps depending on whether you want on-demand queries or offline completeness. Scraping is the answer only when a specific rendered page is the sole way to get what you need.

The framework above is deliberately opinionated because indecision is expensive when your pipeline is already broken. If you take one thing from it, take this: the anonymous .json path is not on the framework at all, because it is no longer a viable production route for automated collection. Every branch leads somewhere else. That is the real meaning of "the .json endpoint is dead" in 2026, not that the URL returns an error, but that no serious pipeline should be built on it anymore.

For a builder, the practical move is boring and correct. Inventory what you actually pull, split it into live and historical, and route each to the option that matches your constraints. Authenticate your live calls, keep a fallback for your historical source, and stop spending engineering time fighting a rate limiter that was designed to win. If you want the documented-API path without building the auth and backoff yourself, the Reddit Data API overview, the rate limits guide, and the pricing page are the fastest way in, and you can start with free credit at /signup. This remains a developer explainer and not legal advice, and redditapis.com is an independent third-party not affiliated with Reddit Inc.