Insights

How a channel's per-post reach has moved, day by day

GET/data-api/v2/insights/telegram/{username}/activity
Scope
insights:read
Freshness
catalog read
Group
Insights
Platforms
1 of 7

What this endpoint answers

The daily history of a channel's average post views. Subscriber counts and attention move independently on Telegram, and a channel whose participant count climbs while its view average falls is the single clearest sign that a subscriber list was bought. This is the series behind that comparison.

This is a catalog read: it is served from the CRM Solid database in milliseconds, costs one budget unit, and reports how old the reading is in meta.cache_age_s. It needs the insights:read scope (Insights): Engagement rates, top posts, viral patterns, cohort benchmarks.

Good to know

  • avg_views is a level rather than a running total, so it is never differenced into a per-day rate: per_day and best_day are always null here, and peak and trough are returned instead.
  • It is the mean of the posts visible on the channel's public preview at crawl time, roughly the last twenty. How fast it responds therefore depends on how often the channel posts: a channel posting five times a day turns that window over in four days, one posting weekly takes months, so a flat line on a quiet channel is not evidence that nothing changed.
  • Present on about 84 percent of Telegram daily rows. It is absent for groups, for channels with no public preview and for channels whose visible posts carry no view counter, and those days are left out of the series rather than read as zero.
  • For the ratio of views to subscribers, and its percentile against channels of the same size, use GET /insights/telegram/{username}/reach. This endpoint is the time axis that one does not have.
  • change is measured against the previous OBSERVED day, and days_covered says how many calendar days that step spans. A crawl gap therefore never disappears into a single day's number: use per_day, or days_covered, rather than reading change as a daily rate.
  • A day with no value is left out rather than carried forward. A missing day is a day nobody looked, not a day nothing happened.
  • window.days_observed is the real denominator and it varies a lot by account. Read it before trusting a per-day figure: history begins 2026-06-09 and the deepest account in any of these catalogs held 80 days on 2026-08-30.
  • audience.precision says whether the follower or subscriber number on this platform can be trusted digit for digit. GET /insights/activity/platforms carries the full explanation for each.
  • Only accounts already in the catalog have a series. An account nobody has asked us about has never been rolled up.

Parameters

Every value the call accepts, with the example the spec ships so the request runs as written.

NameInRequiredExampleWhat it does
usernamepathrequireddurovPublic Telegram username, with or without the @. A t.me link is accepted.
daysqueryoptional30Calendar days of history to read back from today, 1 to 90. The rollup begins 2026-06-09, so no account can answer for more than that.

Call it

Authenticate with a bearer token or the x-api-key header. Keys are server-to-server credentials. Never embed one in front-end code - call the API from your own backend and forward the result.

curl
curl "https://crmsolid.com/data-api/v2/insights/telegram/durov/activity" \
  -H "Authorization: Bearer psk_live_..."
JavaScript
const res = await fetch("https://crmsolid.com/data-api/v2/insights/telegram/durov/activity", {
  headers: {
    Authorization: `Bearer ${process.env.CRM_SOLID_DATA_API_KEY}`,
  },
});

if (!res.ok) {
  const { error } = await res.json();
  throw new Error(`${error.code}: ${error.message} (${error.request_id})`);
}

const { data, meta } = await res.json();
Python
import os

import requests

res = requests.get(
    "https://crmsolid.com/data-api/v2/insights/telegram/durov/activity",
    headers={"Authorization": f"Bearer {os.environ['CRM_SOLID_DATA_API_KEY']}"},
    timeout=30,
)
res.raise_for_status()

payload = res.json()
data, meta = payload["data"], payload["meta"]

Keys look like psk_live_... for production keys, psk_test_... for test keys and are minted in the panel.

What comes back

Success is { data, meta }. Failure is { error: { code, message, request_id } }. The body below is the spec's own example: the values in it are illustrative readings, not live numbers.

Platform
telegram
Id
-1001488156064
Handle
bloomberg
Name
Bloomberg
Audience metric
participants
Audience latest
171,943
Audience precision
exact
Metric key
reach
Metric label
Mean views of the recent posts
Metric kind
recent_average
Metric measures
The mean view count of the posts visible on the channel's public preview when it was crawled, roughly the last twenty. …
Metric precision
exact
Window requested days
30
Window from
2026-08-03
Window to
2026-08-30
Window days observed
20
Window days spanned
28
Window coverage pct
71.4
Window longest gap days
7
Summary first day
2026-08-03
Summary first value
69,130
Summary latest day
2026-08-30
Summary latest value
71,560
Summary change
2,430
Summary change pct
3.51
Summary peak day
2026-08-30
Summary peak value
71,560
Summary trough day
2026-08-03
200 GET /insights/telegram/{username}/activity
{
  "data": {
    "platform": "telegram",
    "id": "-1001488156064",
    "handle": "bloomberg",
    "name": "Bloomberg",
    "audience": {
      "metric": "participants",
      "latest": 171943,
      "precision": "exact"
    },
    "metric": {
      "key": "reach",
      "label": "Mean views of the recent posts",
      "kind": "recent_average",
      "measures": "The mean view count of the posts visible on the channel's public preview when it was crawled, roughly the last twenty. It is a level, not a total, so it is never differenced into a per-day rate.",
      "precision": "exact"
    },
    "window": {
      "requested_days": 30,
      "from": "2026-08-03",
      "to": "2026-08-30",
      "days_observed": 20,
      "days_spanned": 28,
      "coverage_pct": 71.4,
      "longest_gap_days": 7
    },
    "summary": {
      "first": {
        "day": "2026-08-03",
        "value": 69130
      },
      "latest": {
        "day": "2026-08-30",
        "value": 71560
      },
      "change": 2430,
      "change_pct": 3.51,
      "per_day": null,
      "best_day": null,
      "peak": {
        "day": "2026-08-30",
        "value": 71560
      },
      "trough": {
        "day": "2026-08-03",
        "value": 69130
      },
      "per_day_per_1k_audience": null
    },
    "series": [
      {
        "day": "2026-08-29",
        "value": 71300,
        "change": 260,
        "days_covered": 1,
        "per_day": null
      },
      {
        "day": "2026-08-30",
        "value": 71560,
        "change": 260,
        "days_covered": 1,
        "per_day": null
      }
    ]
  },
  "meta": {
    "request_id": "req_9f2c41a8b3d5",
    "generated_at": "2026-08-23T09:14:02.317Z",
    "took_ms": 42
  }
}

The meta block

  • request_idstringrequired

    Unique id for this request. Quote it in a support ticket.

  • generated_atstringrequired

    Server time the response was produced.

  • took_msintegerrequired

    Milliseconds spent server-side.

  • pagePageoptional
  • sourcestringoptional

    Which backend served the payload, for endpoints with more than one.

  • cache_age_sintegeroptional

    Age of the underlying data in seconds. 0 for live reads.

When it fails

GET /insights/telegram/{username}/activity documents 8 failure statuses. Branch on error.code, which is stable and enumerated; message is prose and may change.

  • 401Unauthorizedunauthorized | invalid_key

    No key was presented, or the key is unknown, revoked or expired.

  • 402PaymentRequiredpayment_required | subscription_inactive

    The key is valid but the plan behind it cannot serve the call: the included requests are spent and overage is switched off, capped or unfunded (payment_required), or the billing period lapsed and was not renewed (subscription_inactive). Retrying does not help; paying does. The X-Plan-* headers on this response say how far past the line you are.

    Carries X-Plan, X-Plan-Limit, X-Plan-Overage, X-Plan-Period-End, X-Plan-Remaining.

  • 403Forbiddenforbidden_scope | forbidden_ip

    The key is valid but not allowed to make this call: it lacks the scope, or the request came from an address outside the key's allowlist.

  • 404NotFoundnot_found

    The addressed resource does not exist.

  • 422InvalidRequestinvalid_request

    A parameter is malformed, out of range or mutually exclusive with another. `details` names the offending fields.

  • 429RateLimitedrate_limited | quota_exceeded

    Either the burst ceiling for the current minute or the daily quota is spent. Distinguish with the code: rate_limited clears within the minute, quota_exceeded does not clear until 00:00 UTC.

    Carries Retry-After, X-Quota-Limit, X-Quota-Remaining, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-Request-Id.

  • 500InternalErrorinternal_error

    Something failed on our side. Internals are never leaked; quote the request id.

  • 503Unavailableupstream_timeout | upstream_error | not_configured

    The request could not be served right now. BRANCH ON error.code, not on the status: 'upstream_timeout' means a source was too slow (this is what a catalog query hitting its 15-second statement timeout returns, so it is reachable from any endpoint that reads the corpus, not only the live-scrape ones) and the same call is worth retrying with backoff - narrowing it with a smaller limit, a filtered scope or a less popular account makes it far less likely; 'upstream_error' means a source was unreachable, so back off further; 'not_configured' means the capability has no backing service in this deployment, and retrying will never help.

Every response carries X-Request-Id and meta.request_id. Quote it in support requests.

Coverage and limits

This endpoint covers Telegram. Rate limits come from the tier on your key.

Telegram
TierRequests a minuteRequests a dayLive reads a minute
free301,0005
standard12025,00020
pro600250,00060
unlimited6,00010,000,000600

This call only draws on the ordinary per-minute and per-day columns. Every response reports where you stand in X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset and the X-Plan headers.

Start calling it

A key takes a minute to mint in the panel, no card. The reference covers authentication, the envelope, scopes, rate limits and every error code in one page.

Reference path: /data-api/reference/insights-telegram-activity

We value your privacy

We use cookies to improve our site, analyze traffic, and personalize ads. You can accept all, reject non-essential, or customize your choices. Read our Cookie Policy.