Menstrual Cycle API: How to Get Cycle Tracking Data

There is no sensor for menstruation. Every other page in this cluster opens with a signal some device picks up; this one opens with a text field. Menstrual flow, spotting, cervical mucus quality, ovulation test strips, and sexual activity are all things a person taps into an app, and the platform health stores exist to hold that log and hand it between apps under permission. A thin layer of genuinely sensor-derived data sits alongside it — overnight wrist temperature, basal body temperature, resting heart rate — but those are inputs a cycle model consumes, not the cycle itself.

Where you can get cycle data#

Identifier names, enum constants, and permission strings change; each row records where the claim came from and when it was checked, so you can re-verify rather than trust the table.

The short version of that table: the log lives on the phone. Cloud coverage for cycle data is thin compared with heart rate or sleep, which pushes most builds toward the on-device stores.

Logged, not measured — and predictions are somebody's model#

Apple documents menstrualFlow samples as taking values from the HKCategoryValueMenstrualFlow enum — unspecified, none, light, medium, heavy — and requires every sample to carry HKMetadataKeyMenstrualCycleStart metadata. Two write patterns are documented. Record a whole period as one sample, with the period start as startDate, the period end as endDate, and the cycle-start metadata set to true. Or write several samples across the period, marking only the first with cycle-start true and the rest false, varying the flow value to capture how it changed.

Health Connect splits the same idea in two. MenstruationPeriodRecord is an interval record carrying startTime and endTime. MenstruationFlowRecord is instantaneous, with a flow field taking FLOW_LIGHT, FLOW_MEDIUM, FLOW_HEAVY, or FLOW_UNKNOWN. Both sit behind a single permission pair, android.permission.health.READ_MENSTRUATION and android.permission.health.WRITE_MENSTRUATION.

The sensor-derived slice is narrower than most product plans assume. Apple documents that Apple Watch Series 8 and Apple Watch Ultra sample wrist temperature every five seconds overnight during sleep and aggregate the night into one appleSleepingWristTemperature sample corrected for environmental bias, and that Cycle Tracking uses that data to provide a retrospective estimate of when the person likely ovulated, combined with heart rate and logged cycle data. Read that carefully: retrospective, not a forecast. Apple also documents the type as read-only, so you can request permission to read it but cannot save samples of it, and notes Health needs roughly five nights to build a baseline before it displays wrist temperature, even though the samples are readable from the first night.

So flow and period boundaries are logged, ovulation timing derived from temperature is estimated after the fact, and any future fertile window your UI draws is a prediction from a model — yours or a vendor's. Label it as one. This is wellness information, not contraception and not a diagnosis.

Enum mismatches and other traps#

• Flow scales do not line up. Apple offers five constants including an explicit none; Health Connect offers four with FLOW_UNKNOWN in place of a "no flow" value. Merging the two means deciding what Apple's none becomes on Android, and writing that decision down.
• Ovulation results line up even less. Apple's HKCategoryValueOvulationTestResult has negative, luteinizingHormoneSurge, indeterminate, estrogenSurge, and positive. Health Connect's OvulationTestRecord has RESULT_POSITIVE (documented as peak fertility, the LH surge, with ovulation expected in 10 to 36 hours), RESULT_HIGH (documented as a rise in estrogen or luteinizing hormone), RESULT_NEGATIVE, and RESULT_INCONCLUSIVE — and Google documents that any unknown value comes back as inconclusive. Apple separates an estrogen surge from an LH surge; Google folds both into one high-fertility constant.
• Cervical mucus carries an extra dimension on Android. Apple's enum is dry, sticky, creamy, watery, eggWhite. Health Connect has the same five appearances plus APPEARANCE_UNUSUAL, described as an unusual kind worth attention, and a separate sensation field with light, medium, and heavy values. An appearance-to-appearance mapping silently discards sensation.
• Mandatory fields differ per record. Health Connect lists protectionUsed among the mandatory fields on SexualActivityRecord, while IntermenstrualBleedingRecord requires only metadata and time. Check each record's required set rather than assuming a shared shape.
• Coverage is broader than "period". Apple's Reproductive Health list reaches into pregnancy, lactation, contraceptive, and menopausal state. Request only the types your feature actually uses.

Sensitivity: the part you cannot treat as a normal metric#

Cycle data is the most exposed category in this cluster. Since the 2022 Dobbs decision in the United States, period and fertility logs have been treated by users, regulators, and journalists as data that can be subpoenaed or sold, and a breach here is materially worse than losing someone's step count. Handle it as an engineering problem with a privacy budget, not a compliance checkbox.

Practical guidance, none of it legal advice:

• Keep it on-device when you can. HealthKit and Health Connect are permissioned on-device reads with no server-to-server pull — see on-device vs cloud health data. If a feature can be computed on the phone, do not upload the log at all.
• Request the narrowest permission set that ships the feature. Google's Health Connect access guidance is explicit: only request permissions and data types that support the specific, user-facing health features you offer, and justify each one. Google lists period tracking as a declarable health feature in the Play Console.
• Design for silent denial. Apple documents that users grant or deny per data type and that your app is never told a read was denied — from your app's point of view, no data of that type exists. An empty cycle log must not accuse the user of anything.
• Respect Apple's HealthKit terms. Apple states you may not use HealthKit information for advertising or similar services, must not disclose it to a third party without express permission (and even then only to a party that also provides a health or fitness service), cannot sell it to advertising platforms, data brokers, or information resellers, and must provide a privacy policy.
• Get consent and storage right. Our guides on health-data user consent and storing health data securely cover the consent record, encryption, and deletion path this data needs.

Which should you pick?#

• iOS-only cycle logging: HealthKit's Reproductive Health category types, read and written on-device.
• Android: Health Connect's Cycle Tracking records, behind the per-record permissions above.
• Several brands behind one schema: Terra is the only source documented on our pages that normalizes a menstruation datatype. Verify current coverage in its docs.
• Temperature inputs to a cycle model: appleSleepingWristTemperature on iOS, BasalBodyTemperatureRecord or SkinTemperatureRecord on Android. Our Oura vs WHOOP comparison describes Oura's nightly temperature deviation from baseline as a useful cycle-tracking input, but our pages do not document an Oura menstrual-cycle datatype — verify with the vendor.

Before you ship#

Re-verify every identifier, enum constant, and permission string against Apple's and Google's live references, because these move. Write down your cross-platform enum mapping instead of leaving it implicit in code. Label predictions as predictions. And decide, deliberately, whether this data ever needs to leave the device — for cycle tracking, the cheapest privacy control is the data you never collected.