How to collect Mastodon post stats from your account archive and the API

What you need before you start

Mastodon post stats can be collected two ways here: from the account archive for historical post data, and from the API for current or ongoing access. Keep the scope tight, only use the account’s own data, and do not assume an export or endpoint gives you more than it actually shows.

If you want an agent to read account data under your own permissions, use the MCP setup. If you want authenticated REST requests and the exact request patterns TimeToPost documents, use the API guide.

Pull post data from your Mastodon account archive

Start by locating the account archive export in Mastodon’s export or data download area. The exact file name and contents depend on the instance and export type, which is the annoying bit that makes “one neat universal parser” a fantasy.

For post stats, look for rows or records that identify each post, usually with a stable post identifier, the post text, and a creation or publish timestamp. If the export includes engagement totals, keep those too, such as counts that can help you summarize activity later. Because archive contents vary by export type and instance, do not expect every archive to include the same fields or the same level of detail.

A practical way to work is to scan the archive for the fields that let you answer three questions, which post is this, when was it published, and what engagement data came with it. That is enough to build a usable sheet even if the export is not especially generous.

Read the same account’s post records through the Mastodon API

For current or ongoing access, read the authenticated account’s posts through the API path for that account’s posts. With TimeToPost, the REST API is scoped to your active organization and requests are made over HTTPS with a Bearer token, so keep the request tied to the authenticated owner’s own data and do not wander off into other people’s posts like a raccoon in a snack drawer. The docs say, verbatim, that the API is “scoped to your active organization” and that a token “acts with your full account permissions.”

From the response, capture the same basics you would want from the archive, especially a stable post identifier, the content, the status, and the timestamps you need to line up records. TimeToPost’s GET /api/posts response includes id, content, platforms, status, scheduledAt, publishedAt, and mediaUrls for posts in the active organization. If you are using an agent, the MCP server also exposes post and analytics tools under your account permissions, which keeps the scope on the rails.

Worked example: compare archive rows to API post records

Here is a hypothetical example, because pretending we have your real archive would be a bit rude.

Archive row:

• post_id: mastodon-1842
• text: Coffee first, then the thread
• created_at: 2026-03-14T09:20:00Z
• boosts: 12
• favorites: 34

API record:

• id: mastodon-1842
• content: Coffee first, then the thread
• publishedAt: 2026-03-14T09:20:00Z
• status: published

To verify they are the same post, compare three things, in this order.

1. Stable post identifier, the post_id in the archive matches id in the API record.
2. Post text, the archive text matches content.
3. Creation or publish time, the archive timestamp matches publishedAt or the equivalent timestamp in the export.

If all three line up, you have a solid match. If one field drifts, especially text, treat it as a different record until you can explain the mismatch.

Build a simple stats sheet from the two sources

Keep one spreadsheet or CSV with columns that can hold both archive data and API data without getting fancy about it. A simple set is enough:

• post_id
• published_time
• text
• status
• engagement_boosts or reposts, if present
• engagement_favorites or likes, if present
• other engagement fields present in the archive or API response
• source, such as archive or API

That layout makes it easier to merge the archive snapshot with ongoing API pulls. It also keeps the historical rows separate from fresh records, which matters when you want one export that you can keep using after you switch schedulers. If you already know you will move content into TimeToPost later, this is the moment to keep the history tidy instead of letting it become spreadsheet soup.

When the API is better than the archive

Use the archive when you want a one-time collection of past posts. Use the API when you want repeat pulls, fresher stats, or a feed you can refresh on a schedule.

That choice is pretty simple, really. Snapshot work belongs to the archive. Ongoing monitoring belongs to the API. If you only need one clean export before you leave your current scheduler, the archive is fine. If you expect to keep checking new posts and updated stats, the API is the less annoying route.

What to do with the export before you cancel

Before you cancel, save the collected Mastodon post stats alongside the post history and media references you may still need later. That way, when the scheduler account is gone, you are not trying to reconstruct your posting past from memory and vibes.

This fits the migration checklist mindset: keep the post IDs, timestamps, text, engagement totals, and media references together before you move on. If you are already preparing the next system, store the export in a format you can reuse, then carry it forward with the rest of your history.