Pump settings history
get_settings_historyRetrieve chronological pump settings (basal schedules, targets, ISF, carb ratios) to identify which were active at any time or track changes over a period.
Instructions
Every pump setting change that was in effect during the window, in chronological order: DIA, max basal rate, the programmed basal-rate schedule, and the time-segmented target, ISF and carb-ratio profiles.
THIS IS THE ANSWER for "what's my basal rate" — basalRateSchedule is the PROGRAMMED baseline (what the pump would run in manual mode), archived per settings snapshot. On a closed-loop account (CamAPS FX, Control-IQ, etc.) the algorithm overrides this continuously, so compare it against get_daily_insulin's actual delivered basal rather than expecting them to match, the gap between scheduledDailyBasalUnits and the real delivered total is itself a meaningful figure (how hard the algorithm is working relative to the programmed baseline).
Use it to establish which settings were active at a given time (essential before judging a bolus or an excursion), or to see how settings have been adjusted over a long span.
Glucose-based values (target, ISF) are in the configured unit. Basal-rate values are in units/hour, never unit-converted (not a glucose value). Effective timestamps are plain wall clock time (device-local), not UTC; the per-segment "from" times are pump-schedule clock-hours.
Returns: a settings array, each entry with its effective timestamp, DIA_hours, maxBasalRate (or null, some accounts never populate this key even though they do populate activeBasalProgram, they are independent, not a fallback pair), activeBasalProgram (the name of the currently active basal program/profile, or null if unavailable), basalRateSchedule (a list of {from, unitsPerHour} time segments, or null if this device/account has never shown it), scheduledDailyBasalUnits (or null), the targetBg, isf and carbRatio profiles (each a list of {from, value} time segments; a targetBg segment may also carry valueLow/valueHigh alongside value when the device reports a range rather than a single point — present only when the source data actually has them, no assumed relationship between value and the low/high pair), bgCorrectionThreshold (same shape, or null if this device/account has never shown it) — a separate correction-trigger level distinct from the ordinary target range, where the device populates it — plus bgGoal ({low, high}, a single overall goal range distinct from the time-segmented targetBg profile) and cgmAlerts ({lowGlucose, highGlucose, fallRate, riseRate}, each {enabled, limit}, or the whole object null if unavailable) — the DEVICE'S OWN configured alarm thresholds, a different concept from this extension's own configured low/high boundaries used for time-in-range. HONESTY CAVEAT: fallRate/riseRate read like rate-of-change alerts, not plain glucose levels — not independently confirmed against a real value sample, treat as a best-effort reading of Glooko's field naming.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | Required. Window end as an ISO 8601 timestamp, e.g. 2026-06-20T00:00:00.000Z — plain wall clock time, same caveat as start (the "Z" is a format artifact, not a UTC claim). Treated as inclusive and must be after start. All timestamps returned by this API are likewise plain wall clock time, unconverted. | |
| start | Yes | Required. Window start as an ISO 8601 timestamp, e.g. 2026-06-19T00:00:00.000Z. IMPORTANT: despite the trailing "Z", this is plain WALL CLOCK time, not true UTC — Glooko records only the literal date/time the patient's device showed, with no timezone attached. Use the patient's own wall-clock digits directly (no conversion): resolve "yesterday" or "last 3 weeks" straight into the matching wall-clock date and time. Treated as inclusive. |