One finding with its full test history

A single finding plus the per-pass record behind it: every time the hypothesis was tested, what the effect measured, its p-value, both q-values, the account split-half result, whether it passed, and which rule stopped it when it did not. This is the evidence trail that makes a published claim checkable rather than assertable.

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 research:read scope (Research): Findings, runs and events from the autonomous research engine.

curl "https://crmsolid.com/data-api/v2/research/findings/media%257Cyes%257C*%257C*%257Cengagement%257Ceffect" \
  -H "Authorization: Bearer psk_live_..."

const res = await fetch("https://crmsolid.com/data-api/v2/research/findings/media%257Cyes%257C*%257C*%257Cengagement%257Ceffect", {
  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/research/findings/media%257Cyes%257C*%257C*%257Cengagement%257Ceffect",
    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.

Finding hypothesis id

media|yes|*|*|engagement|effect

Finding status

promoted

Finding effect lift pct

53

Finding effect lift lo pct

45

Finding effect lift hi pct

61

Finding evidence accounts sampled

1,862

Finding evidence q value

0

Finding evidence half concordant

yes

Tests

1 items

Gate alpha

0.05

Gate min accounts

50

Gate min lift pct

10

Gate min consecutive runs

3

{
  "data": {
    "finding": {
      "hypothesis_id": "media|yes|*|*|engagement|effect",
      "status": "promoted",
      "effect": {
        "lift_pct": 53,
        "lift_lo_pct": 45,
        "lift_hi_pct": 61
      },
      "evidence": {
        "accounts_sampled": 1862,
        "q_value": 1.2e-56,
        "half_concordant": true
      }
    },
    "tests": [
      {
        "run_id": 6,
        "run_started_at": "2026-08-19T02:00:00.000Z",
        "family": "engagement:core",
        "lift_pct": 53,
        "p_value": 4.6e-59,
        "q_value": 1.2e-56,
        "q_pooled": 3.9e-56,
        "split_half": {
          "lo_pct": 48.2,
          "hi_pct": 57.9,
          "p_max": 1.1e-21,
          "concordant": true
        },
        "passed": true,
        "fail_reason": null
      }
    ],
    "gate": {
      "alpha": 0.05,
      "min_accounts": 50,
      "min_lift_pct": 10,
      "min_consecutive_runs": 3
    }
  },
  "meta": {
    "request_id": "req_9f2c41a8b3d5",
    "generated_at": "2026-08-23T09:14:02.317Z",
    "took_ms": 42
  }
}

• 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.

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.

• GET/research/findingsFindings the research engine is willing to state
• GET/research/runsResearch pass history
• GET/research/eventsThe research changelog

Reference path: /data-api/reference/research-findings-get