---
title: "Api V2 Flow Hedging Sessions Get"
method: GET
path: "/api/v2/flow/hedging/sessions"
tags: ["Options Flow (v2)"]
---

# Api V2 Flow Hedging Sessions Get

`GET /api/v2/flow/hedging/sessions`

## Request

- Base URL: `https://api.zerogex.io` (the document declares no server; this is the origin it was published from)
- URL: `https://api.zerogex.io/api/v2/flow/hedging/sessions`
- Auth: HTTP bearer

Trading days that have a stored Hedging Flow session, newest first.

The index behind ``/api/flow/hedging?date=``. Deliberately a list of days
that HAVE data rather than a date picker over the calendar: a picker
invites a reader onto an empty session and lets them conclude the feature
is broken, which is why ``/api/replay/sessions`` and the scorecard's
equivalent are both shaped this way.

Read from ``hedging_flow_5min`` and nothing else. Listing from the live
tables instead would advertise exactly the days the prune window keeps
and hide every older session that is still perfectly readable -- the list
and the permalinks have to agree about which days exist.

Each entry carries enough to render a card rather than a date: how many
bars the day has, how many of those were real rather than carried
forward, whether a 0DTE scope exists for it, and where the session's
cumulative lean finished.

``has_more`` comes from asking the database for one row more than the
caller wanted and then dropping it. That extra row is what lets the answer
be certain instead of inferred: a caller comparing ``count`` to ``limit``
is wrong exactly when the total is a multiple of the page size, and it
offers the reader a next page that renders as an empty archive.

## Query parameters

- `symbol` string, required
- `limit` integer
- `before` string, nullable: Page backwards: an ET trading day, YYYY-MM-DD, returning only sessions strictly OLDER than it. Pass the previous response's `next_before`; omit for the newest page. This is the one session list that needs paging at all -- hedging_flow_5min is retention-exempt, so it grows by a session a day without end, and a caller that never pages eventually stops seeing the oldest sessions even though their permalinks still work.

## Response `200`

Successful Response

- EnvelopeHedgingFlowSessionList
  - `data` HedgingFlowSessionList, required: The index behind the dated Hedging Flow permalinks, newest first. Paged, unlike the other session lists. Those read tables ``db-prune`` empties at DATA_RETENTION_DAYS, so one page holds everything they will ever hold; ``hedging_flow_5min`` is retention-exempt and gains a session every trading day, so this list outgrows any fixed page. ``has_more`` is authoritative: it is answered from a row the server fetched and discarded, not inferred from ``count``. Feed ``next_before`` back as ``before`` to walk backwards; it is null on the last page.
    - `symbol` string, required
    - `count` integer, required
    - `sessions` HedgingFlowSession[], required
      - `date` string, date, required
      - `bar_count` integer, required
      - `real_bar_count` integer, required
      - `had_0dte` boolean, required
      - `cum_net_usd` number, nullable
      - `first_bar` string, date-time, nullable
      - `last_bar` string, date-time, nullable
    - `has_more` boolean
    - `next_before` string, nullable
  - `freshness` Freshness, required: The v2 freshness envelope. Present on every ``/api/v2/*`` response.
    - `evaluated_at` string, date-time, required: When the API evaluated this response (server wall clock, UTC). Endpoint-health signal: advances on every request even when the underlying data is unchanged.
    - `generated_at` string, date-time, required: When the served data was computed. Equals the snapshot stamp for cycle-backed endpoints, or evaluated_at for endpoints computed on demand for this request.
    - `source_timestamp` string, date-time, nullable: Timestamp of the upstream market observation the payload derives from. This is what freshness_status is measured against. Null when the endpoint has no upstream feed or returned no rows.
    - `latest_event_at` string, date-time, nullable: Newest event timestamp present in the payload (last bar, last trade, last scored row). Best-effort on very large responses, which are sampled rather than fully walked.
    - `age_seconds` number, nullable: evaluated_at - source_timestamp, in seconds. Null when source_timestamp is null.
    - `market_session_status` string, required: pre-market | regular | after-hours | closed (US/Eastern).
    - `expected_update_cadence` string, nullable: ISO-8601 duration for how often this endpoint's data is expected to change right now, e.g. PT60S. Null means no updates are expected (weekend, holiday, or a feed that only runs during the session).
    - `expected_update_cadence_seconds` number, nullable: expected_update_cadence as a number of seconds.
    - `cadence_profile` string, required: Identifier of the cadence class this endpoint belongs to, e.g. analytics_cycle. Stable across releases; the seconds behind it may be retuned.
    - `stale_after` string, date-time, nullable: Instant after which this payload should be treated as stale. Null whenever expected_update_cadence is null.
    - `freshness_status` 'fresh' | 'aging' | 'stale' | 'session_closed' | 'static' | 'unknown', required: The rolled-up freshness verdict for one response. ``fresh`` ``source_timestamp`` is within one expected update cadence. ``aging`` Past one cadence but not yet past ``stale_after`` — the grace band that absorbs normal cycle jitter. Not an error; a client that polls faster than the cadence sees this routinely. ``stale`` Past ``stale_after`` while updates *were* expected. This is the actionable state: the feed behind this endpoint is late. ``session_closed`` A feed-backed endpoint whose feed is not due to produce anything right now (weekend, holiday, or a feed that only runs during the session). The payload is the last good value — deliberately NOT reported as ``stale``, because an overnight consumer polling a closed market is not observing a fault and should not page on it. ``static`` The endpoint is not feed-backed at all: completed history, or a result computed from the caller's own inputs. Age here carries no health meaning and never becomes a fault. ``unknown`` No source timestamp could be resolved from the payload (e.g. a pure calculator, an admin endpoint, or an empty result set). A consumer should fall back to ``evaluated_at`` for endpoint health and make no claim about data age.

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/zerogex/apis/zerogex-api.md) · [All operations](https://skmtc.dev/zerogex/apis/zerogex-api/llms.txt) · [OpenAPI document](https://skmtc.dev/zerogex/apis/zerogex-api/revisions/753b26bf0592?raw)
