Import Provider Evaluation — Habitica, Strides, Apple Health, Google Fit

Research and decision support. OBJ-1130 asked for these four providers to be evaluated as v4.64 stretch goals. All four were deferred out of v4.64 scope at kickoff; this document answers each in writing so the backlog inherits a decision, not an open question. It ships no code and changes no behavior.

Context: what "viable" means here

v4.64 ships a one-time CSV importer (/settings/import) that reads two files — goals.csv and habit_completions.csv — against a fixed column contract (rails_api/app/services/import_export/csv_schema.rb):

File	Required columns	Optional columns
goals.csv	external_id, name	description, life_area, recurrence_type, recurrence_days, recurrence_interval, duration_minutes, target_amount, unit, target_date
habit_completions.csv	goal_external_id, completed_date	note

If a provider can produce a file (or a small reshape of a file) that fills those columns, adding it to the importer is a column-mapping job, not new backend work. If a provider only exposes data through a live API, the question is whether it fits the separate Connected Apps framework instead (IntegrationProvider / IntegrationConnection / HabitIntegrationMapping, thirteen interactions under rails_api/app/interactions/integrations/, documented in docs/features/connected-apps.md) — which is explicitly one-way, forward-only sync and structurally cannot backfill history (connected-apps.md § Known limitations: "Historical activity from before you connected isn't imported — sync starts from the moment you connect"). A provider whose only real value is historical backfill cannot be served by Connected Apps at all, CSV or not.

Every claim below is cited and dated to when it was read (2026-09-15). Where a provider's docs didn't settle a question, that's stated as "could not establish" rather than guessed.

---

Habitica

Verdict: CSV mapping only

• Public API: Yes — a versioned REST API (v3 is current; v1/v2 are disabled). Auth is a user-supplied token pair, not an OAuth app registration: every request carries x-api-user (the user's ID) and x-api-key (a personal API token), both retrieved from the user's own Habitica account settings. As of late July 2025 requests must also include an x-client identifying header or Habitica's servers reject them. Source: Habitica API documentation, read 2026-09-15; corroborated by Habitica's own community-maintained wiki, Application Programming Interface, and multiple independent third-party integration write-ups describing the identical header pair.
• Historical data — yes, with a caveat: Habitica ships its own built-in CSV export from the product itself (Settings → Data Export, and directly at https://habitica.com/export/history.csv), producing a flat log with columns Task Name, Task ID, Task Type, Date, Value. This is exactly the kind of pre-existing export Orion flagged as the cheapest possible win — a user can self-serve the file with no engineering on our side to produce it. The caveat that matters for a migration tool: Habitica states it does not retain full-resolution history forever — older entries are averaged/compressed the further back they go, so a long-tenured Habitica user's oldest check-ins may arrive as averaged values rather than discrete per-day events. Source: Habitica's own Data Export feature (habitica.com/export/history.csv), corroborated by the community wiki page Data Export and Task History Compression, read 2026-09-15.
• Server API, not device API. No Capacitor plugin, no App Store review implication.
• CSV export exists — call-out per the acceptance criteria. It is not a 1:1 shape match to our two-file contract, though: Habitica's export is a single flat event log (one row per task-history entry), not pre-split into a goal-definition file and a completions file. Mapping it into our contract needs a small reshape, not just a column rename: dedupe rows by Task ID/Task Name into goals.csv (Task ID → external_id, Task Name → name), then filter the same rows into habit_completions.csv (Task ID → goal_external_id, Date → completed_date). That's still squarely "per-provider mapping," just a mapping-plus-filter rather than a pure rename.
• Connected Apps fit: Habitica's v3 API does support outbound webhooks for task-scoring events, which is the same shape Strava uses today — so an ongoing-sync Habitica integration is plausible in principle. But that's a separate, larger piece of work from this evaluation's scope (a new adapter, mapping-confidence work, a new webhook receiver) and isn't needed to capture the historical-import win, which the CSV export already covers more cheaply. Noted as a possible future Connected Apps candidate, not this verdict.

Sizing: XS–S. A column-mapping + reshape script, following the same pattern the importer already needs for any provider. No new backend surface.

---

Strides

Verdict: CSV mapping only (schema unconfirmed — see caveat)

• Public API: none. Strides has no public/documented API. This is confirmed both by the absence of any API documentation on Strides' own site and by repeated user feature requests for one on Strides' own feedback forum, which have not shipped as of this reading. Source: Strides Help Center, read 2026-09-15 (no API mentioned anywhere in the support docs); Strides feature-request forum — "Integrations to log automatically", read 2026-09-15.
• CSV export: yes, confirmed, but gated and only partly documented. The Strides Help Center lists "Data Export" as a bundled feature of the paid Strides Plus tier (alongside Archiving, Goal Notes, Privacy Lock), without describing the export's column structure. Source: Strides Help Center, read 2026-09-15. Strides' founder (Kyle Richey) confirmed directly on the company's own feedback forum that the export is per-tracker-type, not a single unified file — "We can't do a single export in one CSV file, because each of the 4 tracker types has an entirely different data model/structure." That request was marked shipped by the Strides team on 2017-03-08. Source: Strides feature-request forum — "Export all data in one file", read 2026-09-15.
• Historical data: implied yes (an export of a user's own tracked history necessarily includes past entries), but the exact date range and column names could not be established from Strides' public documentation — the export sits behind a paid tier we did not purchase to inspect. This is a real, stated gap, not a guess.
• Server API vs. device: n/a — no API, this is a file export only.
• Connected Apps fit: not applicable — with no API, there is no ongoing-sync path; any Strides integration has to be CSV-based.

Sizing: S, but with an unresolved dependency: someone needs to acquire one real Strides Plus export (a paid subscription, or a volunteered sample from a user) to confirm the actual column headers per tracker type before a mapping can be written. Until that sample exists, this is "cheap once unblocked," not "cheap today."

---

Apple Health (HealthKit)

Verdict: Connected Apps candidate

• No server/cloud API. HealthKit is exclusively an on-device framework (iOS/iPadOS/watchOS/visionOS) — there is no REST endpoint or cloud API surface for reading a user's health data from a backend. Apple's own developer portal describes it as a device-resident "central repository for health and fitness data" and steers integrators toward on-device processing. Source: Apple Developer — Health & Fitness, read 2026-09-15.
• Device API — Capacitor plugin required. Reading HealthKit data from Objectuve's Ionic/Capacitor app requires a native HealthKit-bridging plugin (e.g. @capgo/capacitor-health / the Capawesome Capacitor Health plugin), requesting explicit per-data-type read permissions (NSHealthShareUsageDescription in Info.plist) at runtime. Source: Capawesome — Capacitor Health Plugin, read 2026-09-15.
• App Store privacy review — real, named risk, not boilerplate. Apple's App Review Guideline 5.1.3 (Health and Health Research) specifically restricts what an app may do with HealthKit-sourced data: it "may not use or disclose to third parties data gathered in the health, fitness, and medical research context... for advertising, marketing, or other use-based data mining purposes" beyond directly benefiting the user or health research, "must not write false or inaccurate data into HealthKit," and "may not store personal health information in iCloud." Apple's Health & Fitness developer page reiterates the same constraint directly and additionally requires a completed App Store "Privacy Nutrition Label." Source: Apple App Review Guidelines § 5.1.3, read 2026-09-15; Apple Developer — Health & Fitness, read 2026-09-15.
• Historical data: yes, in principle — HealthKit supports querying a device's full recorded history for a given data type, subject to what the OS/device actually retained. But it is fitness/vitals telemetry (steps, workouts, heart rate, and similar sample types) — there is no HealthKit data type that models an arbitrary user-defined "goal" or "habit" the way Objectuve's Goal model does. Any mapping from HealthKit sample types to Objectuve goals would need product-level decisions about which sample types count as which kind of habit, which is design work, not a data-availability question.
• No CSV export from Apple that fits this use case. iOS's Health app does offer a user-initiated "Export All Health Data" action, but it produces a large (commonly 50–500MB+) two-file XML bundle (export.xml, export_cda.xml), not CSV, and it's a full raw dump rather than anything shaped like our goal/habit model. Building a parser for that XML format is a meaningfully different (and larger) piece of engineering than a CSV column mapping. Source: community documentation of the feature's mechanics and format is consistent across multiple independent write-ups; Apple's own Health app in-product flow (Health → profile icon → Export All Health Data) is the first-party source, read 2026-09-15.
• Why Connected Apps, not the CSV importer: the shape of this integration — live device permission grant, ongoing querying, no server-side file to receive — matches Strava's adapter pattern (rails_api/lib/integration_provider/strava.rb) far more than it matches a one-time CSV upload. It structurally cannot be the one-way, forward-only sync connected-apps.md already documents for history, though: HealthKit can actually return historical on-device data (unlike Strava's forward-only webhook), so a HealthKit adapter would need a real one-time backfill step that neither existing adapter has, which is new framework capability, not just a new provider config.

Sizing: L, and belongs in its own scoped phase, not squeezed into a routine Connected Apps provider addition: a new device-API adapter shape (current framework only knows server-API + webhook/poll), a Capacitor plugin dependency, product decisions on sample-type-to-goal mapping, and a real App Store privacy review cycle with rejection risk.

---

Google Fit

Verdict: not viable

• The API this ticket is asking about is being shut down. Google's own migration FAQ states plainly: "Google Fit APIs will be supported until the end of 2026," and new developer sign-up has been closed since May 1, 2024 — meaning Objectuve cannot even register for Google Fit API access today. Source: Android Developers — Google Fit Migration FAQ, read 2026-09-15. Given today's date (2026-09-15), building new integration work against the Google Fit REST API means shipping against a platform with roughly three and a half months of support life left — not a sound basis for new work.
• Auth (for the record, on the dying API): OAuth 2.0 against a Google account.
• Historical data: the REST API does expose historical aggregated fitness data (that's its core purpose), but this is moot given the sunset above.
• Server API vs. device: the REST API is cloud/server-based; Google's replacement story splits into two different successors depending on need — Health Connect (on-device, Android-only, closest analog to HealthKit) for mobile-first apps, and the separate Google Health API (cloud/account-based, successor lineage from the former Fitbit Web API) for cross-platform cloud integrations. Source: Android Developers — Google Fit Migration FAQ, read 2026-09-15.
• CSV export: Google Takeout can export a user's Google Fit data, but it comes out as a large set of loose per-metric JSON files (not a clean CSV), requiring third-party tooling to consolidate into anything importer-shaped. This is a workaround around a shutting-down product, not something worth building against.
• Connected Apps fit: not for Google Fit specifically — there is nothing to integrate against once the API is gone. The successor, Health Connect, is the Android-side counterpart to HealthKit and would raise the identical "own-phase, device-API, no historical CSV" profile described above if evaluated on its own merits — but that's a different, not-yet-asked question about a different (newer) API, and out of scope for this document, which was asked about Google Fit.

Sizing: n/a — not recommended for v4.65+ backlog under this name. If device-fitness integration is wanted on Android, the actual future ticket is "evaluate Health Connect," not "build Google Fit," and should be scoped alongside the Apple HealthKit phase above so both platforms' device-API work lands together.

---

Summary table

Provider	Verdict	Sizing	Key blocker/enabler
Habitica	CSV mapping only	XS–S	Built-in CSV export exists today; needs a reshape (dedupe → goals, filter → completions), not just a rename. Older history is averaged, not discrete.
Strides	CSV mapping only	S, blocked	Paid-tier CSV export exists but its exact column schema is unconfirmed — needs one real sample acquired before a mapping can be written.
Apple Health	Connected Apps candidate	L, own phase	No server API, no matching CSV export; needs a new device-API adapter shape in the Connected Apps framework plus Capacitor plugin work and App Store privacy review.
Google Fit	not viable	n/a	The REST API sunsets by end of 2026 and has been closed to new developer sign-ups since 2024-05-01. Re-ask as "evaluate Health Connect" if Android device-fitness sync is still wanted.

Recommendation for v4.65+ backlog

1. Habitica CSV mapping (XS–S) — the clear near-term win. Ship a per-provider transform (reshape + column map) from Habitica's native history.csv export into the existing goals.csv + habit_completions.csv contract. No backend change, no new framework surface — this rides the importer exactly as it ships in v4.64.
2. Strides CSV mapping (S, blocked on sample acquisition) — worth doing once someone obtains a real Strides Plus export to confirm the per-tracker-type column headers. File as a follow-up with an explicit "acquire sample" sub-task before estimating the mapping work itself.
3. Apple HealthKit device integration (L, own phase) — do not fold into a routine Connected Apps provider addition. Needs its own phase covering: a new device-API adapter pattern in the Connected Apps framework (current framework is server-API + webhook/poll only), the Capacitor plugin dependency, product decisions on which HealthKit sample types map to which Objectuve goal types, and an App Store privacy review pass (Guideline 5.1.3, Privacy Nutrition Label).
4. Google Fit — do not build. The API is sunsetting within the current milestone's planning horizon and is already closed to new registrations. If Android device-fitness sync remains a goal, replace this backlog item with "evaluate Health Connect" (Android's on-device successor) and consider scoping it together with the HealthKit phase above, since both are device-API integrations with the same shape of work.

---

Last updated: 2026-09-15