Analytics

The API exposes a single analytics endpoint: a rollup of what the workspace actually published over a trailing window. Per-post metrics (impressions, likes, saves) are not part of the public API — they live in the dashboard analytics screen.

Workspace overview

GET /api/v1/analytics/overview

Query parameters:

Name	Type	Notes
days	integer	Size of the trailing window. 1 to 365, default 30. Values above 365 are clamped to 365; anything non-numeric or ≤ 0 falls back to 30.

curl "https://app.nativpost.com/api/v1/analytics/overview?days=7" \
  -H "Authorization: Bearer $NATIVPOST_API_KEY"

Response:

{
  "window": {
    "days": 7,
    "since": "2026-07-12T12:00:00Z"
  },
  "published": 24,
  "per_platform": {
    "instagram": 12,
    "tiktok": 8,
    "twitter": 4
  }
}

Fields:

• window.days — the window actually applied after clamping.
• window.since — the start of the window, computed as now minus days.
• published — total number of successful platform publishes in the window. A single content item fanned out to three platforms counts as three.
• per_platform — the same total, keyed by platform id. Platforms with no publishes in the window are omitted rather than reported as 0.

What counts as published

The numbers come from the publishing queue, not from the content table. A row counts when its status is published and it has a published_at inside the window. Content that is still scheduled, or that failed on every platform, does not appear.

Because the unit is a queue row (one per platform per item), published is a count of deliveries, not of content objects.

Counting content objects instead

If you want a count of content items rather than deliveries, list the content directly and page through it:

curl "https://app.nativpost.com/api/v1/content?status=published&limit=100" \
  -H "Authorization: Bearer $NATIVPOST_API_KEY"

See Pagination for walking the full set.

Plan limits

GET /api/v1/me reports features.analytics_history_days for the workspace’s plan. The overview endpoint itself does not truncate the window to that value — it only clamps to 365 — so check the plan field yourself if you need to respect it.

Freshness

published and per_platform are computed from the queue at request time, so a post that went out a minute ago is already counted. There is no background refresh delay and no need to poll on a fixed cadence.