एंडपॉइंट

इस पेज पर, REST API के नियमों के बारे में खास जानकारी दी गई है. साथ ही, Google Health API के सामान्य टास्क और हर टास्क के उदाहरणों की इंडेक्स भी दी गई है.

REST API के नियम

Google Health API, Google API Improvement Proposals (AIP) के स्टैंडर्ड के मुताबिक काम करता है. खास तौर पर, AIP-127 (एचटीटीपी और gRPC ट्रांसकोडिंग) और AIP-131 से लेकर AIP-135 (स्टैंडर्ड तरीके). इन स्टैंडर्ड से यह तय होता है कि किसी प्रोटो मैसेज से एचटीटीपी अनुरोध में डेटा को कैसे मैप किया जाता है.

क्वेरी पैरामीटर

क्वेरी पैरामीटर का इस्तेमाल तब किया जाता है, जब डेटा यूआरएल का हिस्सा होता है. यह मुख्य रूप से GET अनुरोधों (किसी संसाधन को फ़ेच करना) या LIST अनुरोधों (फ़िल्टर करना/पेज नंबर डालना) के लिए है. हालांकि, इसका इस्तेमाल DELETE कार्रवाइयों के लिए भी किया जाता है.

  • प्लेसमेंट: इसे यूआरएल में ? के बाद जोड़ा जाता है.
  • सिंटैक्स: की-वैल्यू पेयर, & से अलग किए जाते हैं.
  • मैपिंग: अनुरोध मैसेज में मौजूद हर फ़ील्ड, यूआरएल पाथ टेंप्लेट का हिस्सा नहीं होता. इसे क्वेरी पैरामीटर पर मैप किया जाता है.
  • सबसे सही विकल्प: सामान्य टाइप (स्ट्रिंग, पूर्णांक, enum) और दोहराए गए फ़ील्ड के लिए.

सिंटैक्स का उदाहरण:

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"

अनुरोध का मुख्य भाग

अनुरोध के मुख्य हिस्से का इस्तेमाल तब किया जाता है, जब डेटा किसी संसाधन की स्थिति में बदलाव करता है या यूआरएल के लिए बहुत बड़ा होता है. बॉडी आम तौर पर, संसाधन का JSON फ़ॉर्मैट होता है. आम तौर पर, इसका इस्तेमाल POST, PATCH, और PUT के लिए किया जाता है.

  • प्लेसमेंट: एचटीटीपी पेलोड में (यूआरएल में नहीं दिखता).
  • सिंटैक्स: इसे 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"
}

हाइब्रिड केस

एआईपी-134 के मुताबिक Update तरीके या PATCH ऑपरेशन में, दोनों का इस्तेमाल किया जाता है. यूआरएल में संसाधन का नाम होता है, मुख्य हिस्से में अपडेट किया गया संसाधन डेटा होता है, और क्वेरी पैरामीटर (आम तौर पर 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"
}

मुख्य अंतर एक नज़र में

सुविधा क्वेरी पैरामीटर अनुरोध का मुख्य भाग
एआईपी के दिशा-निर्देश इस कुकी का इस्तेमाल खोजने, फ़िल्टर करने, और पढ़ने की कार्रवाइयों के लिए किया जाता है. इसका इस्तेमाल लिखने से जुड़ी कार्रवाइयों के लिए किया जाता है.
वीडियो किसको दिखे यह ब्राउज़र के इतिहास और सर्वर लॉग में दिखता है. यूआरएल से छिपाया गया है.
जटिलता यह सुविधा, फ़्लैट या दोहराए गए स्ट्रक्चर के लिए उपलब्ध है. यह डीपली नेस्ट किए गए JSON ऑब्जेक्ट के साथ काम करता है.
एन्कोडिंग इसे यूआरएल-कोड में बदला जाना चाहिए. उदाहरण के लिए, स्पेस %20 बन जाते हैं. JSON के स्टैंडर्ड फ़ॉर्मैट में कोड में बदला गया.

तारीख

Google Health API में सभी तारीखें, YYYY-MM-DD फ़ॉर्मैट में दिखती हैं. Nutrition API, तारीख की वैल्यू के लिए आईएसओ-8601 स्टैंडर्ड का इस्तेमाल करता है. हालांकि, इसके लिए ये शर्तें पूरी होनी चाहिए:

  • साल, चार अंकों में YYYY
  • साल की वैल्यू 0000-9999 के बीच होनी चाहिए
  • ISO-8601 स्टैंडर्ड या अन्य इपोक के हिसाब से, शुरू होने की तारीख से जुड़ी पाबंदियों को लागू नहीं किया गया है

हेडर

Google Health API के एंडपॉइंट को लागू करने के लिए, सही हेडर और ऐक्सेस टोकन का इस्तेमाल करना ज़रूरी है. GET और POST, दोनों तरह के अनुरोधों के लिए इस हेडर का इस्तेमाल करने का सुझाव दिया जाता है:

Authorization: Bearer access-token
Accept: application/json

एपीआई टास्क इंडेक्स

इस सेक्शन में, Google Health API से जुड़े सामान्य टास्क की इंडेक्स दी गई है. साथ ही, हर टास्क के उदाहरण दिए गए हैं.

Fitbit या Google का यूज़र आईडी पाना

Google OAuth 2.0 के ज़रिए उपयोगकर्ता की सहमति मिलने के बाद, टोकन रिस्पॉन्स में Fitbit या Google का उपयोगकर्ता आईडी शामिल नहीं होता. User-ID पाने के लिए, getIdentity एंडपॉइंट को कॉल करें. getIdentity Fitbit के लेगसी वर्शन के यूज़र आईडी और Google के यूज़र आईडी, दोनों को दिखाता है.

हमारा सुझाव है कि जैसे ही कोई नया उपयोगकर्ता OAuth के ज़रिए सहमति देता है, वैसे ही getIdentity एंडपॉइंट को कॉल करें और दोनों उपयोगकर्ता आईडी सेव करें. इससे आपको इंटिग्रेशन में पुराने और नए सिस्टम के साथ काम करने की सुविधा मिलती है.

उदाहरण के लिए:

अनुरोध

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

जवाब

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

पूरे दिन में इकट्ठा किया गया इंट्राडे या ज़्यादा जानकारी वाला डेटा पाना

किसी खास डेटा टाइप के लिए, 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) के साथ दिखाया जाता है. इससे, उस सेशन की मेज़र की गई टेलीमेट्री और मेट्रिक की इंटिग्रिटी बनी रहती है.

डेटा फ़िल्टर करें

समय अंतराल, तारीख या ऑब्ज़र्वेशन के समय जैसी शर्तों से मेल खाने वाले डेटा पॉइंट रिकॉर्ड के खास सबसेट को वापस पाने के लिए, filter पैरामीटर के साथ list या reconcile एंडपॉइंट का इस्तेमाल करें.

ज़्यादा जानकारी वाले दिशा-निर्देशों, फ़ॉर्मैटिंग के नियमों, पुष्टि करने से जुड़ी गड़बड़ियों, और क्वेरी के उदाहरणों के लिए, डेटा फ़िल्टर करने की गाइड देखें.

डेटा सोर्स फ़ैमिली के हिसाब से फ़िल्टर करना

किसी खास तरह के सोर्स से मिले डेटा को अलग करने या इकट्ठा करने के लिए, dataSourceFamily पैरामीटर का इस्तेमाल करें. उदाहरण के लिए, फ़िज़िकल वेयरेबल डिवाइसों से मिले डेटा की तुलना में मैन्युअल एंट्री से मिले डेटा को अलग करना.

reconcile, rollUp, और dailyRollUp के लिए, दिशा-निर्देशों, साथ काम करने वाले फ़ैमिली ग्रुप, और अनुरोध और जवाब के उदाहरणों के बारे में ज़्यादा जानने के लिए, डेटा फ़िल्टर करने से जुड़ी गाइड में डेटा सोर्स फ़ैमिली के हिसाब से फ़िल्टर करना लेख पढ़ें.

सूर्य की रोशनी के समय के हिसाब से डेटा फ़िल्टर करना

list पैरामीटर के साथ 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 पैरामीटर के साथ 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 पैरामीटर के साथ काम करते हैं. डेटा पास करने का तरीका, एंडपॉइंट पर निर्भर करता है:

एंडपॉइंट (एचटीटीपी मेथड) मैकेनिज़्म
reconcile (GET) dataSourceFamily को यूआरएल क्वेरी पैरामीटर के तौर पर पास करें.
rollUp (POST) JSON अनुरोध के मुख्य हिस्से में, dataSourceFamily को फ़ील्ड के तौर पर पास करें.
dailyRollUp (POST) JSON अनुरोध के मुख्य हिस्से में, dataSourceFamily को फ़ील्ड के तौर पर पास करें.

इस्तेमाल किए जा सकने वाले डेटा सोर्स फ़ैमिली

यहां दी गई टेबल में, dataSourceFamily एट्रिब्यूट की इस्तेमाल की जा सकने वाली वैल्यू के बारे में बताया गया है:

विकल्प ब्यौरा
users/me/dataSourceFamilies/all-sources डिफ़ॉल्ट मान. यह फ़ंक्शन, पहले पक्ष (1P) और तीसरे पक्ष (3P) के सभी रजिस्टर किए गए डेटा सोर्स से मिले डेटा पॉइंट दिखाता है. इस विकल्प से, तीसरे पक्ष के ऐप्लिकेशन का डेटा वापस मिल जाएगा. जैसे, स्मार्टवॉच से मापे गए कदमों की संख्या + तीसरे पक्ष के ऐप्लिकेशन से मापे गए कदमों की संख्या + मोबाइल फ़ोन से मापे गए कदमों की संख्या + मैन्युअल तरीके से जोड़े गए कदमों की संख्या.
users/me/dataSourceFamilies/google-wearables इसमें Google और Fitbit के ट्रैकर डिवाइसों (जैसे, Fitbit के पहनने वाले ट्रैकर और Pixel Watch) से रिकॉर्ड किया गया डेटा शामिल है. इसमें मैन्युअल तरीके से लॉग किया गया डेटा और फ़ोन से अनुमान लगाया गया डेटा शामिल नहीं है. इस विकल्प का इस्तेमाल तब करें, जब आपके इंटिग्रेशन के लिए, सीधे तौर पर पहने जाने वाले हार्डवेयर से रिकॉर्ड की गई सेंसर टेलीमेट्री की ज़रूरत हो.
users/me/dataSourceFamilies/google-sources इसमें Google और Fitbit के पहले पक्ष के सोर्स शामिल हैं. इसमें फ़िज़िकल ट्रैकर डिवाइस के रिकॉर्ड, Health Connect से मिला डेटा, और पहले पक्ष के ऐप्लिकेशन (जैसे, Fitbit ऐप्लिकेशन या Google Fit) के ज़रिए मैन्युअल तरीके से लॉग की गई कोई भी एंट्री शामिल है.

किसी डेटा सोर्स फ़ैमिली से मिलाया गया डेटा स्ट्रीम पाने के लिए, dataSourceFamily क्वेरी पैरामीटर के साथ reconcile एंडपॉइंट को कॉल करें.

उदाहरण के लिए, यहां दिया गया GET अनुरोध, 03-03-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 एंडपॉइंट को कॉल करें. साथ ही, JSON अनुरोध के मुख्य हिस्से में dataSourceFamily फ़ील्ड पास करें.

नीचे दिए गए 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 एंडपॉइंट का इस्तेमाल करके, डेटा पॉइंट के एग्रीगेट को वापस पाएं. यह एग्रीगेट, सेकंड में तय की गई विंडो पर आधारित होता है. साथ ही, यह datetime रेंज पर आधारित होता है. यह रेंज, उपयोगकर्ताओं के स्थानीय समय (यूटीसी में) के हिसाब से तय की जाती है.

rollUp एंडपॉइंट को कॉल करते समय, अनुरोध का मुख्य हिस्सा दें. इसमें ज़रूरी समयावधि और windowSize शामिल होना चाहिए. windowSize के लिए, यहां दी गई ज़रूरी शर्तों का ध्यान रखें:

  • कम से कम विंडो साइज़: windowSize की अवधि कम से कम एक सेकंड होनी चाहिए ("1s"). एक सेकंड से कम अवधि, शून्य या नेगेटिव अवधि वाले अनुरोध अस्वीकार कर दिए जाएंगे और आपको 400 Bad Request (INVALID_ROLLUP_WINDOW) मिलेगा.
  • स्टोरेज रिज़ॉल्यूशन अलाइनमेंट: एग्रीगेट किए गए डेटा को सब-बकेट में एक जैसा डिस्ट्रिब्यूट करने के लिए, ऐसा windowSize चुनें जो डेटा टाइप के स्टोरेज रिज़ॉल्यूशन के बराबर या उससे ज़्यादा हो. जैसे, एक मिनट के अंतराल वाले चरणों के लिए "60s". ज़्यादा जानकारी के लिए, रोलअप विंडो का साइज़ और स्टोरेज का रिज़ॉल्यूशन देखें.

उदाहरण के लिए, एक-एक मिनट के अंतराल (60s) में कदमों की संख्या को रोल अप करने के लिए:

अनुरोध

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

{
  "range": {
    "startTime": "2026-02-17T17:00:00Z",
    "endTime": "2026-02-17T17:59:59Z"
  },
  "windowSize": "60s"
}

जवाब

{
  "rollupDataPoints": [
    {
      "startTime": "2026-02-17T17:55:00Z",
      "endTime": "2026-02-17T17:56:00Z",
      "steps": {
        "countSum": "72"
      }
    },
    {
      "startTime": "2026-02-17T17:54:00Z",
      "endTime": "2026-02-17T17:55:00Z",
      "steps": {
        "countSum": "85"
      }
    },
...
  ]
}

एक दिन या एक से ज़्यादा दिनों का एग्रीगेट किया गया डेटा

dailyRollUp एंडपॉइंट का इस्तेमाल तब किया जाना चाहिए, जब आपको एक दिन या कई दिनों के डेटा को इकट्ठा करना हो. इसे windowSize कहा जाता है. अनुरोध के मुख्य हिस्से में, ज़रूरी समयावधि के लिए बंद-खुले समय की जानकारी दें. डेटा टाइप के आधार पर, आपको तय किए गए अंतराल के हिसाब से कुल या औसत वैल्यू मिलेगी.

उदाहरण के लिए:

अनुरोध

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": 2,
        "day": 26
      },
      "time": {
        "hours": 0,
        "minutes": 0,
        "seconds": 0,
        "nanos": 0
      }
    },
    "end": {
      "date": {
        "year": 2026,
        "month": 2,
        "day": 26
      },
      "time": {
        "hours": 23,
        "minutes": 59,
        "seconds": 59,
        "nanos": 0
      }
    }
  },
  "windowSizeDays": 1
}

जवाब

{
  "rollupDataPoints": [
    {
      "civilStartTime": {
        "date": {
          "year": 2026,
          "month": 2,
          "day": 26
        },
        "time": {}
      },
      "civilEndTime": {
        "date": {
          "year": 2026,
          "month": 2,
          "day": 26
        },
        "time": {
          "hours": 23,
          "minutes": 59,
          "seconds": 59
        }
      },
      "steps": {
        "countSum": "3822"
      }
    }
  ]
}

जब रेंज, विंडो के साइज़ का मल्टिपल नहीं होती है, तब बकेटिंग

अगर अनुरोध की गई रेंज, windowSize (या windowSizeDays) का पूरा गुणज नहीं है, तो समय के हिसाब से आखिरी बकेट को रेंज के ऊपरी एंडपॉइंट पर छोटा कर दिया जाएगा. साथ ही, यह विंडो के साइज़ से कम अवधि को कवर करेगा. एपीआई, आपके अनुरोध को बिना किसी बदलाव के स्वीकार करता है. साथ ही, इसमें कोई राउंडिंग, टाइम शिफ़्ट या डेटा इंटरपोलेशन नहीं किया जाता.

अनुरोध की गई पूरी रेंज को कवर करने के लिए, एपीआई सीलिंग डिवीज़न का इस्तेमाल करके एग्रीगेशन विंडो की कुल संख्या का हिसाब लगाता है:

Number of windows = ceiling(Range duration / Window size)

हर बकेट, आपकी रेंज की शुरुआत से क्रमवार तरीके से शुरू होती है. अगर पूरी साइज़ वाली दूसरी विंडो जोड़ने से, अनुरोध की गई समयसीमा खत्म होने के बाद भी डेटा मिलता है, तो आखिरी विंडो को समयसीमा खत्म होने के समय पर काट दिया जाता है (क्लैंप कर दिया जाता है).

बकेटिंग कैसे काम करती है

जब ऐसी रेंज के लिए रोलअप का अनुरोध किया जाता है जिन्हें बांटा नहीं जा सकता, तो एपीआई इन नियमों को लागू करता है:

  • बकेटिंग, अनुरोध की गई रेंज (range.startTime या range.start) की शुरुआत से शुरू होती है और विंडो के साइज़ (windowSize या windowSizeDays) के हिसाब से आगे बढ़ती है.
  • समय के हिसाब से आखिरी बकेट को, अनुरोध की गई रेंज (range.endTime या range.end) के आखिर में क्लैंप किया जाता है. इसका मतलब है कि यह अनुरोध की गई विंडो के साइज़ से कम अवधि को कवर करता है.
  • जवाब में मिले RollupDataPoint या DailyRollupDataPoint ऑब्जेक्ट, अपने शुरू और खत्म होने के टाइमस्टैंप के बारे में साफ़ तौर पर बताते हैं. इनका इस्तेमाल करके, काटे गए बकेट की असल अवधि की जांच की जा सकती है.
  • एपीआई, रोलअप डेटा को उल्टे क्रम में दिखाता है. इसका मतलब है कि सबसे नया डेटा सबसे पहले दिखता है. इसलिए, समय के हिसाब से क्रम में आखिरी बकेट (जो कि छोटा किया गया है) नतीजे के तौर पर मिली सूची में पहले एलिमेंट (index 0) के तौर पर दिखता है.

परिदृश्य: 12 मिनट की रेंज और 5 मिनट की विंडो

मान लें कि कोई क्लाइंट, 12 मिनट की रेंज में 5 मिनट के windowSize के साथ रोलअप करने का अनुरोध करता है:

  • range.startTime: 10:00:00
  • range.endTime: 10:12:00 (कुल अवधि: 12 मिनट)
  • windowSize: 5 minutes

बारह मिनट, पांच मिनट का गुणज नहीं है (12 = 5 * 2 + 2). इसलिए, एपीआई अनुरोध स्वीकार करता है और विंडो की संख्या की गिनती इस तरह करता है: ceiling(12 / 5) = 3.

इससे, समय के हिसाब से ये तीन बकेट तैयार होते हैं:

  1. बकेट 1: [10:00:00, 10:05:00) — अवधि: पांच मिनट (पूरी विंडो)
  2. दूसरा बकेट: [10:05:00, 10:10:00) — अवधि: पांच मिनट (पूरी विंडो)
  3. तीसरा बकेट (काटा गया): [10:10:00, 10:12:00) — अवधि: दो मिनट (range.endTime पर काटा गया)

कुल वैल्यू पर असर

आखिरी विंडो की अवधि कम होने की वजह से, ऐडिटिव मेट्रिक (जैसे कि चरणों की संख्या या कुल संख्या) को छोटा किए गए बकेट में कम कर दिया जाएगा. ऐसा सिर्फ़ कम समय के ट्रैक की वजह से होगा.

अगर कोई उपयोगकर्ता, 12 मिनट के इस पूरे समय के दौरान, हर मिनट 100 कदम की रफ़्तार से चलता है, तो:

  • बकेट 1 (10:00–10:05): 500 कदम (5 मिनट × 100 कदम/मिनट)
  • बकेट 2 (10:05–10:10): 500 कदम (5 मिनट × 100 कदम/मिनट)
  • तीसरा बकेट (10:10–10:12): 200 कदम (2 मिनट × 100 कदम/मिनट)

ऑर्डर करने की सुविधा दिखाने वाले एपीआई रिस्पॉन्स का उदाहरण

एपीआई, नतीजों को उल्टे क्रम में दिखाता है. इसलिए, काटे गए बकेट को दिखाई गई सूची में पहले एलिमेंट के तौर पर दिखाया जाता है:

{
  "rollupDataPoints": [
    {
      "startTime": "2026-08-20T10:10:00Z",
      "endTime": "2026-08-20T10:12:00Z",
      "steps": {
        "countSum": "200"
      }
    },
    {
      "startTime": "2026-08-20T10:05:00Z",
      "endTime": "2026-08-20T10:10:00Z",
      "steps": {
        "countSum": "500"
      }
    },
    {
      "startTime": "2026-08-20T10:00:00Z",
      "endTime": "2026-08-20T10:05:00Z",
      "steps": {
        "countSum": "500"
      }
    }
  ]
}

रोलअप विंडो का साइज़ और अंडरलाइंग स्टोरेज रिज़ॉल्यूशन

rollUp एंडपॉइंट, एक सेकंड या उससे ज़्यादा का कोई भी windowSize स्वीकार करता है. हालांकि, अलग-अलग डेटा टाइप, अलग-अलग सैंपलिंग रेट या इंटरवल की अवधि पर मेज़रमेंट रिकॉर्ड करते हैं और उन्हें सेव करते हैं. उदाहरण के लिए, पहनने लायक डिवाइस से मिलने वाली शारीरिक गतिविधि की मेट्रिक, जैसे कि steps, distance, active-minutes, और active-energy-burned आम तौर पर एक मिनट (60s) के अंतराल पर रिकॉर्ड की जाती हैं.

इंटरवल डेटा टाइप को एग्रीगेट करते समय, rollUp एंडपॉइंट, रिकॉर्ड किए गए हर डेटा पॉइंट को उस बकेट में रखता है जिसमें डेटा पॉइंट का startTime होता है. एपीआई, इंटरवल डेटा को सब-इंटरवल बकेट में न तो बांटता है, न ही इंटरपोलेट करता है, और न ही डिस्ट्रिब्यूट करता है.

अगर आपने डेटा स्टोरेज के इंटरवल से छोटा windowSize तय किया है (उदाहरण के लिए, एक मिनट के इंटरवल पर स्टोर किए गए steps के लिए 10 सेकंड की विंडो का अनुरोध करना):

  1. इंटरवल के startTime से मेल खाने वाले पहले सब-बकेट (उदाहरण के लिए, 10:00:00 से 10:00:10) को, पूरे मिनट के लिए इकट्ठा किया गया काउंट मिलता है. उदाहरण के लिए, उस मिनट के लिए रिकॉर्ड किए गए सभी 100 कदम.
  2. उसी मिनट के बाकी सब-बकेट (10:00:10 से 10:00:20, 10:00:20 से 10:00:30 वगैरह) को कोई डेटा पॉइंट नहीं मिलता, क्योंकि उन विंडो में कोई इंटरवल शुरू नहीं होता.

इस वजह से, डेटा में अचानक से बढ़ोतरी दिखती है. ऐसा इसलिए होता है, क्योंकि पूरे इंटरवल की वैल्यू, पहली सब-विंडो में दिखती है.

डेटा को सही तरीके से इकट्ठा करने के लिए, हमेशा windowSize को टारगेट किए गए डेटा टाइप के स्टोरेज रिज़ॉल्यूशन के बराबर या उससे ज़्यादा समय के लिए सेट करें. उदाहरण के लिए, steps के लिए 60s या उससे ज़्यादा. हर डेटा टाइप के लिए स्टोरेज रिज़ॉल्यूशन और रोलअप विंडो के लिए सुझाई गई कम से कम अवधि जानने के लिए, Google Health API के डेटा टाइप का रेफ़रंस देखें.

उपयोगकर्ता का सेहत का डेटा अपडेट करना

उपयोगकर्ता की सेहत का डेटा अपडेट करने के लिए, patch एंडपॉइंट का इस्तेमाल करें.

patch एंडपॉइंट, अनुरोध यूआरएल में दिए गए आइडेंटिफ़ायर के आधार पर, मौजूदा रिकॉर्ड को अपडेट करता है. पहले से जोड़े गए डेटा पॉइंट का आइडेंटिफ़ायर डालें. API, मौजूदा रिकॉर्ड को ओवरराइट कर देता है.

डेटा पॉइंट के इंटरवल टाइमस्टैंप (startTime और endTime) को भी अपडेट किया जा सकता है. ऐसा रिकॉर्ड का मालिक कर सकता है. इसके अलावा, इन्हें Health Connect जैसे अपस्ट्रीम प्लैटफ़ॉर्म से भी अपडेट किया जा सकता है. टाइमस्टैंप में बदलाव करने के बारे में ज़्यादा जानने के लिए, डेटा मैनेजमेंट गाइड देखें. अपडेट इंटरवल के टाइमस्टैंप अपडेट करने का उदाहरण देखने के लिए, मौजूदा डेटा के लिए अपडेट इंटरवल के टाइमस्टैंप अपडेट करना लेख पढ़ें.

डेटा पॉइंट आइडेंटिफ़ायर का इस्तेमाल कब करना चाहिए

डेटा पॉइंट आइडेंटिफ़ायर इन स्थितियों में ज़रूरी होता है:

  • टारगेट किए गए अपडेट: किसी खास मेज़रमेंट को अपडेट करने के लिए, patch अनुरोध में उसका आइडेंटिफ़ायर दें.
  • मिटाना: आइडेंटिफ़ायर को बनाए रखने से, आपका ऐप्लिकेशन बाद में batchDelete एंडपॉइंट का इस्तेमाल करके रिकॉर्ड मिटा सकता है.

यहां एक उदाहरण दिया गया है, जिसमें कोई व्यक्ति "Scales R Us" कंपनी के "HumanScale" नाम के स्केल पर, शरीर में मौजूद फ़ैट की रीडिंग अपडेट करता है. उपयोगकर्ता के शरीर में वसा की नई रीडिंग 2026-03-10 के लिए 20% है:

अनुरोध

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 को अपडेट करने के लिए, डेटा पॉइंट के संसाधन यूआरआई को PATCH अनुरोध भेजें. किसी रिकॉर्ड के फ़ील्ड में बदलाव सिर्फ़ उसका ओरिजनल क्रिएटर या मालिक कर सकता है. ऐप्लिकेशन, उन डेटा पॉइंट में बदलाव नहीं कर सकते जिन्हें उन्होंने नहीं बनाया है.

टाइमस्टैंप में बदलाव करने की सुविधा, Health Connect से अपस्ट्रीम अपडेट, और कैश मेमोरी से जुड़ी जानकारी के बारे में जानने के लिए, डेटा मैनेजमेंट गाइड देखें.

यहां दिए गए उदाहरण में, मालिक के ऐप्लिकेशन को 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
      }
    }
  }
}

खाने का कोई आइटम लॉग करना

किसी खाने-पीने की चीज़ को लॉग करने के लिए, nutrition-log dataPoints एंडपॉइंट पर POST अनुरोध भेजें. अनुरोध के मुख्य हिस्से में, nutritionLog ऑब्जेक्ट वाला DataPoint शामिल होता है. ज़्यादा जानकारी के लिए, पोषण गाइड देखें.

उदाहरण के लिए:

अनुरोध

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"
    }
  }
}

उपयोगकर्ता का सेहत का डेटा मिटाना

उपयोगकर्ता के Fitbit ऐप्लिकेशन के डेटा की किसी ऐरे को मिटाने के लिए, batchDelete तरीके का इस्तेमाल करें.

यहां एक उदाहरण दिया गया है. इसमें किसी व्यक्ति ने पहले स्केल पर अपने बॉडी फ़ैट का डेटा रिकॉर्ड किया था, लेकिन अब उसे यह रिकॉर्ड मिटाना है. मांसपेशियों के शुरुआती और आखिरी छोर और गतिविधि की ओरिजनल जानकारी से 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 का एक मुख्य फ़ायदा यह है कि इससे किसी व्यक्ति की परफ़ॉर्मेंस को ट्रैक किया जा सकता है. साथ ही, लंबे समय तक उसकी सेहत से जुड़ी ज़रूरी जानकारी पर नज़र रखी जा सकती है. उपयोगकर्ता के डेटा को तब तक क्वेरी किया जा सकता है, जब तक उसे रिकॉर्ड किया गया है. एपीआई, आपके ऐप्लिकेशन के इस्तेमाल किए जा सकने वाले पुराने डेटा की मात्रा पर कोई सीमा या पाबंदी नहीं लगाता है.

हालांकि, पुराने डेटा के लिए क्वेरी करने पर, अब भी स्टैंडर्ड रेट लिमिट लागू होती हैं. सिस्टम को स्थिर रखने और बहुत ज़्यादा पेलोड को रोकने के लिए, Google Health API एंडपॉइंट के हिसाब से पेज के साइज़ के साथ अपने-आप पेज नंबर डालने की सुविधा का इस्तेमाल करता है. इन बातों का ध्यान रखें:

  • अपने-आप पेज पर बांटने की सुविधा: अगर डेटा के लंबे स्पैन के लिए क्वेरी की जाती है, तो एपीआई सिर्फ़ उस एंडपॉइंट के लिए पेज के साइज़ की सीमा तक नतीजों का पहला पेज दिखाएगा. साथ ही, nextPageToken भी दिखाएगा. इसके बाद के पेजों का अनुरोध करने के लिए, आपको nextPageToken का इस्तेमाल करना होगा.
  • पेज के अलग-अलग साइज़: कैपिंग की सीमाएं, एंडपॉइंट और डेटा टाइप पर निर्भर करती हैं. ज़्यादातर डेटा टाइप के लिए, पेज का साइज़ ज़्यादा से ज़्यादा 10,000 तक सीमित होता है. हालांकि, कुछ डेटा टाइप, जैसे कि exercise और sleep के लिए, डिफ़ॉल्ट और ज़्यादा से ज़्यादा पेज साइज़ 25 पर सेट होता है. उदाहरण के लिए, अगर कोई क्लाइंट पिछले 10 सालों का नींद से जुड़ा सारा डेटा मांगता है, तो एपीआई पहले पेज पर सिर्फ़ 25 स्लीप सेशन दिखाएगा.
  • डेटा रोलअप करने की तारीख की सीमा से जुड़ी पाबंदियां: डेटा रोलअप और एग्रीगेशन एंडपॉइंट (जैसे, rollUp और dailyRollUp) के लिए, क्वेरी की तारीख की सीमाओं पर पाबंदियां लगाई जाती हैं. ये पाबंदियां, डेटा टाइप के आधार पर लगाई जाती हैं:
    • calories-in-heart-rate-zone, heart-rate, active-minutes, और total-calories के लिए, ज़्यादा से ज़्यादा 14 दिनों की सीमा.
    • रोलअप किए गए अन्य सभी डेटा टाइप के लिए, ज़्यादा से ज़्यादा 90 दिनों की सीमा.

आपके ऐप्लिकेशन को जितने पुराने डेटा की ज़रूरत है उसके हिसाब से, पूरे डेटासेट को वापस पाने के लिए, आपको पेजों को क्रम से बांटना होगा. अपने ऐप्लिकेशन के डेटा को सिंक करने की प्रोसेस डिज़ाइन करते समय, इस बात का ध्यान रखें.

बेहतर परफ़ॉर्मेंस पाने और एपीआई से जुड़ी गड़बड़ियों से बचने के लिए, पुराने डेटा को क्वेरी करते समय इन दिशा-निर्देशों का पालन करें:

फ़ेज़ के हिसाब से डेटा सिंक करना (हॉट वर्सेस कोल्ड लोड)

  • शुरुआती "हॉट" लोड: प्राइमरी लोड सीक्वेंस के दौरान, सिर्फ़ पिछले 7 से 14 दिनों का डेटा फ़ेच और रेंडर करें. इससे यह पक्का होता है कि उपयोगकर्ताओं को डेटा तुरंत दिखे. इसके लिए, उन्हें लंबी अवधि तक चलने वाली क्वेरी का इंतज़ार न करना पड़े.
  • बैकग्राउंड में "कोल्ड" लोड: प्राइमरी यूज़र इंटरफ़ेस (यूआई) रेंडर होने के बाद, पुराने डेटा को एसिंक्रोनस, कम प्राथमिकता वाली कतार या बैकग्राउंड प्रोसेस में भेजें.

एग्रीगेशन के लिए क्वेरी को हिस्सों में बांटना

  • रोलअप और रोज़ाना के रोलअप एंडपॉइंट, तारीख की ज़्यादा से ज़्यादा सीमा लागू करते हैं. यह सीमा, डेटा टाइप के हिसाब से 14 या 90 दिन होती है. इसलिए, आपको इतिहास के बड़े एग्रीगेशन क्वेरी को इन सीमाओं के अंदर, छोटे-छोटे क्रमवार इंटरवल में बांटना होगा.
  • इन सब-क्वेरी को सुरक्षित तरीके से बैच या क्रम में लगाएं, ताकि एक साथ कई अनुरोध करने की सीमा का पालन किया जा सके और यूज़र इंटरफ़ेस (यूआई) पर प्रोग्रेस इंडिकेटर को स्थिर रखा जा सके.

पहले से एग्रीगेट किए गए रोल-अप का इस्तेमाल करना

खास जानकारी वाले डैशबोर्ड और रुझान चार्ट को फिर से व्यवस्थित करें, ताकि पहले से एग्रीगेट किए गए डेटा और खास जानकारी वाले एंडपॉइंट (जैसे, DailyRollUpDataPoints) का इस्तेमाल किया जा सके. इससे बैकएंड पर कंप्यूटिंग का ओवरहेड और क्लाइंट को डेटा ट्रांसफ़र करने में लगने वाला समय काफ़ी कम हो जाएगा.

गड़बड़ी ठीक करने की बेहतर सुविधा (स्मार्ट तरीके से फिर से कोशिश करना)

  • दर की सीमाओं (429 Too Many Requests) और सर्वर गेटवे टाइमआउट (504 Gateway Timeout) का सामना करते समय, एक्सपोनेन्शियल बैकऑफ़ को सख्ती से लागू करें. बड़े और फ़ेल हो चुके पेलोड को तुरंत फिर से भेजने की कोशिश न करें. तुरंत फिर से कोशिश करने से, बैकएंड पर ज़्यादा लोड पड़ता है और सिस्टम की परफ़ॉर्मेंस खराब होती है.