---
title: "Get Regime History"
method: GET
path: "/api/v1/regimes/history"
tags: ["Regimes"]
---

# Get Regime History

`GET /api/v1/regimes/history`

## Request

- Base URL: `https://cryptodataapi.com`
- URL: `https://cryptodataapi.com/api/v1/regimes/history`
- Auth: API key in header `X-API-Key`

Committed long-horizon regime transitions over a window (Pro Plus).

``/regimes`` publishes only what is committed right now, so the sequence that
produced it could not be reconstructed from this API at all. Each entry here
is one committed run: which regime, the exact instant it committed, when the
next one replaced it, and how long it held.

**``committed_at`` is exact.** It comes from the ``in_regime_since`` stamped
at commit time and carried in every archived sample — not from the ~25-min
sample that first observed the change. And because every committed regime is
now protected by a minimum-dwell floor of at least 2h, no transition can hide
between two samples.

**Coverage starts 2026-08-07 and cannot be backfilled.** The published regime
is a stateful commit through the anti-churn dwell gate, not a pure function
of the archived signals — replaying older inputs would produce a sequence
that was never actually served. ``coverage_start`` reports the true start.

Not to be confused with ``/quant/regimes/history``, which is the short-horizon
6-state HMM's hourly probability Parquet. This is the 10-state cycle model.

## Query parameters

- `from` string: Window start, inclusive (ISO-8601 or unix ms). Defaults to 30 days ago.
- `to` string: Window end, EXCLUSIVE (ISO-8601 or unix ms). Defaults to now.
- `limit` integer: Max archive samples to scan (~57/day), not transitions returned.

## Response `200`

Successful Response

- RegimeHistoryResponse: `/api/v1/regimes/history` — the committed transition sequence.
  - `transitions` RegimeTransition[], required
    - `id` integer, nullable
    - `regime` string, nullable
    - `anchor` string, nullable
    - `name` string, nullable
    - `committed_at` string, required: ISO-8601 instant the regime COMMITTED, read from the snapshot's own in_regime_since — not the sample that first observed it, so this is exact rather than rounded to the archive cadence
    - `ended_at` string, nullable: commit instant of the NEXT regime; null while this one is current
    - `dwell_seconds` integer, nullable: Held duration; measured to now for the open final run
    - `rationale` string, nullable
    - `stage` string, nullable
    - `euphoria_score` integer, nullable
    - `first_observed_at` string, required: First archived sample carrying this run
    - `last_observed_at` string, required: Last archived sample carrying this run
    - `observations` integer, required: Archived samples covering this run
  - `count` integer, required
  - `from` string, required: Start of the requested window (inclusive)
  - `to` string, required: End of the requested window (exclusive)
  - `coverage_start` string, nullable: Earliest archived snapshot. Recording began 2026-08-07 and CANNOT be backfilled — the published regime is a stateful commit through the dwell gate, so replaying older signals would invent a sequence that was never served. A `from` earlier than this returns nothing for the uncovered part.
  - `sample_interval_seconds` integer, required: Archive cadence. Every committed regime is protected by a dwell floor of at least 2h, well above this, so no transition can fall between samples.
  - `truncated` boolean, required: True when `limit` clipped the window. Rows are read oldest-first, so the RECENT end is what is missing — narrow the window and re-request.

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/cryptodataapi/apis/crypto-data-api.md) · [All operations](https://skmtc.dev/cryptodataapi/apis/crypto-data-api/llms.txt) · [OpenAPI document](https://skmtc.dev/cryptodataapi/apis/crypto-data-api/revisions/8628b754ca81?raw)