Fitness API deprecation scanner: find Fitbit Web API, Google Fit and other dead calls

Run the same scan in CI

The rules above also ship as a GitHub Action in this site’s repository. Add this workflow to .github/workflows/:

name: Fitness API deprecation check
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: nikitastarovzz/aifitnessapi/actions/fitness-api-deprecation-check@main
        with:
          path: .
          fail-on: error # or: warning, never

GitHub Action: uses: nikitastarovzz/aifitnessapi/actions/fitness-api-deprecation-check@main (inputs path, exclude, fail-on = error | warning | never; outputs hits, errors, warnings). It writes an annotation on each line and a job summary table, with no dependencies and nothing sent anywhere. "error" means the vendor says the API is gone, or it is dying and the date the vendor gave has passed; "warning" means deprecated, or dying with the date still ahead. A line containing fitness-api-deprecation-ignore is skipped.

The Action and this page run one rule file and one engine. Both are written by a generator from this site’s data, and the build fails when the Action’s copy differs, so the two cannot disagree. A workflow in the repository runs the Action on its own test fixtures on every change.

What it looks for

129 patterns over 14 entries of the Fitness API Graveyard. Status and date are the graveyard’s, which keeps each vendor’s precision: a year stays a year. Each Fitbit hit links its row on the Fitbit to Google Health API map.

What it does not look for

• Oura personal access tokens: A personal access token is sent like any other bearer token, so nothing in code tells it apart from an OAuth token.
• Google Fit Sensors API and BLE API: Google's BLE API page names no client class or method this site could quote, so only the Sensors API half is scanned.

How a hit is decided

1. Only strings a vendor prints. Every pattern is a written form of something on a vendor page (a path in Fitbit's request tables, a host or a Gradle coordinate in Google's Fit docs, a package name on its registry page), and “Why this pattern” under each hit quotes that page. An API the site has not sourced is not guessed at.
2. Most specific wins. A Fitbit URL is matched against every endpoint path, placeholders and all ({date}, ${id}, %s), and the longest fixed text wins. The bare host, or a /1/user/ path in a file that names Fitbit, reports only when no endpoint matched the line, which is how a URL built by string concatenation is still found.
3. Packages by registry. npm names match in code and package.json; PyPI names only on a line of a Python manifest (requirements.txt, pyproject.toml, Pipfile), since a Python import name need not be the package name.
4. Severity from the vendor's date. Red (an error in CI) when the vendor says it is gone, or it is dying and the date given has passed; a year counts as passed only after December 31. Amber (a warning) for deprecated, or dying with the date ahead.
5. The replacement is the vendor's. For Fitbit endpoints, the Google Health API data type and method from Google's migration tables, the same rows as the Fitbit to Google Health API map; where the tables have no row, the hit says so.

Next step

Turning this into a choice of API:

• Migrating from the Fitbit Web API to the Google Health API →
• How to migrate from Google Fit to Health Connect →
• Migrate off a deprecated fitness API →