I Pulled Nine Years of My Own Dev.to Data. The Numbers Were Not What I Expected

There is an API. It will tell you things about your writing that the dashboard will not. I have been publishing on Dev.to since April 2017. There is a four-year hole in the middle where I posted almost nothing, and then a return in March 2026 that has produced eighty-six posts in six months. That shape turns out to be useful. Two distinct bodies of work, on the same account, separated by a gap long enough that the platform itself changed underneath them. A natural experiment I did not set out to run. What I wanted was simple: a chart of follower growth with my article publication dates overlaid, to see whether particular posts moved the line. What I got instead was a fairly uncomfortable education in which of my numbers mean anything. The API made all of it possible, and almost nobody seems to use it.

Yes, There Is an API. Base URL is https://dev.to/api. You generate a key at Settings → Extensions → DEV Community API Keys. Most read endpoints for your own data want that key in an api-key header.

---

Trick One: The Default Page Size Is Not the Maximum

The followers endpoint is documented as returning 80 per page. I have a little over eighteen thousand followers, which is 227 round trips. The v1 pagination range actually runs to 1000. The 80 is a default, not a ceiling:

batch = client.get(
    f"{API_ROOT}/followers/users",
    params={"page": page, "per_page": 1000},
).json()

Nineteen requests instead of 227. Thirty-one seconds instead of however long 227 polite requests would have taken.

A Forem instance can cap per_page lower through an environment variable, so do not hardcode the assumption. Ask for the maximum, then learn the real stride from what comes back:

if page == 1 and len(batch) < requested:
    # Either the server capped us or that is the entire list.
    # Either way, this is the real page size.
page_size = len(batch)

Rate limiting is real and it is not gentle. Back off on 429, sleep between pages, and checkpoint your merged results to disk every few pages. A long first pull that dies on page 190 should not discard the previous 189.

---

Trick Two: Follower Dates Reconstruct History You Never Recorded

This is the single most useful thing in the API and it is easy to miss. /api/followers/users returns a created_at on every follower: the date that person started following you. You do not need to snapshot your follower count daily and wait six months to accumulate a time series. One pull reconstructs the entire curve retroactively, back to your first follower.

Catch: You only receive people who currently follow you. Anyone who followed and later unfollowed has vanished from the dataset. So the curve is "current followers by acquisition date," not your follower count as it stood on any given day. It increases monotonically by construction and can never show you a decline that actually happened. For working out which posts drove acquisition, fine. For anything about retention, it is actively misleading.

---

Trick Three: The Analytics Endpoints Exist and Are Barely Documented

There is a whole analytics family that most third-party tooling ignores:

• /api/analytics/totals - lifetime views, reactions, comments
• /api/analytics/historical - daily series over a date range
• /api/analytics/past_day - hourly, last 24 hours
• /api/analytics/referrers - where the traffic came from
• /api/analytics/follower_engagement - follower growth over time, plus top posts, bundled

All accept article_id to scope to a single post. Two important characteristics:

1. The responses nest. They are not flat integers. Example:

   {
     "page_views": {
       "total": 246454,
       "average_read_time_in_seconds": 306
     }
   }
   

2. Historical data degrades as you go back. For my 2017 posts the endpoint returns weekly buckets rather than daily rows, accounting for only about 15% of those posts' lifetime views. For 2019 it covers 95%. For 2026, 100%.

That matters more than it sounds. I computed a "half-life" for each post-days from publication until it had earned half its views to date. My first attempt confidently reported that several 2017 posts had half-lives around 3,000 days. They do not. The endpoint simply does not remember most of what those posts earned, and dividing a remembered fraction produces a precise, authoritative, meaningless number.

Coverage gate fix:

lifetime = article["page_views_count"]
tracked = sum(daily_series.values())

if lifetime and tracked < lifetime * 0.8:
    continue  # Skip this post-it's likely a false positive

Eighty-two of my 130 posts survive that gate. The median half-life among them is four days.

---

Trick Four: Some Metadata Is in the Markdown, Not the JSON

I write multi-part series. None of my posts came back with a collection_id, which is the field you would reach for to group them. The series are right there in the Dev.to UI. The article serializer just does not include the field.

But /api/articles/me/published returns body_markdown, front matter and all, and the series name is sitting in it:

FRONT_MATTER_SERIES = re.compile(r"^series:\s*(.+?)\s*$", re.M)

def series_name(article):
    body = article.get("body_markdown") or ""
    if not body.lstrip().startswith("---"):
        return None
    parts = body.split("---", 2)
    if len(parts) < 3:
        return None
    match = FRONT_MATTER_SERIES.search(parts[1])
    return match.group(1).strip().strip('"\'') if match else None

General lesson: When a field you expect is absent from the JSON, check whether the source document came back too. It often did.

---

Trick Five: Comments Arrive Pre-Threaded

/api/comments?a_id={id} returns comments as a tree, with each comment's replies nested in children. The structure is doing analytical work for free, and flattening it while preserving depth takes about eight lines:

from collections import deque

def flatten(nodes, depth=0):
    out = []
    for node in nodes or []:
        out.append({
            "depth": depth,
            "username": (node.get("user") or {}).get("username"),
            "created_at": node.get("created_at"),
            "text": strip_html(node.get("body_html")),
        })
        out.extend(flatten(node.get("children") or [], depth + 1))
    return out

Depth is the metric that matters. Comment count cannot distinguish eight people each saying "great article" from two people arguing with you for four rounds. Maximum thread depth can.

One of my posts has a thread 35 levels deep. That is not a comment section-it is a sustained argument, and no count-based metric would have told me it happened. There is no endpoint for creating comments, incidentally. Replying still requires the browser. Probably deliberate.

---

What the Data Actually Said

Here is where the exercise stopped being a programming problem.

• Follower count is not a readership number. I gained roughly 18,000 followers in 2026. My 2026 posts have 14,300 total views between them. You cannot acquire eighteen thousand followers from fourteen thousand views. The daily rate sits at a median of 136 with no meaningful response to whether I published anything, and about 37% of the usernames carry auto-generated-looking hex or numeric tails. That is reciprocal-follow farming, it is endemic, and it has nothing to do with me.

• My most-viewed work is nine years old and no longer being read. My 2017 output was MicroPython, NodeMCU, and MongoDB tutorials. Forty-four posts from 2017 to 2019 pulled 32,474 views. Eighty-six posts in 2026 have pulled 14,300.

• The daily series tells the other half. My 5,472-view NodeMCU post has had zero views in the last ninety days. Nineteen of my 130 posts are at zero for the quarter. Lifetime counters never decrease, which makes an archive look alive long after it has stopped breathing.

• Engagement numbers invert completely. Those big old tutorials run about 2 reactions per thousand views. My 2026 essays run 56 to 72, with one at 71.6 reactions and 63.8 comments per thousand. Across the eras: 44 old posts drew 26 comments total. 86 new posts have drawn 606.

So one body of work got found and skimmed. The other gets read and argued with. They are different products, and I had been evaluating both with the same number.

Traffic breakdown:

Source	Percentage
Google (direct or unknown)	4%
Direct / Unknown	74.5%
Internal Dev.to	19%

For someone whose best-performing historical content is evergreen reference material, that is the number I find hardest to look at.

---

What I Would Tell Someone Starting This Pull

1. Pull the followers once and cache them, because the dates reconstruct years of history you never thought to record.
2. Gate every analytics computation on data coverage, because a partial series will hand you a confident wrong answer rather than an error.
3. Read thread depth instead of comment count. The former captures sustained engagement; the latter conflates volume with quality.
4. Check body_markdown before concluding a field does not exist. Many fields present themselves only in the serialized HTML, not in the JSON payload.

Mostly, though: separate the metrics that measure distribution from the metrics that measure whether anyone cared. Views, follower counts, and impressions are the first kind. Comment depth, reply rates, and the fact that the same four people keep showing up in your threads are the second. I spent nine years assuming the first kind was the scoreboard. The API took an evening to tell me otherwise.