एंडपॉइंट

इस पेज पर, 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"
}

हाइब्रिड केस

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

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

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

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

डेटा पॉइंट के इंटरवल टाइमस्टैंप (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
    }
  }
}

मौजूदा डेटा के लिए, अपडेट इंटरवल के टाइमस्टैंप

किसी मौजूदा डेटा पॉइंट के इंटरवल टाइमस्टैंप (REST JSON पेलोड में startTime और endTime या gRPC में start_time और end_time) अपडेट करने के लिए, डेटा पॉइंट के संसाधन यूआरआई को 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) का सामना करते समय, एक्सपोनेन्शियल बैकऑफ़ को सख्ती से लागू करें. बड़े और फ़ेल हो चुके पेलोड को तुरंत फिर से भेजने की कोशिश न करें. तुरंत फिर से कोशिश करने से, बैकएंड पर ज़्यादा लोड पड़ता है और सिस्टम की परफ़ॉर्मेंस खराब हो जाती है.
पीछे जाएं
क्लाइंट लाइब्रेरी
आगे बढ़ें
फ़िल्टर