---
title: "Get Streak Programme"
method: GET
path: "/api/v1/agents/streak/programme"
tags: ["experiments"]
---

# Get Streak Programme

`GET /api/v1/agents/streak/programme`

Is the streak ladder selecting anybody, and can we measure their streaks at all?

**This is the shadow gate, not the causal readout.** The treated-versus-control
comparison for any streak agent is ``GET /agents/{agent_id}/holdout``, which runs on
the shared holdout service: one grouped query, one maturity clause, one outcome for
both arms. Recomputing arms here would be a second implementation of the same split,
and any drift between the two would read as a real effect rather than as a bug. So
this answers only the two questions that are specific to this programme and that the
rollout is blocked on.

**Coverage.** ``customer_events`` is a FILTERED store: the extractor writes only events
classified core, minus the workspace's machine-event names, and only for workspaces
that opted into extraction. A server-emitted streak event can be excluded from it
entirely, so "the event is there" is a measurement rather than an assumption. The split
below is how many people the publisher could measure from events against how many fell
back to the person property, which is unreliable at the exact moment the loss ladder
fires.

**Volume.** Enrolment by moment, from the currently published state, plus how often
streaks actually break and get rebuilt in this workspace. The break figure is
descriptive and explicitly NOT causal: it counts everybody, messaged or not, and exists
to size the programme rather than to credit it.

## Query parameters

- `days` integer

## Headers

- `authorization` string, nullable — Bearer <token>

## Response `200`

Successful Response

- EnvelopeDict
  - `data` object, required
  - `meta` Meta
    - `request_id` string
    - `timestamp` string, date-time
    - `total` integer, nullable
    - `truncated` boolean, nullable
    - `reply_total` integer, nullable
    - `metric_total` integer, nullable
    - `people_total` integer, nullable

## Other responses

- `422` — Validation Error

## Changes

- **2026-09-05** `5691a8e12158` — 2 info
  - the `meta` response's property default value changed from `{"request_id":"","timestamp":"2026-09-04T03:53:05.348646"}` to `{"request_id":"","timestamp":"2026-09-05T02:09:45.736252"}` for the status `200`
  - the `timestamp` response's property default value changed from `2026-09-04T03:53:05.348646` to `2026-09-05T02:09:45.736252` for the status `200`
- **2026-09-04** `6be81c2b5273` — 5 info
  - added the optional property `meta/metric_total` to the response with the `200` status
  - added the optional property `meta/people_total` to the response with the `200` status
  - added the optional property `meta/reply_total` to the response with the `200` status
  - the `meta` response's property default value changed from `{"request_id":"","timestamp":"2026-09-03T19:42:04.697120"}` to `{"request_id":"","timestamp":"2026-09-04T03:53:05.348646"}` for the status `200`
  - …1 more
- **2026-09-03** `dd130eae1c32` — 2 info
  - the `meta` response's property default value changed from `{"request_id":"","timestamp":"2026-09-03T04:12:49.531787"}` to `{"request_id":"","timestamp":"2026-09-03T19:42:04.697120"}` for the status `200`
  - the `timestamp` response's property default value changed from `2026-09-03T04:12:49.531787` to `2026-09-03T19:42:04.697120` for the status `200`
- …earlier changes not shown

[Full history](https://skmtc.dev/minro/apis/minro-cs-platform/changes/api/v1/agents/streak/programme/get.md)

---

[API](https://skmtc.dev/minro/apis/minro-cs-platform.md) · [All operations](https://skmtc.dev/minro/apis/minro-cs-platform/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/minro/minro-cs-platform/revisions/5691a8e12158/schema)