Insights
Every username a channel has held, and which ones it gave up
/data-api/v2/insights/telegram/{username}/name-history- Scope
- insights:read
- Freshness
- catalog read
- Group
- Insights
- Platforms
- 1 of 7
What this endpoint answers
Telegram lets a channel change its public username and lets it hold several at once, and the two look identical in a flat list of aliases. This separates them. A name still seen in the newest crawl is an alias the channel holds; a name whose last sighting stopped while another kept moving is a name the channel dropped, which is a rename. A channel that has traded its name is a different asset from one that has not, and the response carries the measured base rate so a caller knows how unusual the answer is.
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
- first_seen is when the ENGINE first saw the name, never when the channel adopted it. observation.engine_watching_since is 2026-06-09 and a rename that happened before that date is invisible here. Treat a first_seen equal to that date as 'at least this old' rather than as an origin.
- latest_drop_observed_at is an upper bound, not a date. It is the last crawl that still saw a dropped name in use, so the change happened at or after it. The channel's crawl cadence sets how tight that bound is.
- status is held when a name was seen in the same crawl as the newest name (within one hour of it) and dropped otherwise. The crawler writes all of a channel's usernames in one pass, sub-second apart, so an hour separates the two cases without being sensitive to where the boundary sits.
- Holding several usernames at once is normal and is not a rename. renamed is true only when a name stopped being seen while another kept being seen.
- The base rate is what makes the answer readable. Measured over the 2,000 largest channels on 2026-08-31: 1,849 (92.5%) hold exactly one username, 151 (7.6%) hold more than one, and 81 (4.1%) no longer use the first name the engine recorded. It is re-measured by hand rather than live, because the catalog-wide version of that scan does not finish inside a request.
- This addresses a channel by its CURRENT username. Looking up a name a channel has already given up needs an index on lower(username) over tgdir_chat_usernames that does not exist yet: today that lookup is a sequential scan of 3.13M rows, measured at 9.9s.
- GET /identity/telegram/{username}/aliases returns the same rows as a flat array without the held / dropped split, and is the right call when all you want is the list.
Parameters
Every value the call accepts, with the example the spec ships so the request runs as written.
| Name | In | Required | Example | What it does |
|---|---|---|---|---|
username | path | required | toncoin | Public @username or a t.me link. The channel's CURRENT username. |
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 "https://crmsolid.com/data-api/v2/insights/telegram/toncoin/name-history" \
-H "Authorization: Bearer psk_live_..."
const res = await fetch("https://crmsolid.com/data-api/v2/insights/telegram/toncoin/name-history", {
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();
import os
import requests
res = requests.get(
"https://crmsolid.com/data-api/v2/insights/telegram/toncoin/name-history",
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.
- Username
- toncoin
- Chat id
- -1001233043722
- Title
- Gram of TON
- Type
- channel
- Status
- active
- Subscribers
- 6,863,255
- Current username
- toncoin
- Names recorded
- 2
- Names held
- 1
- Names dropped
- 1
- Renamed
- yes
- Latest drop observed at
- 8/1/2026, 12:03:16 AM
- Names
- 2 items
- Observation first seen
- 6/9/2026, 12:13:05 PM
- Observation last seen
- 8/31/2026, 12:09:24 PM
- Observation engine watching since
- 2026-06-09
- Base rate measured on
- 2026-08-31
- Base rate sample
- the 2,000 largest channels by subscribers
- Base rate sample size
- 2,000
- Base rate one name pct
- 92.5
- Base rate more than one name pct
- 7.6
- Base rate no longer original name pct
- 4.1
{
"data": {
"username": "toncoin",
"chat_id": "-1001233043722",
"title": "Gram of TON",
"type": "channel",
"status": "active",
"subscribers": 6863255,
"current_username": "toncoin",
"names_recorded": 2,
"names_held": 1,
"names_dropped": 1,
"renamed": true,
"latest_drop_observed_at": "2026-08-01T00:03:16.620Z",
"names": [
{
"username": "toncoin",
"is_current": true,
"status": "held",
"first_seen": "2026-06-09T12:13:05.037Z",
"last_seen": "2026-08-31T12:09:24.653Z",
"last_seen_days_ago": 0
},
{
"username": "gram",
"is_current": false,
"status": "dropped",
"first_seen": "2026-06-22T13:40:20.657Z",
"last_seen": "2026-08-01T00:03:16.620Z",
"last_seen_days_ago": 30
}
],
"observation": {
"first_seen": "2026-06-09T12:13:05.037Z",
"last_seen": "2026-08-31T12:09:24.653Z",
"engine_watching_since": "2026-06-09"
},
"base_rate": {
"measured_on": "2026-08-31",
"sample": "the 2,000 largest channels by subscribers",
"sample_size": 2000,
"one_name_pct": 92.5,
"more_than_one_name_pct": 7.6,
"no_longer_original_name_pct": 4.1
}
},
"meta": {
"request_id": "req_9f2c41a8b3d5",
"generated_at": "2026-08-23T09:14:02.317Z",
"took_ms": 42
}
}
The meta block
request_idstringrequiredUnique id for this request. Quote it in a support ticket.
generated_atstringrequiredServer time the response was produced.
took_msintegerrequiredMilliseconds spent server-side.
pagePageoptionalsourcestringoptionalWhich backend served the payload, for endpoints with more than one.
cache_age_sintegeroptionalAge of the underlying data in seconds. 0 for live reads.
When it fails
GET /insights/telegram/{username}/name-history documents 8 failure statuses. Branch on error.code, which is stable and enumerated; message is prose and may change.
- 401Unauthorized
unauthorized | invalid_keyNo key was presented, or the key is unknown, revoked or expired.
- 402PaymentRequired
payment_required | subscription_inactiveThe 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.
- 403Forbidden
forbidden_scope | forbidden_ipThe 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.
- 404NotFound
not_foundThe addressed resource does not exist.
- 422InvalidRequest
invalid_requestA parameter is malformed, out of range or mutually exclusive with another. `details` names the offending fields.
- 429RateLimited
rate_limited | quota_exceededEither 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.
- 500InternalError
internal_errorSomething failed on our side. Internals are never leaked; quote the request id.
- 503Unavailable
upstream_timeout | upstream_error | not_configuredThe 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.
| Tier | Requests a minute | Requests a day | Live reads a minute |
|---|---|---|---|
| free | 30 | 1,000 | 5 |
| standard | 120 | 25,000 | 20 |
| pro | 600 | 250,000 | 60 |
| unlimited | 6,000 | 10,000,000 | 600 |
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-name-history