На этой странице приведены общие сведения о соглашениях REST API, а также список распространенных задач Google Health API и примеры их выполнения.
Соглашения REST API
Google Health API соответствует стандартам Google API Improvement Proposals (AIP), в частности AIP-127 (HTTP and gRPC Transcoding) и AIP-131 – AIP-135 (Standard Methods). Эти стандарты определяют, как данные сопоставляются из прото-сообщения с HTTP-запросом.
Параметры запроса
Параметры запроса используются, когда данные являются частью URL. В основном это запросы GET (получение ресурса) или LIST (фильтрация/разбиение на страницы), но также используется для операций DELETE.
- Расположение. Добавляется к URL после символа
?. - Синтаксис. Пары "ключ-значение", разделенные символом
&. - Сопоставление. Каждое поле в сообщении запроса, которое не является частью шаблона пути URL, сопоставляется с параметром запроса.
- Подходит для простых типов (строки, целые числа, перечисления) и повторяющихся полей.
Подробный список форматов фильтров, справочные материалы по полям, правила проверки и примеры приведены в руководстве по фильтрации данных.
Пример синтаксиса:
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"
Тело запроса
Тело запроса используется, когда данные изменяют состояние ресурса или слишком велики для URL. Тело обычно представляет собой JSON-представление самого ресурса. Обычно используется для операций POST, PATCH и PUT.
- Размещение. Внутри полезной нагрузки HTTP (не видно в URL).
- Синтаксис. Формат объекта JSON.
- Сопоставление. Определяется в аннотации
google.api.http.body: "*"означает, что все сообщение является телом.body: "resource_name"означает, что телом является только определенное поле в прототипе.
- Для чего подходит: сложные объекты, вложенные сообщения и конфиденциальные данные.
Подробные инструкции по размерам окон объединения, правилам группировки и примеры агрегирования можно найти в руководстве по агрегированным данным.
Пример синтаксиса:
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"
}Гибридный чехол
В методе Update, соответствующем AIP-134, или операции PATCH используются оба.
URL содержит название ресурса, тело – обновленные данные ресурса, а параметр запроса (обычно update_mask) указывает, какие поля нужно изменить.
PATCH https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id
Content-Type: application/json
{
"endpointUri": "https://myapp.com/new-webhooks/health"
}
Основные различия
| Функция | Параметры запроса | Тело запроса |
|---|---|---|
| Рекомендации по использованию AIP | Используется для поиска, фильтрации и операций чтения. | Используется для операций записи. |
| Видимость | Они видны в истории браузера и журналах сервера. | Скрыто из URL. |
| Сложность | Ограничено плоскими или повторяющимися структурами. | Поддерживает глубоко вложенные объекты JSON. |
| Кодирование | Должен быть закодирован для URL (например, пробелы заменяются на %20). |
Стандартная кодировка JSON. |
Даты
Все даты в Google Health API указываются в формате YYYY-MM-DD. Nutrition API поддерживает стандарт ISO-8601 для значений даты со следующими условиями:
- Год в четырехзначном формате
YYYY - Значения года в диапазоне 0000–9999.
- Ограничения на дату начала, предусмотренные стандартом ISO-8601 или другими началами отсчета, не применяются.
заголовки;
Для выполнения конечных точек Google Health API необходимо использовать соответствующие заголовки и токен доступа. Для запросов GET и POST рекомендуется использовать следующий заголовок:
Authorization: Bearer access-token Accept: application/json
Индекс задачи API
В этом разделе приведены примеры распространенных задач, которые можно выполнять с помощью Google Health API.
Как получить идентификатор пользователя Fitbit или Google
После того как пользователь предоставит согласие через Google OAuth 2.0, ответ с токеном не будет содержать идентификатор пользователя Fitbit или Google. Вызовите конечную точку getIdentity сразу после обмена кодом авторизации, чтобы получить legacyUserId и healthUserId и убедиться, что аккаунт Google пользователя связан с Google Здоровьем. Если аккаунт ещё не связан, getIdentity возвращает 400 Bad
Request с причиной ACCOUNT_NOT_LINKED (см. раздел Обработка несвязанных аккаунтов Google).
Пример:
Запрос
GET https://health.googleapis.com/v4/users/me/identity Authorization: Bearer access-token Accept: application/json
Ответ (200 OK)
{
"name": "users/me/identity",
"legacyUserId": "A1B2C3",
"healthUserId": "111111256096816351"
}Ответ (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"
}
}
]
}
}Получение подробных данных, собранных в течение дня
Используйте конечную точку list для определенного типа данных, чтобы получить подробные данные, собранные в течение дня с поддерживаемыми интервалами для этого типа данных.
Пример:
Запрос
GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints Authorization: Bearer access-token Accept: application/json
Ответ
{
"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"
}Как получить согласованное представление данных за интервал
Чтобы получить данные за интервал без перекрывающихся записей или конфликтов между устройствами, вызовите конечную точку reconcile. Конечная точка reconcile автоматически удаляет дублирующиеся интервалы в пакетах синхронизации и на нескольких записывающих устройствах, возвращая авторитетный непрерывный поток, подходящий для рендеринга временных шкал активности и расчета продолжительности.
Чтобы узнать, почему подключенные устройства создают перекрывающиеся интервалы, и сравнить работу list и reconcile, ознакомьтесь с руководством по управлению данными.
В примере ниже сравниваются ответы list (возвращает обе перекрывающиеся записи) и reconcile (разрешает конфликт, возвращая авторитетную запись) для пользователя с двумя перекрывающимися тренировками:
Необработанный список
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"
}
}
]
}Сверено
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"
}
}
]
}При согласовании конфликтующие сеансы дедуплицируются и выбирается авторитетная запись, а не создается искусственное объединение времени (например, с 11:00:00Z до 11:50:00Z). Согласованный ответ возвращает выигрышный элемент данных (7797422996486764704) с его исходным записанным интервалом (с 11:20:00Z до 11:50:00Z), сохраняя целостность измеренной телеметрии и показателей этого сеанса.
Введите фильтр
Чтобы получить определенные подмножества записей элементов данных, соответствующих критериям, таким как интервал времени, дата или время наблюдения, используйте конечную точку list или reconcile с параметром filter.
Подробные инструкции, правила форматирования, ошибки валидации и примеры запросов можно найти в руководстве по фильтрации данных.
Фильтр по семейству источников данных
Чтобы изолировать или агрегировать данные из определенных типов источников (например, физических носимых устройств по сравнению с записями, введенными вручную), используйте параметр dataSourceFamily.
Подробные инструкции, поддерживаемые семейства, а также примеры запросов и ответов для reconcile, rollUp и dailyRollUp приведены в разделе Фильтрация по семейству источников данных руководства по фильтрации данных.
Как отфильтровать данные по времени начала интервала
Используйте конечную точку list с параметром filter, чтобы отфильтровать данные по гражданскому времени или интервалу.
Пример:
Запрос
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
Ответ
{
"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"
}Как отфильтровать данные по физическому времени наблюдения за выборкой
Используйте конечную точку list с параметром filter, чтобы отфильтровать данные по времени наблюдения.
Пример:
Запрос
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
Ответ
{
"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": ""
}Фильтрация и агрегирование по семейству источников данных
Семейство источников данных – это логическая группировка источников данных (например, умные часы, мобильные приложения или записи, добавленные вручную). Это позволяет изолировать или агрегировать данные из определенных типов источников (например, физических носимых устройств по сравнению с записями, сделанными вручную).
Конечные точки reconcile, rollUp и dailyRollUp поддерживают параметр dataSourceFamily. Механизм передачи зависит от конечной точки:
| Конечная точка (метод HTTP) | Механизм |
|---|---|
reconcile (GET) |
Передайте dataSourceFamily в качестве параметра запроса URL. |
rollUp (POST) |
Передайте dataSourceFamily в качестве поля в теле запроса JSON. |
dailyRollUp (POST) |
Передайте dataSourceFamily в качестве поля в теле запроса JSON. |
Поддерживаемые семейства источников данных
В таблице ниже описаны поддерживаемые значения dataSourceFamily.
| Option | Описание |
|---|---|
users/me/dataSourceFamilies/all-sources |
Значение по умолчанию. Возвращает элементы данных, согласованные по всем зарегистрированным собственным и сторонним источникам данных. При выборе этого варианта будут возвращены данные сторонних приложений (например, шаги, зарегистрированные умными часами, сторонним приложением и мобильным телефоном, а также добавленные вручную). |
users/me/dataSourceFamilies/google-wearables |
Включает данные, записанные устройствами Google и трекерами Fitbit (например, носимыми трекерами Fitbit и Pixel Watch). Исключает данные, зарегистрированные вручную, и данные, рассчитанные телефоном. Используйте этот вариант, если для интеграции требуется необработанная телеметрия датчиков, записанная непосредственно носимым оборудованием. |
users/me/dataSourceFamilies/google-sources |
Включает собственные источники Google и Fitbit. К ним относятся записи с физических трекеров, данные из сервиса "Здоровье и спорт" и любые записи, добавленные вручную через приложения Google, например приложение Fitbit или Google Fit. |
Чтобы получить согласованный поток данных из определенного семейства источников данных, вызовите конечную точку reconcile с параметром запроса dataSourceFamily.
Например, следующий GET-запрос получает данные о сне, записанные трекером, за день после 3 марта 2026 года:
Запрос
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
Ответ
{
"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": ""
}Чтобы агрегировать элементы данных за определенный период времени, ограниченный определенным семейством источников данных, вызовите конечную точку rollUp и передайте поле dataSourceFamily в теле запроса JSON.
Следующий запрос POST запрашивает количество шагов за день с часовыми интервалами (3600s), агрегированное исключительно с носимых устройств:
Запрос
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"
}Ответ
{
"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"
}
}
]
}Чтобы агрегировать ежедневные данные для определенного семейства источников, вызовите конечную точку dailyRollUp и передайте поле dataSourceFamily в теле запроса.
Например, следующий запрос рассчитывает ежедневные сводки по шагам пользователя, включая все собственные источники Google и Fitbit (носимые устройства и записи, добавленные вручную):
Запрос
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"
}Ответ
{
"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"
}
}
]
}Как агрегировать данные за определенный период времени
Используйте конечную точку rollUp, чтобы получить агрегированные элементы на основе окна в секундах (windowSize) за диапазон datetime в физическом времени пользователя (в формате UTC).
При вызове конечной точки rollUp укажите в теле запроса требуемый полуинтервал времени range и windowSize (не менее "1s"). Подробные инструкции по требованиям к windowSize, согласованию разрешения хранилища, правилам группировки, а также примеры запросов и ответов можно найти в разделе Агрегирование по физическим интервалам времени руководства по агрегированию данных.
Агрегирование данных за один или несколько дней
Используйте конечную точку dailyRollUp, чтобы агрегировать данные за один или несколько дней (windowSizeDays). Укажите в теле запроса полуоткрытый интервал гражданского времени range. В зависимости от типа данных конечная точка возвращает сумму или среднее значение для каждого окна.
Подробную информацию о ежедневном агрегировании, обработке гражданского времени, ограничениях диапазона для каждого запроса, а также примеры запросов и ответов можно найти в разделе Агрегирование по календарным дням руководства по агрегированию данных.
Обновление данных о здоровье пользователя
Чтобы обновить данные о здоровье пользователя, используйте конечную точку patch.
Конечная точка patch обновляет существующую запись на основе идентификатора, указанного в URL запроса. Укажите идентификатор ранее добавленного элемента данных. API перезапишет существующую запись.
Временные метки интервала элемента данных (startTime и endTime) также могут быть обновлены владельцем записи или получены от вышестоящих платформ, таких как "Здоровье и спорт". Подробную информацию об изменяемости временных меток можно найти в руководстве по управлению данными. Пример обновления временных меток интервалов приведен в разделе Обновление временных меток интервалов для существующих данных.
Когда использовать идентификатор элемента данных
Идентификатор элемента данных необходим в следующих случаях:
- Целевые обновления. Чтобы обновить определенный показатель, укажите его идентификатор в запросе
patch. - Удаление. Сохранение идентификатора позволяет приложению удалить запись позже с помощью конечной точки
batchDelete.
Ниже приведен пример, в котором пользователь обновляет данные о жировой ткани, полученные с помощью весов HumanScale от компании Scales R Us. Новое значение доли жировой ткани пользователя составляет 20 % на 10 марта 2026 года:
Запрос
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
}
}Ответ
{
"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
}
}
}Как обновить временные метки интервалов для существующих данных
Чтобы обновить временные метки интервала (startTime и endTime в полезной нагрузке REST JSON или start_time и end_time в gRPC) существующего элемента данных, отправьте запрос PATCH к URI ресурса элемента данных. Изменять поля записи может только ее создатель или владелец. Приложения не могут редактировать данные, которые они не создавали.
Дополнительную информацию об изменяемости временных меток, обновлениях из платформы "Здоровье и спорт" и последствиях кеширования можно найти в руководстве по управлению данными.
В примере ниже показано, как приложение-владелец обновляет временные метки интервала в существующей записи о потреблении воды с помощью конечной точки patch.
Запрос
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
}
}
}Ответ
{
"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
}
}
}
}Записать продукт
Чтобы зарегистрировать блюдо, отправьте запрос POST к конечной точке nutrition-log dataPoints. Тело запроса содержит DataPoint с объектом nutritionLog.
Дополнительную информацию можно найти в руководстве по питанию.
Пример:
Запрос
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
}
}
}Ответ
{
"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"
}
}
}Удалить данные о здоровье пользователя
Используйте метод batchDelete, чтобы удалить массив данных приложения Fitbit пользователя.
Вот пример, когда пользователь ранее записал свою жировую ткань на весах, но хочет удалить запись. Используя user-id и data-point-id из исходного действия вставки:
Запрос
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"
]
}Ответ
{
"done": true,
"response": {
"@type": "type.googleapis.com/google.devicesandservices.health.v4main.BatchDeleteDataPointsResponse"
}
}Как найти информацию об устройстве
Используйте конечную точку list, чтобы получить список устройств, подключенных к аккаунту пользователя. К ним относятся модель устройства (deviceVersion) и время его последней синхронизации с мобильным приложением Google Health (lastSyncTime).
Конфигурация списка и информация о синхронизации могут пригодиться при устранении неполадок с синхронизацией или получении статистики с момента последней синхронизации.
Пример:
Запрос
GET https://health.googleapis.com/v4/users/me/pairedDevices Authorization: Bearer access-token Accept: application/json
Ответ
{
"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"
]
}
]
}Запрос статистики
Одно из основных преимуществ Google Health API – возможность отслеживать показатели здоровья пользователя в течение длительного времени. Вы можете запрашивать данные пользователя за весь период, в течение которого они записывались. API не накладывает никаких ограничений на объем статистики, которую может использовать ваше приложение.
Однако на запросы статистики по-прежнему распространяются стандартные ограничения. Чтобы обеспечить стабильность системы и предотвратить чрезмерную нагрузку, Google Health API использует автоматическую разбивку на страницы с размерами страниц, зависящими от конечной точки. Обратите внимание на следующие ограничения и особенности:
- Автоматическая разбивка на страницы. Если вы запрашиваете данные за длительный период, API вернет только первую страницу результатов, размер которой не превышает ограничение для конечной точки, а также токен
nextPageToken. Чтобы запросить последующие страницы, необходимо использоватьnextPageToken. - Переменные размеры страниц. Ограничения зависят от конечной точки и типа данных. Для большинства типов данных размер страницы ограничен 10 000.
Однако для некоторых типов данных, таких как
exerciseиsleep, размер страницы по умолчанию и максимальный размер страницы ограничены 25. Например, если клиент запрашивает все данные о сне за последние 10 лет, API все равно вернет только 25 сеансов сна на первой странице. - Ограничения на диапазон дат для сводных данных. Для конечных точек сводных и агрегированных данных (таких как
rollUpиdailyRollUp) диапазоны дат запросов ограничены в зависимости от типа данных:- Максимальный диапазон дат для
calories-in-heart-rate-zone,heart-rate,active-minutesиtotal-caloriesсоставляет 14 дней. - Максимальный диапазон дат для всех остальных типов данных в сводных ресурсах составляет 90 дней.
- Максимальный диапазон дат для
В зависимости от объема статистики, необходимой вашему приложению, для получения всего набора данных может потребоваться последовательно пролистать страницы. Учитывайте это при разработке процесса синхронизации данных в приложении.
Чтобы обеспечить оптимальную производительность и избежать ошибок API, следуйте этим рекомендациям при запросе статистики:
Поэтапная синхронизация данных (горячая и холодная загрузка)
- Первоначальная загрузка. При первой загрузке извлекайте и показывайте данные только за последние 7–14 дней. Это позволяет пользователям сразу видеть данные, не дожидаясь выполнения длительных запросов.
- Фоновая "холодная" загрузка. Передайте извлечение старых данных в асинхронную очередь с более низким приоритетом или фоновый процесс после отрисовки основного интерфейса.
Разбиение запросов для агрегирования
- Поскольку для конечных точек сводки и ежедневной сводки действует ограничение на максимальный диапазон дат (14 или 90 дней в зависимости от типа данных), вам необходимо разбивать большие запросы на агрегирование за прошлые периоды на более мелкие последовательные интервалы в пределах этих ограничений.
- Объединяйте подзапросы в пакеты или последовательности, чтобы не превышать лимиты на параллельные запросы и поддерживать стабильную работу индикаторов выполнения в интерфейсе.
Используйте предварительно агрегированные сводные данные
Реструктурируйте обзорные панели управления и диаграммы трендов, чтобы использовать предварительно агрегированные сводные конечные точки (например, DailyRollUpDataPoints). Это значительно снизит вычислительную нагрузку на серверную часть и время передачи данных по сети клиенту.
Надежная обработка ошибок (умные повторные попытки)
- При достижении ограничений на частоту запросов (
429 Too Many Requests) и превышении времени ожидания шлюза сервера (504 Gateway Timeout) используйте экспоненциальную выдержку. Не пытайтесь сразу же повторно отправлять большие пакеты данных, которые не удалось передать. Мгновенные повторные попытки увеличивают нагрузку на серверную часть и усугубляют деградацию системы.