Insights

What an account gains on the days it posts against the days it does not

GET/data-api/v2/insights/bluesky/{handle}/posting-impact
Scope
insights:read
Freshness
catalog read
Group
Insights
Platforms
1 of 7

What this endpoint answers

The Bluesky rollup records an account's follower count and its post count on the same row of the same day, so every day in the window can be labelled as one the account published on or one it stayed quiet on, and the follower gain on each group compared. Bluesky publishes no per-post view or like count, so nothing here says how a post performed. What it does say is whether publishing moves this account's follower number at all, measured against the account itself rather than against a cohort.

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

  • Only steps between two CONSECUTIVE observed days are used. A step spanning a crawl gap cannot be attributed to a posting day or a silent one, so it is excluded and counted in steps_skipped_over_gaps rather than folded into either group.
  • This is association, not causation, and the sample is one account over at most 90 days. A high median_ratio says the account's follower number moved more on its publishing days across this window; it does not establish that the posts caused it, and a single news cycle can produce the same reading.
  • An empty group carries nulls, never zeros. An account that published every day in the window has silent_days: 0 and every silent-day statistic null, because not measured and no gain are different claims.
  • A day where the post count went DOWN is a day of deletions. It belongs in neither group and is reported on its own as deleting_days.
  • posts_published is the sum of the daily increases, so a day that both published and deleted is under-counted. It is the net movement of the account's own post counter, which is the only thing the engine records.
  • Bluesky follower counts are exact to the digit. On the freshest day 89.9% of 36,975 values were not multiples of ten, which is what chance gives for unrounded integers, so these gains are measurements rather than rounding steps.
  • Measured support for the split, on production 2026-08-31 over the 300 largest accounts and their 8,991 consecutive-day steps in a 30 day window: 5,156 steps published at least one post, 3,815 published none, 20 went backwards on a deletion, and 245 of the 300 accounts had at least one silent day.
  • Bluesky handles are rented and can move between accounts. The largest matching account wins the lookup, matching GET /directory/bluesky/{id}. Pass a did:plc: identifier to address one account for certain.
  • measurable is false with reason insufficient_history under six usable steps. 35,279 of the 134,530 accounts that have any series at all had 30 or more observed days on 2026-08-30, and 4,992 of the top 5,000 by followers did.

Parameters

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

NameInRequiredExampleWhat it does
handlepathrequiredjamesgunn.bsky.socialBluesky handle such as nytimes.com, or a did:plc: identifier.
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/bluesky/jamesgunn.bsky.social/posting-impact" \
  -H "Authorization: Bearer psk_live_..."
JavaScript
const res = await fetch("https://crmsolid.com/data-api/v2/insights/bluesky/jamesgunn.bsky.social/posting-impact", {
  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/bluesky/jamesgunn.bsky.social/posting-impact",
    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.

Did
did:plc:lotavzt36yanhfy3j3gpysyj
Handle
jamesgunn.bsky.social
Display name
James Gunn
Status
active
Followers
352,753
Follows
77
Posts
1,195
Account created at
4/23/2023, 7:37:16 PM
Account age days
1,226
Window requested days
30
Window from
2026-08-01
Window to
2026-08-31
Window days observed
31
Window days spanned
31
Window coverage pct
100
Window longest gap days
0
Measurable
yes
Cadence steps used
30
Cadence steps skipped over gaps
0
Cadence posting days
11
Cadence silent days
19
Cadence deleting days
0
Cadence active day pct
36.7
Cadence posts published
15
Cadence posts per active day
1.36
Cadence longest silence days
4
Follower gain on posting days days
11
Follower gain on posting days median
58
200 GET /insights/bluesky/{handle}/posting-impact
{
  "data": {
    "did": "did:plc:lotavzt36yanhfy3j3gpysyj",
    "handle": "jamesgunn.bsky.social",
    "display_name": "James Gunn",
    "status": "active",
    "followers": 352753,
    "follows": 77,
    "posts": 1195,
    "account_created_at": "2023-04-23T19:37:16.346Z",
    "account_age_days": 1226,
    "window": {
      "requested_days": 30,
      "from": "2026-08-01",
      "to": "2026-08-31",
      "days_observed": 31,
      "days_spanned": 31,
      "coverage_pct": 100,
      "longest_gap_days": 0
    },
    "measurable": true,
    "reason": null,
    "cadence": {
      "steps_used": 30,
      "steps_skipped_over_gaps": 0,
      "posting_days": 11,
      "silent_days": 19,
      "deleting_days": 0,
      "active_day_pct": 36.7,
      "posts_published": 15,
      "posts_per_active_day": 1.36,
      "longest_silence_days": 4
    },
    "follower_gain": {
      "on_posting_days": {
        "days": 11,
        "median": 58,
        "mean": 59.8,
        "total": 658,
        "best": {
          "day": "2026-08-12",
          "change": 105
        },
        "worst": {
          "day": "2026-08-17",
          "change": 30
        }
      },
      "on_silent_days": {
        "days": 19,
        "median": 39,
        "mean": 39.8,
        "total": 756,
        "best": {
          "day": "2026-08-09",
          "change": 74
        },
        "worst": {
          "day": "2026-08-11",
          "change": 20
        }
      },
      "median_difference": 19,
      "median_ratio": 1.487
    }
  },
  "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/bluesky/{handle}/posting-impact 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 Bluesky. Rate limits come from the tier on your key.

Bluesky
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-bluesky-posting-impact

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.