Analytics API

Two kinds of numbers live here, and the difference matters.

The live routes call Instagram, TikTok or YouTube when you ask and answer about now. The collected routes read the history UseNadia stores itself, every 30 minutes, and answer about then — which is the only way to compare a video published yesterday with one published last month. The collected routes do not exist in the original project.

GET /analytics/{integration}               live account metrics
GET /analytics/post/{postId}               live metrics of one post
GET /video-list/{integrationId}            the catalogue, live from the provider
GET /analytics-history/{integrationId}     the collected account series
GET /video-history/{integrationId}         the collected per-video series

Live account metrics

GET /analytics/{integration}?date=30

Parameter	In	Required	Description
`integration`	path	Yes	The channel id
`date`	query	Yes	Days to look back: `7`, `30`, `90`…

Response 200, one series per metric. The labels depend on the platform (followers, reach, likes, views…):

[
  {
    "label": "Followers",
    "data": [
      { "date": "2026-10-19", "total": "1250" },
      { "date": "2026-10-20", "total": "1280" }
    ],
    "percentageChange": 2.4
  }
]

total comes back as a string, as the platforms return it. An empty array means the platform exposes no account metrics for that channel.

Live post metrics

GET /analytics/post/{postId}?date=30

Same parameters, for one published post. The answer has three shapes:

Answer	Meaning
`[ { label, data, percentageChange } ]`	The metrics, same shape as the account
`{ "missing": true }`	The post published but the platform returned no id (`releaseId` is `missing`): repair it with the release-id routes first
`[]`	The post is not published yet, or the platform has no per-post metrics

The catalogue

GET /video-list/{integrationId}

Query	Type	Description
`max_count`	number	How many videos
`cursor`	number	Provider cursor for the next page

Per-video performance — views, likes, comments, shares — read live from the provider, where /analytics/{integration} aggregates the whole account. The shape is the provider’s: TikTok and Instagram differ. 400 when the platform has no per-video list.

The collected history

Both history routes take the same query. Without from, the window is the last 30 days; without to, it ends now.

Query	Type	Description
`from`	ISO date	Start of the window
`to`	ISO date	End of the window
`limit`	integer ≥ 1	Page size
`offset`	integer ≥ 0	Walk past the server-side cap

A read is capped server-side at 5,000 rows. offset walks past the cap, and total says when to stop. The channel must be yours: 404 otherwise.

The account series

GET /analytics-history/{integrationId}

{
  "items": [
    { "integrationId": "cm4ean69r0003w8w1cdomox9n", "at": "2026-10-20T09:30:00.000Z", "metric": "followers", "value": 1280 }
  ],
  "total": 1284,
  "limit": 5000,
  "offset": 0,
  "from": "2026-09-20T09:30:00.000Z",
  "to": "2026-10-20T09:30:00.000Z"
}

One row per metric per collection pass, metric named as the provider names it.

The per-video series

GET /video-history/{integrationId}

Same query, plus one:

Query	Type	Description
`videoId`	`string`	Narrow to one video. Omit it to get every video’s series in a single call

The response carries two extra fields:

Field	Description
`videos`	The identity of the IDs in `items` — `videoId`, `title`, `cover`, `duration`. The series alone only knows opaque video IDs
`hidden`	How many videos were confirmed deleted on the provider and left out of `items`

Rows come newest video first, so the first page is always the videos that matter most.

Reading it correctly

The content board reads the same history to put numbers on its published cards.