Endpoints

Cette page présente les conventions de l'API REST, ainsi qu'un index des tâches courantes de l'API Google Health et des exemples pour chacune d'elles.

Conventions de l'API REST

L'API Google Health respecte les normes des propositions d'amélioration des API Google (AIP), en particulier l'AIP-127 (transcodage HTTP et gRPC) et les AIP-131 à AIP-135 (méthodes standards). Ces normes définissent la manière dont les données sont mappées d'un message proto à une requête HTTP.

Paramètres de requête

Les paramètres de requête sont utilisés lorsque les données font partie de l'URL. Cela concerne principalement les requêtes GET (récupération d'une ressource) ou LIST (filtrage/pagination), mais est également utilisé pour les opérations DELETE.

  • Emplacement : ajouté à l'URL après un ?.
  • Syntaxe : paires clé-valeur séparées par &.
  • Mappage : chaque champ du message de requête qui ne fait pas partie du modèle de chemin d'URL est mappé à un paramètre de requête.
  • Idéal pour : les types simples (chaînes, entiers, énumérations) et les champs répétés.

Pour obtenir une liste détaillée des formats de filtres, des références de champs, des règles de validation et des exemples, consultez le guide sur le filtrage des données.

Exemple de syntaxe :

GET https://health.googleapis.com/v4/users/me/dataTypes/data-type/dataPoints?page_size=10&filter=data_type.interval.start_time >= "2025-10-01T00:00:00Z"

Corps de la requête

Le corps de la requête est utilisé lorsque les données modifient l'état d'une ressource ou sont trop volumineuses pour une URL. Le corps est généralement une représentation JSON de la ressource elle-même. Généralement utilisé pour les opérations POST, PATCH et PUT.

  • Emplacement : dans la charge utile HTTP (non visible dans l'URL).
  • Syntaxe : formaté en tant qu'objet JSON.
  • Mappage : défini dans l'annotation google.api.http.
    • body: "*" signifie que l'intégralité du message constitue le corps.
    • body: "resource_name" signifie que seul un champ spécifique du proto est le corps.
  • Idéal pour : les objets complexes, les messages imbriqués et les données sensibles.

Pour obtenir des instructions détaillées sur les tailles de fenêtre de cumul, les règles de bucketing et des exemples d'agrégation, consultez le guide sur les données agrégées.

Exemple de syntaxe :

POST https://health.googleapis.com/v4/users/me/dataTypes/data-type/dataPoints:rollUp
Content-Type: application/json

{
  "range": {
    "startTime": "2025-11-05T00:00:00Z",
    "endTime": "2025-11-13T00:00:00Z"
  },
  "windowSize": "3600s"
}

Le cas hybride

Dans une méthode Update conforme à la norme AIP-134 ou une opération PATCH, les deux sont utilisés. L'URL contient le nom de la ressource, le corps contient les données de la ressource mise à jour et un paramètre de requête (généralement update_mask) spécifie les champs à modifier.

PATCH https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id
Content-Type: application/json

{
  "endpointUri": "https://myapp.com/new-webhooks/health"
}

Aperçu des principales différences

Fonctionnalité Paramètres de requête Corps de la requête
Consignes AIP Utilisé pour les opérations de recherche, de filtrage et de lecture. Utilisé pour les opérations d'écriture.
Visibilité Visible dans l'historique du navigateur et les journaux du serveur. Masqué dans l'URL.
Complexité Limité aux structures plates ou répétées. Compatible avec les objets JSON profondément imbriqués.
Encodage Doit être encodé au format URL (par exemple, les espaces deviennent %20). Encodage JSON standard.

Dates

Toutes les dates de l'API Google Health sont affichées au format YYYY-MM-DD. L'API Nutrition est compatible avec la norme ISO-8601 pour les valeurs de date, avec les conditions suivantes :

  • Année à quatre chiffres YYYY
  • Valeurs d'année comprises entre 0000 et 9999
  • Aucune application des restrictions de date de début impliquées par la norme ISO-8601 ou une autre époque

En-têtes

L'exécution des points de terminaison de l'API Google Health nécessite l'utilisation des en-têtes et du jeton d'accès appropriés. L'en-tête suivant est recommandé pour les requêtes GET et POST :

Authorization: Bearer access-token
Accept: application/json

Index des tâches de l'API

Cette section fournit un index des tâches courantes de l'API Google Health et des exemples pour chacune d'elles.

Obtenir l'ID utilisateur Fitbit ou Google

Une fois qu'un utilisateur a donné son consentement via Google OAuth 2.0, la réponse du jeton ne contient pas l'ID utilisateur Fitbit ni Google. Appelez le point de terminaison getIdentity immédiatement après avoir échangé le code d'autorisation pour récupérer legacyUserId et healthUserId, et vérifiez que le compte Google de l'utilisateur est associé à Google Health. Si le compte n'est pas encore associé, getIdentity renvoie 400 Bad Request avec le motif ACCOUNT_NOT_LINKED (voir Gérer les comptes Google non associés).

Exemple :

Requête

GET https://health.googleapis.com/v4/users/me/identity
Authorization: Bearer access-token
Accept: application/json

Réponse (200 OK)

{
  "name": "users/me/identity",
  "legacyUserId": "A1B2C3",
  "healthUserId": "111111256096816351"
}

Réponse (400 ACCOUNT_NOT_LINKED)

{
  "error": {
    "code": 400,
    "message": "The account is not linked to Google Health.",
    "status": "FAILED_PRECONDITION",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "ACCOUNT_NOT_LINKED",
        "domain": "health.googleapis.com",
        "metadata": {
          "redirect_uri": "https://fitbit.google.com/auth/signup"
        }
      }
    ]
  }
}

Obtenir des données intrajournalières ou détaillées collectées tout au long d'une journée

Utilisez le point de terminaison list pour un type de données spécifique afin d'obtenir des données intrajournalières ou détaillées collectées tout au long de la journée à des intervalles compatibles avec ce type de données.

Exemple :

Requête

GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints
Authorization: Bearer access-token
Accept: application/json

Réponse

{
  "dataPoints": [
    {
      "dataSource": {
        "recordingMethod": "PASSIVELY_MEASURED",
        "device": {
          "manufacturer": "",
          "displayName": "Charge 6"
        },
        "platform": "FITBIT"
      },
      "steps": {
        "interval": {
          "startTime": "2026-03-04T07:05:00Z",
          "startUtcOffset": "0s",
          "endTime": "2026-03-04T07:06:00Z",
          "endUtcOffset": "0s",
          "civilStartTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 5
            }
          },
          "civilEndTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 6
            }
          }
        },
        "count": "40"
      }
    },
...
  ],
  "nextPageToken": "Xm5h-6L0viZxIlRuWjx5bmvy98zj85uG34tuMn16mu2pntsnZI32iqhq"
}

Obtenir une vue rapprochée des données d'intervalle

Pour récupérer des données d'intervalle sans chevauchement d'enregistrements ni conflits multi-appareils, appelez le point de terminaison reconcile. Le point de terminaison de rapprochement déduplique automatiquement les intervalles qui se chevauchent entre les lots de synchronisation et les différents appareils d'enregistrement, et renvoie un flux continu faisant autorité, adapté à l'affichage des chronologies d'activité et au calcul des durées.

Pour en savoir plus sur les raisons pour lesquelles les appareils connectés produisent des intervalles qui se chevauchent et pour obtenir une comparaison opérationnelle entre list et reconcile, consultez le guide de gestion des données.

L'exemple suivant compare la réponse de list (qui renvoie les deux enregistrements qui se chevauchent) à celle de reconcile (qui résout le conflit en renvoyant l'enregistrement faisant autorité) pour un utilisateur ayant deux sessions d'exercice qui se chevauchent :

Liste brute

GET https://health.googleapis.com/v4/users/me/dataTypes/exercise/dataPoints
Authorization: Bearer access-token
Accept: application/json
 
{
  "dataPoints": [
    {
      "name": "users/111111256096816351/dataTypes/exercise/dataPoints/7797422996486764704",
      "exercise": {
        "interval": {
          "startTime": "2026-09-03T11:20:00Z",
          "endTime": "2026-09-03T11:50:00Z"
        },
        "exerciseType": "RUNNING"
      }
    },
    {
      "name": "users/111111256096816351/dataTypes/exercise/dataPoints/4389052750481144696",
      "exercise": {
        "interval": {
          "startTime": "2026-09-03T11:00:00Z",
          "endTime": "2026-09-03T11:30:00Z"
        },
        "exerciseType": "RUNNING"
      }
    }
  ]
}

Rapproché

GET https://health.googleapis.com/v4/users/me/dataTypes/exercise/dataPoints:reconcile
Authorization: Bearer access-token
Accept: application/json
 
{
  "dataPoints": [
    {
      "dataPointName": "users/111111256096816351/dataTypes/exercise/dataPoints/7797422996486764704",
      "exercise": {
        "interval": {
          "startTime": "2026-09-03T11:20:00Z",
          "endTime": "2026-09-03T11:50:00Z"
        },
        "exerciseType": "RUNNING"
      }
    }
  ]
}

Le rapprochement résout les conflits de sessions en dédupliquant et en sélectionnant l'enregistrement faisant autorité plutôt qu'en synthétisant une union temporelle artificielle (par exemple, de 11:00:00Z à 11:50:00Z). La réponse rapprochée renvoie le point de données gagnant (7797422996486764704) avec son intervalle enregistré d'origine (de 11:20:00Z à 11:50:00Z), ce qui préserve l'intégrité de la télémétrie et des métriques mesurées de cette session.

Filtrer les données

Pour récupérer des sous-ensembles spécifiques d'enregistrements de points de données correspondant à des critères tels qu'un intervalle de temps, une date ou une heure d'observation, utilisez le point de terminaison list ou reconcile avec un paramètre filter.

Pour obtenir des instructions détaillées, des règles de mise en forme, des erreurs de validation et des exemples de requêtes, consultez le guide de filtrage des données.

Filtrer par famille de sources de données

Pour isoler ou agréger des données provenant de types de sources spécifiques (par exemple, des accessoires connectés physiques par rapport à des entrées manuelles), utilisez le paramètre dataSourceFamily.

Pour obtenir des instructions détaillées, des familles compatibles et des exemples de requêtes et de réponses pour reconcile, rollUp et dailyRollUp, consultez Filtrer par famille de sources de données dans le guide "Filtrer les données".

Filtrer les données par heure de début civile de l'intervalle

Utilisez le point de terminaison list avec un paramètre filter pour filtrer les données par heure civile ou par intervalle.

Exemple :

Requête

GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints?filter=steps.interval.civil_start_time >= "2026-03-04T00:00:00"
Authorization: Bearer access-token
Accept: application/json

Réponse

{
  "dataPoints": [
    {
      "dataSource": {
        "recordingMethod": "PASSIVELY_MEASURED",
        "device": {
          "manufacturer": "",
          "displayName": "Charge 6"
        },
        "platform": "FITBIT"
      },
      "steps": {
        "interval": {
          "startTime": "2026-03-04T07:05:00Z",
          "startUtcOffset": "0s",
          "endTime": "2026-03-04T07:06:00Z",
          "endUtcOffset": "0s",
          "civilStartTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 5
            }
          },
          "civilEndTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 4
            },
            "time": {
              "hours": 7,
              "minutes": 6
            }
          }
        },
        "count": "40"
      }
...
  ],
  "nextPageToken": "Xm5h-6L0viZxIlRuQjp5bml1bZ4ve2dhNmZvMnt4Yn7qIGQhbHN3YQ"
}

Filtrer les données en fonction de l'heure physique d'observation d'un échantillon

Utilisez le point de terminaison list avec un paramètre filter pour filtrer les données en fonction de l'heure physique de l'observation de l'échantillon.

Exemple :

Requête

GET https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints?filter=body_fat.sample_time.physical_time >= "2026-03-01T00:00:00Z"
Authorization: Bearer access-token
Accept: application/json

Réponse

{
  "dataPoints": [
    {
      "name": "users/123456789/dataTypes/body-fat/dataPoints/1234567890",
      "dataSource": {
        "recordingMethod": "UNKNOWN",
        "application": {
          "packageName": "",
          "webClientId": "",
          "googleWebClientId": "google-web-client-id"
        },
        "platform": "GOOGLE_WEB_API"
      },
      "bodyFat": {
        "sampleTime": {
          "physicalTime": "2026-03-10T10:00:00Z",
          "utcOffset": "0s",
          "civilTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 10
            },
            "time": {
              "hours": 10
            }
          }
        },
        "percentage": 20
      }
    }
  "nextPageToken": ""
}

Filtrer et agréger par famille de sources de données

Une famille de sources de données est un regroupement logique de sources de données (telles que des montres connectées, des applications mobiles ou des entrées manuelles). Il vous permet d'isoler ou d'agréger des données provenant de types de sources spécifiques (par exemple, des accessoires connectés physiques par rapport à des entrées manuelles).

Les points de terminaison reconcile, rollUp et dailyRollUp sont tous compatibles avec le paramètre dataSourceFamily. Le mécanisme de transmission dépend du point de terminaison :

Point de terminaison (méthode HTTP) Mécanisme
reconcile (GET) Transmettez dataSourceFamily en tant que paramètre de requête d'URL.
rollUp (POST) Transmettez dataSourceFamily en tant que champ dans le corps de la requête JSON.
dailyRollUp (POST) Transmettez dataSourceFamily en tant que champ dans le corps de la requête JSON.

Familles de sources de données compatibles

Le tableau suivant décrit les valeurs dataSourceFamily acceptées :

Option Description
users/me/dataSourceFamilies/all-sources Valeur par défaut  Renvoie les points de données rapprochés de toutes les sources de données first party (1P) et tierces (3P) enregistrées. Les données des applications tierces seront renvoyées avec cette option (par exemple, les pas enregistrés par la montre connectée + les pas enregistrés par l'application tierce + les pas enregistrés par le téléphone mobile + les pas enregistrés manuellement).
users/me/dataSourceFamilies/google-wearables Inclut les données enregistrées par les appareils de suivi Google et Fitbit (comme les bracelets d'activité Fitbit et la Pixel Watch). Exclut les données enregistrées manuellement et les données estimées par le téléphone. Utilisez cette option lorsque votre intégration nécessite des données de télémétrie brutes enregistrées directement par un capteur d'appareil connecté.
users/me/dataSourceFamilies/google-sources Inclut des sources first party Google et Fitbit. Cela inclut les enregistrements des trackers physiques, les données de Santé Connect et toutes les entrées manuelles enregistrées via des applications propriétaires (comme l'app Fitbit ou Google Fit).

Pour obtenir un flux de données rapproché d'une famille de sources de données spécifique, appelez le point de terminaison reconcile avec le paramètre de requête dataSourceFamily.

Par exemple, la requête GET suivante récupère le sommeil enregistré par le tracker pour le jour suivant le 03/03/2026 :

Requête

GET https://health.googleapis.com/v4/users/me/dataTypes/sleep/dataPoints:reconcile?dataSourceFamily=users/me/dataSourceFamilies/google-wearables&filter=sleep.interval.civil_end_time >= "2026-03-03"
Authorization: Bearer access-token
Accept: application/json

Réponse

{
  "dataPoints": [
    {
      "name": "users/2515055256096816351/dataTypes/sleep/dataPoints/2724123844716220216",
      "dataSource": {
        "recordingMethod": "DERIVED",
        "device": {
          "displayName": "Charge 6"
        },
        "platform": "FITBIT"
      },
      "sleep": {
        "interval": {
          "startTime": "2026-03-03T20:57:30Z",
          "startUtcOffset": "0s",
          "endTime": "2026-03-04T04:41:30Z",
          "endUtcOffset": "0s"
        },
        "type": "STAGES",
        "stages": [
          {
            "startTime": "2026-03-03T20:57:30Z",
            "startUtcOffset": "0s",
            "endTime": "2026-03-03T20:59:30Z",
            "endUtcOffset": "0s",
            "type": "AWAKE",
            "createTime": "2026-03-04T04:43:40.937183Z",
            "updateTime": "2026-03-04T04:43:40.937183Z"
          },
          {
            "startTime": "2026-03-04T04:07:30Z",
            "startUtcOffset": "0s",
            "endTime": "2026-03-04T04:41:30Z",
            "endUtcOffset": "0s",
            "type": "AWAKE",
            "createTime": "2026-03-04T04:43:40.937183Z",
            "updateTime": "2026-03-04T04:43:40.937183Z"
          }
        ],
        "metadata": {
          "stagesStatus": "SUCCEEDED",
          "processed": true,
          "main": true
        },
        "summary": {
          "minutesInSleepPeriod": "464",
          "minutesAfterWakeUp": "0",
          "minutesToFallAsleep": "0",
          "minutesAsleep": "407",
          "minutesAwake": "57",
          "stagesSummary": [
            {
              "type": "AWAKE",
              "minutes": "56",
              "count": "12"
            },
            {
              "type": "LIGHT",
              "minutes": "198",
              "count": "19"
            },
            {
              "type": "DEEP",
              "minutes": "114",
              "count": "10"
            },
            {
              "type": "REM",
              "minutes": "94",
              "count": "4"
            }
          ]
        },
        "createTime": "2026-03-04T04:43:40.337983Z",
        "updateTime": "2026-03-04T04:43:40.937183Z"
      }
    }
  ],
  "nextPageToken": ""
}

Pour agréger des points de données sur une taille de fenêtre spécifique limitée à une famille de sources de données particulière, appelez le point de terminaison rollUp et transmettez le champ dataSourceFamily dans le corps de la requête JSON.

La requête POST suivante interroge le nombre de pas de marche intrajournaliers à intervalles d'une heure (3600s), agrégés exclusivement à partir d'accessoires connectés :

Requête

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:rollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "startTime": "2026-07-29T00:00:00Z",
    "endTime": "2026-07-29T23:59:59Z"
  },
  "windowSize": "3600s",
  "dataSourceFamily": "users/me/dataSourceFamilies/google-wearables"
}

Réponse

{
  "rollupDataPoints": [
    {
      "startTime": "2026-07-29T08:00:00Z",
      "endTime": "2026-07-29T09:00:00Z",
      "steps": {
        "countSum": "1200"
      }
    },
    {
      "startTime": "2026-07-29T09:00:00Z",
      "endTime": "2026-07-29T10:00:00Z",
      "steps": {
        "countSum": "3450"
      }
    }
  ]
}

Pour agréger les points de données quotidiens d'une famille de sources spécifique, appelez le point de terminaison dailyRollUp et transmettez le champ dataSourceFamily dans le corps de la requête.

Par exemple, la requête suivante calcule les cumuls quotidiens du nombre de pas de l'utilisateur, y compris toutes les sources Google et Fitbit propriétaires (accessoires connectés et entrées manuelles) :

Requête

POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:dailyRollUp
Authorization: Bearer access-token
Accept: application/json

{
  "range": {
    "start": {
      "date": {
        "year": 2026,
        "month": 7,
        "day": 28
      },
      "time": {
        "hours": 0,
        "minutes": 0,
        "seconds": 0,
        "nanos": 0
      }
    },
    "end": {
      "date": {
        "year": 2026,
        "month": 7,
        "day": 30
      },
      "time": {
        "hours": 0,
        "minutes": 0,
        "seconds": 0,
        "nanos": 0
      }
    }
  },
  "windowSizeDays": 1,
  "dataSourceFamily": "users/me/dataSourceFamilies/google-sources"
}

Réponse

{
  "rollupDataPoints": [
    {
      "civilStartTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 28
        },
        "time": {}
      },
      "civilEndTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 28
        },
        "time": {
          "hours": 23,
          "minutes": 59,
          "seconds": 59
        }
      },
      "steps": {
        "countSum": "8430"
      }
    },
    {
      "civilStartTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 29
        },
        "time": {}
      },
      "civilEndTime": {
        "date": {
          "year": 2026,
          "month": 7,
          "day": 29
        },
        "time": {
          "hours": 23,
          "minutes": 59,
          "seconds": 59
        }
      },
      "steps": {
        "countSum": "11245"
      }
    }
  ]
}

Agréger des points de données sur une période donnée

Utilisez le point de terminaison rollUp pour renvoyer l'agrégation des points de données en fonction d'une fenêtre en secondes (windowSize), sur une plage datetime dans l'heure physique de l'utilisateur (en UTC).

Lorsque vous appelez le point de terminaison rollUp, fournissez le corps de la requête représentant les heures de début et de fin requises range et windowSize (au moins "1s"). Pour obtenir des instructions détaillées sur les exigences de windowSize, l'alignement de la résolution de stockage, les règles de segmentation, ainsi que des exemples de requêtes et de réponses, consultez Agrégation sur des intervalles de temps physiques dans le guide sur l'agrégation des données.

Agréger des données sur un ou plusieurs jours

Utilisez le point de terminaison dailyRollUp pour agréger les données sur un ou plusieurs jours (windowSizeDays). Indiquez l'heure civile fermée-ouverte range pour l'intervalle requis dans le corps de la requête. Selon le type de données, le point de terminaison renvoie la somme ou la moyenne de chaque fenêtre.

Pour en savoir plus sur le comportement d'agrégation quotidienne, la gestion de l'heure civile, les limites de plage par requête, ainsi que des exemples de requêtes et de réponses, consultez Agrégation sur plusieurs jours calendaires dans le guide "Agrégation de données".

Mettre à jour les données de santé d'un utilisateur

Utilisez le point de terminaison patch pour mettre à jour les données de santé d'un utilisateur.

Le point de terminaison patch met à jour un enregistrement existant en fonction de l'identifiant spécifié dans l'URL de la requête. Indiquez l'identifiant d'un point de données précédemment inséré. L'API écrase l'enregistrement existant.

Les codes temporels d'intervalle d'un point de données (startTime et endTime) peuvent également être mis à jour par le propriétaire de l'enregistrement ou propagés à partir de plates-formes en amont telles que Santé Connect. Pour en savoir plus sur la mutabilité des codes temporels, consultez le guide de gestion des données. Pour obtenir un exemple de mise à jour des codes temporels d'intervalle, consultez Mettre à jour les codes temporels d'intervalle pour les données existantes.

Quand utiliser l'identifiant de point de données ?

L'identifiant du point de données est essentiel dans les scénarios suivants :

  • Mises à jour ciblées : pour mettre à jour une mesure spécifique, indiquez son identifiant dans la requête patch.
  • Suppressions : la conservation de l'identifiant permet à votre application de supprimer l'enregistrement ultérieurement à l'aide du point de terminaison batchDelete.

Voici un exemple dans lequel un utilisateur met à jour sa mesure de graisse corporelle sur une balance appelée "HumanScale " de l'entreprise "Scales R Us". La nouvelle mesure de la masse graisseuse de l'utilisateur est de 20 % pour la date du 10/03/2026 :

Requête

PATCH https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints/1234567890
Authorization: Bearer access-token
Content-Type: application/json

{
  "name": "users/me/dataTypes/body-fat/dataPoints/1234567890",
  "dataSource": {
    "recordingMethod": "ACTIVELY_MEASURED",
    "device": {
      "formFactor": "SCALE",
      "manufacturer": "Scales R Us",
      "displayName": "HumanScale"
    }
  },
  "bodyFat": {
    "sampleTime": {
      "physicalTime": "2026-03-10T10:00:00Z"
    },
    "percentage": 20
  }
}

Réponse

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4main.DataPoint",
    "name": "users/123456789/dataTypes/body-fat/dataPoints/1234567890",
    "dataSource": {
      "recordingMethod": "ACTIVELY_MEASURED",
      "device": {
        "formFactor": "SCALE",
        "manufacturer": "Scales R Us",
        "displayName": "HumanScale"
      },
      "application": {
        "googleWebClientId": "618308034039.apps.googleusercontent.com"
      },
      "platform": "GOOGLE_WEB_API"
    },
    "bodyFat": {
      "sampleTime": {
        "physicalTime": "2026-03-10T10:00:00Z"
      },
      "percentage": 20
    }
  }
}

Mettre à jour les codes temporels d'intervalle pour les données existantes

Pour mettre à jour les codes temporels d'intervalle (startTime et endTime dans les charges utiles JSON REST, ou start_time et end_time dans gRPC) d'un point de données existant, envoyez une requête PATCH à l'URI de ressource du point de données. Seul le créateur ou le propriétaire d'origine d'un enregistrement peut modifier ses champs. Les applications ne peuvent pas modifier les points de données qu'elles n'ont pas créés.

Pour en savoir plus sur la mutabilité des codes temporels, les mises à jour en amont de Santé Connect et les implications de la mise en cache, consultez le guide de gestion des données.

L'exemple suivant montre une application propriétaire qui met à jour les codes temporels d'intervalle d'un journal d'hydratation existant à l'aide du point de terminaison patch :

Requête

PATCH https://health.googleapis.com/v4/users/me/dataTypes/hydration-log/dataPoints/4093039283164890826
Authorization: Bearer access-token
Content-Type: application/json

{
  "hydrationLog": {
    "interval": {
      "startTime": "2026-09-03T10:05:00Z",
      "endTime": "2026-09-03T10:19:59Z"
    },
    "amountConsumed": {
      "milliliters": 350
    }
  }
}

Réponse

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4.DataPoint",
    "name": "users/111111256096816351/dataTypes/hydration-log/dataPoints/4093039283164890826",
    "hydrationLog": {
      "interval": {
        "startTime": "2026-09-03T10:05:00Z",
        "endTime": "2026-09-03T10:19:59Z",
        "civilStartTime": {
          "date": {
            "year": 2026,
            "month": 9,
            "day": 3
          },
          "time": {
            "hours": 10,
            "minutes": 5
          }
        },
        "civilEndTime": {
          "date": {
            "year": 2026,
            "month": 9,
            "day": 3
          },
          "time": {
            "hours": 10,
            "minutes": 19,
            "seconds": 59
          }
        }
      },
      "amountConsumed": {
        "milliliters": 350
      }
    }
  }
}

Enregistrer un aliment

Pour enregistrer un aliment, envoyez une requête POST au point de terminaison nutrition-log dataPoints. Le corps de la requête contient un objet DataPoint avec un objet nutritionLog. Pour en savoir plus, consultez le guide sur la nutrition.

Exemple :

Requête

POST https://health.googleapis.com/v4/users/me/dataTypes/nutrition-log/dataPoints
Authorization: Bearer access-token
Content-Type: application/json

{
  "nutritionLog": {
    "interval": {
      "startTime": "2026-06-16T12:00:00Z",
      "endTime": "2026-06-16T12:30:00Z"
    },
    "foodDisplayName": "Banana",
    "mealType": "LUNCH",
    "energy": {
      "kcal": 105
    },
    "totalCarbohydrate": {
      "grams": 27
    },
    "totalFat": {
      "grams": 0.3
    }
  }
}

Réponse

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4.DataPoint",
    "name": "users/123456789/dataTypes/nutrition-log/dataPoints/567890",
    "dataSource": {
      "recordingMethod": "ACTIVELY_MEASURED",
      "platform": "GOOGLE_WEB_API"
    },
    "nutritionLog": {
      "interval": {
        "startTime": "2026-06-16T12:00:00Z",
        "startUtcOffset": "0s",
        "endTime": "2026-06-16T12:30:00Z",
        "endUtcOffset": "0s"
      },
      "energy": {
        "kcal": 105
      },
      "totalCarbohydrate": {
        "grams": 27
      },
      "totalFat": {
        "grams": 0.3
      },
      "mealType": "LUNCH",
      "foodDisplayName": "Banana"
    }
  }
}

Supprimer les données de santé des utilisateurs

Utilisez la méthode batchDelete pour supprimer un tableau de données de l'application Fitbit d'un utilisateur.

Voici un exemple dans lequel un utilisateur a déjà enregistré sa masse graisseuse sur une balance, mais souhaite supprimer l'enregistrement. Utilisez les valeurs user-id et data-point-id de l'action d'insertion d'origine :

Requête

POST https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints:batchDelete
Authorization: Bearer access-token
Accept: application/json
content-length: 93

{
  "names": [
    "users/123456789/dataTypes/body-fat/dataPoints/1234567890"
  ]
}

Réponse

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4main.BatchDeleteDataPointsResponse"
  }
}

Trouver des informations sur un appareil

Utilisez le point de terminaison list pour récupérer la liste des appareils associés au compte d'un utilisateur. Cela inclut les informations sur le modèle de l'appareil (deviceVersion) et la date de sa dernière synchronisation avec l'application mobile Google Health (lastSyncTime).

La configuration de la liste et les informations de synchronisation sont utiles pour résoudre les problèmes de synchronisation ou récupérer des données historiques depuis la dernière synchronisation.

Exemple :

Requête

GET https://health.googleapis.com/v4/users/me/pairedDevices
Authorization: Bearer access-token
Accept: application/json

Réponse

{
  "pairedDevices": [
    {
      "name": "users/me/pairedDevices/123456",
      "deviceType": "TRACKER",
      "batteryStatus": "High",
      "batteryLevel": 88,
      "lastSyncTime": "2026-03-04T07:05:00Z",
      "deviceVersion": "Charge 6",
      "macAddress": "00:11:22:33:44:55",
      "features": [
        "STEPS",
        "HEART_RATE"
      ]
    }
  ]
}

Interroger les données historiques

L'un des principaux avantages de l'API Google Health est la possibilité de suivre les performances d'un utilisateur et de surveiller ses constantes vitales sur de longues périodes. Vous pouvez interroger les données d'un utilisateur aussi loin qu'elles ont été enregistrées. L'API n'impose aucune limite ni restriction sur la quantité de données historiques que votre application peut consommer.

Toutefois, l'interrogation des données historiques reste régie par les limites de débit standards. Pour gérer la stabilité du système et éviter les charges utiles excessives, l'API Google Health utilise la pagination automatique avec des tailles de page spécifiques aux points de terminaison. Notez les limites et le comportement suivants :

  • Pagination automatique : si vous interrogez une longue période de données, l'API ne renvoie que la première page de résultats, jusqu'à la limite de taille de page pour ce point de terminaison, ainsi qu'un nextPageToken. Vous devez utiliser nextPageToken pour demander les pages suivantes.
  • Tailles de page variables : les limites de plafonnement dépendent du point de terminaison et du type de données. Pour la plupart des types de données, la taille de page est limitée à 10 000 maximum. Toutefois, pour certains types de données tels que exercise et sleep, la taille de page par défaut et maximale est limitée à 25. Par exemple, si un client demande toutes les données sur le sommeil des 10 dernières années, l'API ne renverra que 25 périodes de sommeil sur la première page.
  • Restrictions de plage de dates de cumul : pour les points de terminaison de cumul et d'agrégation de données (tels que rollUp et dailyRollUp), les plages de dates de requête sont limitées en fonction du type de données :
    • Une plage maximale de 14 jours pour calories-in-heart-rate-zone, heart-rate, active-minutes et total-calories.
    • Une plage maximale de 90 jours pour tous les autres types de données de cumul.

Selon le volume de données historiques dont votre application a besoin, la récupération de l'ensemble de données complet nécessite de paginer les pages de manière séquentielle. Gardez cela à l'esprit lorsque vous concevez le processus de synchronisation des données de votre application.

Pour garantir des performances optimales et éviter les erreurs d'API, suivez ces consignes lorsque vous interrogez des données historiques :

Synchronisation des données par phases (chargement à chaud ou à froid)

  • Chargement "à chaud" initial : récupérez et n'affichez que les données des 7 à 14 derniers jours lors de la séquence de chargement principale. Cela permet aux utilisateurs de voir les données immédiatement, sans attendre les requêtes de longue durée.
  • Chargement "à froid" en arrière-plan : déléguez la récupération des données historiques plus anciennes à une file d'attente asynchrone de priorité inférieure ou à un processus en arrière-plan après l'affichage de l'interface utilisateur principale.

Fragmentation des requêtes pour l'agrégation

  • Étant donné que les points de terminaison de cumul et de cumul quotidien appliquent une limite maximale de plage de dates (14 ou 90 jours selon le type de données), vous devez décomposer les requêtes d'agrégation historiques volumineuses en intervalles séquentiels plus petits respectant ces limites.
  • Regroupez ou séquencez ces sous-requêtes de manière sécurisée pour respecter les limites de simultanéité et maintenir des indicateurs de progression stables dans l'interface utilisateur.

Exploiter les roll-ups pré-agrégés

Restructurez les tableaux de bord de présentation et les graphiques de tendance pour utiliser des points de terminaison récapitulatifs pré-agrégés (tels que DailyRollUpDataPoints). Cela réduira considérablement les frais de calcul sur le backend et le temps de transfert réseau vers le client.

Gestion résiliente des exceptions (nouvelles tentatives intelligentes)

  • Mettez en œuvre une gestion stricte de l'intervalle exponentiel entre les tentatives lorsque vous rencontrez des limites de débit (429 Too Many Requests) et des délais d'expiration de la passerelle du serveur (504 Gateway Timeout). Ne relancez jamais immédiatement les charges utiles volumineuses ayant échoué. Les nouvelles tentatives instantanées multiplient l'encombrement du backend et aggravent la dégradation du système.
Précédent
Bibliothèques clientes
Suivant
Filtres