מינויים ל-webhook

‫Google Health API מאפשר לאפליקציה שלכם לקבל התראות בזמן אמת כשנתוני בריאות וכושר של המשתמש משתנים. במקום לבצע בדיקות חוזרות כדי לראות אם יש שינויים, השרת שלכם מקבל בקשת HTTPS POST (webhook){:target="_blank" class="external"} ברגע שהנתונים זמינים ב-Google Health API.

סוגי נתונים נתמכים

יש תמיכה בהתראות של Webhook לסוגי הנתונים הבאים:

  • דקות טווח דופק
  • רמת הפעילות
  • גובה
  • סוכר בדם
  • שומן בגוף
  • קלוריות בטווח הדופק
  • שונות קצב הלב היומית
  • טווח הדופק היומי
  • רמת החמצן בדם (סטורציה) מדי יום
  • קצב נשימה יומי
  • הדופק היומי במנוחה
  • נתונים יומיים שנגזרים מטמפרטורת השינה
  • מרחק
  • פעילות גופנית
  • קומות
  • דופק
  • שונות קצב הלב
  • גובה
  • יומן מאזן הנוזלים
  • יומן תזונה
  • סיכום השינה של קצב הנשימה
  • הרצת נתוני צריכת החמצן המרבית (VO2 max)
  • תקופה של חוסר פעילות
  • שינה
  • שלבים
  • זמן בטווח הדופק
  • משקל

ההתראות נשלחות לגבי סוגי הנתונים האלה רק אם המשתמש הביע הסכמה לאחד מההיקפים המתאימים:

  • פעילות, שכוללת את סוגי הנתונים הבאים: צעדים, גובה, מרחק וקומות:
    • https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly
    • https://www.googleapis.com/auth/googlehealth.activity_and_fitness.writeonly
  • מדדי בריאות, שכוללים את סוג הנתונים של משקל:
    • https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.readonly
    • https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.writeonly
  • שינה, שכולל את סוג הנתונים של השינה:
    • https://www.googleapis.com/auth/googlehealth.sleep.readonly
    • https://www.googleapis.com/auth/googlehealth.sleep.writeonly

חשבונות שירות ב-IAM

לא חובה, אבל מומלץ להשתמש בחשבון שירות של IAM כשמגדירים מנויים ל-Google Health API. חשבונות שירות מספקים אבטחה טובה יותר לעומסי עבודה של אפליקציות בהשוואה לחשבונות משתמשים רגילים, באמצעות התכונות הבאות:

  • פרטי כניסה אוטומטיים לטווח קצר: כשמצרפים חשבונות שירות לסביבת ביצוע של Google Cloud (כמו Compute Engine,‏ Cloud Run או Google Kubernetes Engine), הם מקבלים באופן אוטומטי פרטי כניסה מאובטחים לטווח קצר ומבצעים רוטציה שלהם. כך נמנעים הסיכונים שקשורים לניהול ולאחסון של מפתחות סטטיים קבועים.
  • העיקרון של הרשאות מינימליות: חשבונות שירות מספקים זהויות ייעודיות לעומסי עבודה. אתם יכולים להעניק להם רק את ההרשאות הספציפיות שנדרשות לניהול נקודות קצה של מנויים, וכך למנוע גישה רחבה יותר למשאבי Google Cloud.
  • מחזור חיים עצמאי: חשבונות שירות פועלים באופן עצמאי מחשבון של משתמש ספציפי, וכך שינויים בכוח האדם לא משפיעים על יציבות האימות לטווח ארוך.

הגדרה של חשבון שירות

כדי להגדיר את אפליקציית המנוי כך שתבצע אימות באמצעות חשבון שירות:

  1. יצירת חשבון שירות: במסוף Google Cloud, עוברים לדף IAM & Admin של הפרויקט כדי ליצור חשבון שירות חדש בניהול המשתמשים.
  2. הקצאת תפקידי IAM נדרשים: מקצים לחשבון השירות את התפקידים המתאימים שנדרשים לניהול מנויים בפרויקט בענן של Google.
  3. מצרפים את חשבון השירות לעומס העבודה: מגדירים את סביבת האירוח של לוגיקת המנויים כך שתפעל כחשבון השירות החדש. כך קוד האפליקציה (למשל ספריות הלקוח של Google API) יכול לזהות באופן אוטומטי את פרטי הכניסה לטווח קצר של חשבון השירות ולהשתמש בהם כשמתבצעת קריאה ל-projects.subscribers REST API.

תפקידים ב-CPE

כדי לנהל מנויים או מינויים ל-Google Health API, צריך להקצות את התפקיד המתאים לחשבון השירות שמבצע את קריאות ה-API. בהתאם לרמת הגישה הנדרשת, מקצים אחד מהתפקידים הבאים:

  • Google Health API Read
  • Google Health API Editor
  • Google Health API Admin

מידע נוסף על תפקידים והרשאות ב-Google Health API IAM

ניהול המנויים

כדי לקבל התראות, צריך לרשום מנוי שמייצג את נקודת הקצה של ההתראות באפליקציה. אפשר לנהל את המנויים באמצעות ה-API בארכיטקטורת REST שזמין בכתובת projects.subscribers.

נקודת הקצה של המנויים חייבת להשתמש ב-HTTPS ‏ (TLSv1.2 ומעלה) ולכולם צריכה להיות גישה אליה. במהלך יצירה ועדכונים של מנויים, Google Health API מבצע אתגר אימות כדי לוודא שאתם הבעלים של ה-URI של נקודת הקצה. אם האימות נכשל, פעולות היצירה והעדכון של המינויים נכשלות עם שגיאה FailedPreconditionException.

יצירת מינוי

כדי לרשום מנוי חדש לפרויקט, משתמשים בנקודת הקצה create. תצטרכו לספק:

  • ‫project-id: מספר הפרויקט שבו נוצר חשבון השירות של ה-webhook.
  • ‫subscriberId: מזהה ייחודי שאתם מספקים למנוי. המזהה הזה צריך לכלול בין 4 ל-36 תווים, ולהתאים לביטוי הרגולרי ([a-z]([a-z0-9-]{2,34}[a-z0-9])).
  • ‫endpointUri: כתובת היעד של התראות ה-webhook.
  • ‫subscriberConfigs: סוגי הנתונים שרוצים לקבל עליהם התראות, ומדיניות המינוי לכל אחד מהם.
  • ‫endpointAuthorization: מנגנון ההרשאה של נקודת הקצה. הפרמטר הזה חייב להכיל את הערך secret שאתם מספקים. הערך של secret נשלח בכותרת Authorization עם כל הודעת התראה. אפשר להשתמש באסימון הזה כדי לוודא שהבקשות הנכנסות מגיעות מ-Google Health API. לדוגמה, אפשר להגדיר את secret ל-Bearer R4nd0m5tr1ng123 לאימות Bearer, או ל-Basic dXNlcjpwYXNzd29yZA== לאימות בסיסי.

ב-subscriberConfigs צריך להגדיר את subscriptionCreatePolicy לכל סוג נתונים. מגדירים את הערך ל-AUTOMATIC כדי להשתמש במינויים אוטומטיים, או ל-MANUAL אם אתם מתכוונים לנהל את מינויי המשתמשים בעצמכם. לפרטים נוספים על כל אפשרות, אפשר לעיין במאמרים בנושא מינויים אוטומטיים ומינויים ידניים.

בקשה

POST https://health.googleapis.com/v4/projects/project-id/subscribers?subscriberId=subscriber-id
{
  "endpointUri": "https://myapp.com/webhooks/health",
  "subscriberConfigs": [
    {
      "dataTypes": ["steps", "altitude", "distance", "floors", "weight"],
      "subscriptionCreatePolicy": "AUTOMATIC"
    },
    {
      "dataTypes": ["sleep"],
      "subscriptionCreatePolicy": "MANUAL"
    }
  ],
  "endpointAuthorization": {
    "secret": "Bearer example-secret-token"
  }
}

תשובה

{
  "name": "projects/project-id/subscribers/subscriber-id",
  "endpointUri": "https://myapp.com/webhooks/health",
  "subscriberConfigs": [
    {
      "dataTypes": ["steps", "altitude", "distance", "floors", "weight"],
      "subscriptionCreatePolicy": "AUTOMATIC"
    },
    {
      "dataTypes": ["sleep"],
      "subscriptionCreatePolicy": "MANUAL"
    }
  ]
}

הצגת רשימת המנויים

אפשר להשתמש בנקודת הקצה list כדי לאחזר את כל המנויים שרשומים לפרויקט.

בקשה

GET https://health.googleapis.com/v4/projects/project-id/subscribers

תשובה

{
  "subscribers": [
    {
      "name": "projects/project-id/subscribers/subscriber-id",
      "endpointUri": "https://myapp.com/webhooks/health",
      "subscriberConfigs": [
        {
          "dataTypes": ["steps", "altitude", "distance", "floors", "weight"],
          "subscriptionCreatePolicy": "AUTOMATIC"
        },
        {
          "dataTypes": ["sleep"],
          "subscriptionCreatePolicy": "MANUAL"
        }
      ],
      "endpointAuthorization": {
        "authorizationTokenSet": true
      }
    }
  ],
  "totalSize": 1
}

עדכון מנוי

משתמשים בנקודת הקצה patch כדי לעדכן מנוי בפרויקט. השדות שאפשר לעדכן הם endpointUri, subscriberConfigs ו-endpointAuthorization.

כדי לעדכן שדות, צריך לספק updateMask פרמטר שאילתה וגוף בקשה. הפרמטר updateMask צריך להכיל רשימה מופרדת בפסיקים של שמות השדות שרוצים לעדכן, תוך שימוש בשיטת Camel Case לשמות השדות (לדוגמה, endpointUri). גוף הבקשה צריך להכיל אובייקט Subscriber חלקי עם הערכים החדשים של השדות שרוצים לעדכן. רק השדות שצוינו ב-updateMask מתעדכנים. אם תספקו שדות בגוף הבקשה שלא מופיעים ב-updateMask, המערכת תתעלם מהם.

אם מעדכנים את endpointUri או את endpointAuthorization, מתבצע אימות של נקודות קצה. פרטים נוספים זמינים במאמר בנושא אימות של נקודות קצה.

כשמעדכנים את subscriberConfigs, חשוב לזכור שמדובר בהחלפה מלאה, ולא במיזוג. אם subscriberConfigs נכלל ב-updateMask, כל ההגדרות האישיות שמאוחסנות עבור המנוי הזה נדרסות על ידי הרשימה שמופיעה בגוף הבקשה. כדי להוסיף או להסיר הגדרה, צריך לספק את כל ההגדרות. אם אתם מעדכנים שדות אחרים ורוצים לשמור על ההגדרות הנוכחיות, אל תכללו את subscriberConfigs ב-updateMask.

בקשה

PATCH https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id?updateMask=endpointUri
{
  "endpointUri": "https://myapp.com/new-webhooks/health"
}

תשובה

{
  "name": "projects/project-id/subscribers/subscriber-id",
  "endpointUri": "https://myapp.com/new-webhooks/health",
  "subscriberConfigs": [
    {
      "dataTypes": ["steps", "altitude", "distance", "floors", "weight"],
      "subscriptionCreatePolicy": "AUTOMATIC"
    },
    {
      "dataTypes": ["sleep"],
      "subscriptionCreatePolicy": "MANUAL"
    }
  ]
}

מחיקת מנוי

כדי להסיר מנוי מהפרויקט, משתמשים בנקודת הקצה delete. אחרי המחיקה, המנוי לא יקבל יותר התראות.

בקשה

DELETE https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id

תשובה

אם המחיקה בוצעה בהצלחה, מוחזר גוף תגובה ריק עם סטטוס HTTP ‏ `200 OK`. 
{}

אימות של נקודות קצה

כדי להבטיח את האבטחה והמהימנות של מסירת ההתראות, Google Health API מבצע תהליך אימות דו-שלבי מחייב בכל פעם שיוצרים מנוי או מעדכנים את הגדרות נקודת הקצה שלו (endpointUri או endpointAuthorization). התהליך הזה מתבצע באופן סינכרוני במהלך קריאה ל-API. השירות שולח שתי בקשות POST אוטומטיות ל-URI של נקודת הקצה, באמצעות User-Agent‏ Google-Health-API-Webhooks-Verifier, עם גוף JSON‏ {"type": "verification"}.

  • לחיצת יד מאושרת: הבקשה הראשונה נשלחת עם הכותרת Authorization שהגדרתם. השרת צריך להגיב עם סטטוס 200 OK או 201 Created.
  • אתגר לא מורשה: הבקשה השנייה נשלחת ללא פרטי כניסה. השרת צריך להגיב עם סטטוס 401 Unauthorized או 403 Forbidden.

הלחיצת יד הזו מאשרת שנקודת הקצה פעילה ומאכפת את האבטחה בצורה נכונה. אם אחד מהשלבים נכשל, בקשת ה-API נכשלת ומוצגת השגיאה FAILED_PRECONDITION. רק אחרי שהלחיצת יד הזו מצליחה, המנוי שלכם נשמר ומופעל כדי לקבל התראות על נתוני בריאות וכושר.

רוטציית מפתחות

אם אתם צריכים לסובב מפתחות ל-endpointAuthorization, אתם יכולים לפעול לפי השלבים הבאים:

  1. מגדירים את נקודת הקצה כך שתקבל גם את הערכים הישנים וגם את הערכים החדשים של endpointAuthorization.
  2. מעדכנים את הגדרות המנוי עם הערך החדש endpointAuthorization באמצעות בקשת patch עם ?updateMask=endpointAuthorization.
  3. מגדירים את נקודת הקצה כך שתקבל רק ערך חדש של endpointAuthorization אחרי שמוודאים ששלב 2 בוצע בהצלחה.

מינויים של משתמשים

‫Google Health API עוזר לכם לנהל את מינויי המשתמשים ביעילות, וכך מצמצם את הצורך ברישום ידני במהלך צירוף משתמשים.

מינויים אוטומטיים

מומלץ להשתמש במינויים אוטומטיים. כדי להפעיל את התכונה הזו, צריך להגדיר את subscriptionCreatePolicy לערך AUTOMATIC ב-subscriberConfigs עבור סוגי הנתונים הספציפיים. הנתונים שאתם מציינים במדיניות dataTypes הם אותם סוגי נתונים ש-Google Health API שולח לגביהם התראות, בתנאי שהמשתמשים גם נתנו הסכמה מהמשתמש לגבי סוגי הנתונים האלה.AUTOMATIC

כשמשתמש מעניק לאפליקציה הסכמה להיקפי הרשאות שתואמים לסוגי נתונים עם מדיניות AUTOMATIC, Google Health API עוקב באופן אוטומטי אחרי סוגי הנתונים שנובעים מהחיתוך בין סוגי הנתונים שהמשתמש הסכים לשתף לבין סוגי הנתונים של הגדרת המנוי האוטומטית של אותו משתמש, ושולח התראות לגביהם. לאחר מכן, המערכת שולחת התראות לנקודת הקצה שלכם בכל פעם שהמשתמש הזה יוצר נתונים חדשים מהסוגים האלה. האפשרות הזו מתאימה למשתמשים שמביעים הסכמה לפני או אחרי שיוצרים את המינוי. לא מתבצעת השלמת חוסר בנתונים (data backfill) לגבי נתונים שנוצרו לפני יצירת המנוי.

אם משתמש מבטל את ההסכמה, ההתראות לגבי סוגי הנתונים התואמים יפסיקו. מינויים אוטומטיים מנוהלים על ידי Google ואי אפשר להציג אותם או למחוק אותם בנפרד. הם מוסרים רק כשמוחקים את המינוי הראשי.

מינויים ידניים

אם הגדרתם את המנוי שלכם ל-MANUAL subscription_create_policy עבור סוגי נתונים ספציפיים, אתם צריכים ליצור ולנהל מנויים באופן מפורש לכל משתמש. מינוי מקשר משתמש ספציפי לנקודת הקצה של המינויים שלכם עבור קבוצה מוגדרת של סוגי נתונים. מפתחים יכולים להשתמש בממשקי API ספציפיים כדי:

  • יצירה (ידנית) של מינויים לכל healthUserId – יצירת מינוי חדש למשתמש ספציפי. כדי להשתמש בשיטה הזו, המנוי צריך להגדיר את SubscriptionCreatePolicy לערך MANUAL עבור סוגי הנתונים המבוקשים.
  • עדכון (ידני) של מינוי – עדכון של סוגי הנתונים של מינוי קיים של משתמש.
  • מחיקת מינוי (ידנית) – מחיקת מינוי של משתמש ספציפי. אחרי המחיקה, נקודת הקצה של המנוי לא תקבל יותר התראות לגבי המשתמש הזה עבור סוגי הנתונים המשויכים.
  • רשימת מינויים (ידנית) – רשימה של כל המינויים הפעילים של מנוי מסוים. אפשר לסנן את התוצאות לפי משתמש או סוג נתונים.

התראות

כשנתונים של משתמש משתנים עבור סוג נתונים שהמשתמש נרשם לקבלת עדכונים לגביו, Google Health API שולח בקשת HTTPS POST לכתובת ה-URL של נקודת הקצה של המשתמש.

פורמט ההתראות

המטען הייעודי של ההתראה הוא אובייקט JSON שמכיל פרטים על שינוי הנתונים. הנתונים האלה כוללים את מזהה המשתמש, סוג הנתונים ומרווחי הזמן, ואפשר להשתמש בהם כדי להריץ שאילתה על הנתונים המעודכנים.

{
  "data": {
    "version": "1",
    "clientProvidedSubscriptionName": "subscription-name",
    "healthUserId": "health-user-id",
    "operation": "UPSERT",
    "dataType": "steps",
    "intervals": [
      {
        "physicalTimeInterval": {
          "startTime": "2026-03-08T01:29:00Z",
          "endTime": "2026-03-08T01:34:00Z"
        },
        "civilDateTimeInterval": {
          "startDateTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 7
            },
            "time": {
              "hours": 17,
              "minutes": 29
            }
          },
          "endDateTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 7
            },
            "time": {
              "hours": 17,
              "minutes": 34
            }
          }
        },
        "civilIso8601TimeInterval": {
          "startTime": "2026-03-07T17:29:00",
          "endTime": "2026-03-07T17:34:00"
        }
      }
    ]
  }
}

השדה operation מציין את סוג השינוי שהפעיל את ההתראה:

  • ‫UPSERT: נשלח בכל פעם שמוסיפים נתונים או משנים אותם.
  • ‫DELETE: נשלח כשמשתמש מוחק נתונים.

מומלץ להגדיר את הלוגיקה לטיפול בהתראות כאידמפוטנטית, במיוחד עבור פעולות UPSERT, כי ניסיונות חוזרים יכולים לגרום לשליחת התראות כפולות.

השדה clientProvidedSubscriptionName הוא מזהה ייחודי. למינויים עם מדיניות MANUAL, השדה הזה מכיל את שם המינוי הקבוע שסופק על ידי המפתח והוגדר כשנוצר המינוי. כך מתקבל מזהה יציב לניהול מינויים ידניים. למינויים שנוצרו עם מדיניות AUTOMATIC, Google Health API יוצר ומקצה באופן אוטומטי מזהה ייחודי (UUID אקראי) לשדה הזה לכל התראה. הכללת clientProvidedSubscriptionName במדיניות ידנית ובמדיניות אוטומטית מבטיחה פורמט עקבי של מטען ייעודי (Payload) של התראות בכל סוגי המינויים.

‫healthUserId הוא מזהה של Google Health API עבור המשתמש שהנתונים שלו השתנו. אם האפליקציה שלכם תומכת במספר משתמשים, יכול להיות שתקבלו התראות על כל משתמש שהעניק לאפליקציה שלכם הסכמה. כשמקבלים התראה, משתמשים ב-healthUserId כדי לזהות את הנתונים של איזה משתמש השתנו, כדי שאפשר יהיה להשתמש בפרטי הכניסה שלו ל-OAuth כדי לשלוח שאילתה לגבי הנתונים שלו.

כדי למפות את פרטי הכניסה של משתמש ב-OAuth ל-healthUserId שלו, משתמשים בנקודת הקצה getIdentity. מתקשרים לנקודת הקצה הזו עם פרטי הכניסה של המשתמש במהלך צירוף המשתמש כדי לאחזר את healthUserId שלו, ושומרים את המיפוי הזה. המיפוי הזה לא משתנה עם הזמן, ולכן אפשר לשמור אותו במטמון ללא הגבלת זמן. דוגמה מופיעה במאמר בנושא קבלת מזהה משתמש. כך תוכלו לבחור את פרטי הכניסה הנכונים של המשתמש כשאתם שולחים שאילתות לנתונים על סמך healthUserId בהתראה.

איך משיבים להתראות

השרת שלכם חייב להגיב להתראות באופן מיידי עם קוד סטטוס 204 No Content של HTTP. כדי למנוע זמן קצוב לתפוגה, צריך לעבד את מטען ייעודי (payload) של ההתראה באופן אסינכרוני אחרי שליחת התשובה. אם Google Health API מקבל קוד סטטוס אחר או שהבקשה נכשלת בגלל פסק זמן, המערכת מנסה לשלוח את ההתראה שוב מאוחר יותר.

דוגמה ל-Node.js ‏ (Express):

app.post('/webhook-receiver', (req, res) => {
    // 1. Immediately acknowledge the notification
    res.status(204).send();

    // 2. Process the data asynchronously in the background
    const notification = req.body;
    setImmediate(() => {
        console.log(`Update for user ${notification.data.healthUserId} of type ${notification.data.dataType}`);
        // Trigger your data retrieval logic here
    });
});

שיטות מומלצות

כדי להבטיח טיפול מהימן ויעיל בעדכוני נתונים, מומלץ לפעול לפי השיטות המומלצות הבאות:

  • שימוש ב-Subscription API: אפשר להשתמש ב-Subscription API כדי לקבל הודעה כשיש למשתמש נתונים חדשים להורדה, במקום לבצע סקר של נקודות קצה.
  • הוספה לתור ועיבוד של התראות בנפרד: כשמקבלים התראות על מינוי, מוסיפים אותן לתור ומעבדים אותן בנפרד על סמך המשאבים של המערכת. כדי לשמור על נקודת הקצה של ה-webhook קלה ככל האפשר, צריך לאשר את הבקשה באופן מיידי.

אימות חתימה

כדי לוודא את האותנטיות של התראות Webhook, מטען ה-JSON הגולמי של כל התראות ה-Webhook היוצאות נחתם באמצעות מפתח פרטי באמצעות PublicKeySign של Tink, ומספק את החתימה עם קידוד Base64 בכותרת ה-HTTP ‏GOOGLE-HEALTH-API-SIGNATURE בבקשה. מפתחות החתימה האלה עוברים רוטציה אוטומטית כל 30 יום, וקבוצת המפתחות הציבוריים הרשמית התואמת מופצת כקובץ JSON בכתובת ה-URL הקבועה https://www.gstatic.com/googlehealthapi/webhooks/webhooks_public_keyset.json.

איך מאמתים את החתימה

שימוש ב-Tink (מומלץ): מפתחים יכולים לאמת את החתימה באמצעות הפרימיטיב PublicKeyVerify של Tink. מאחזרים את קבוצת המפתחות הציבוריים מכתובת ה-URL הקבועה, יוצרים מופע של הפרימיטיב PublicKeyVerify עם קבוצת המפתחות ומאמתים את הכותרת GOOGLE-HEALTH-API-SIGNATURE שפוענחה מול מטען ה-JSON הייעודי הגולמי של ה-webhook.

אימות ידני (ללא Tink): אם מפתחים בוחרים לא להשתמש ב-Tink, הם יכולים לאמת את החתימה באופן ידני לפי השלבים הבאים:

  1. מפענחים את הכותרת GOOGLE-HEALTH-API-SIGNATURE מקידוד base64 כדי להפריד את התחילית של Tink באורך 5 בייט (שמכילה תחילית גרסה באורך בייט אחד ומזהה מפתח באורך 4 בייט) מהחתימה בפועל בקידוד DER.
  2. מאחזרים את קבוצת המפתחות של ה-JSON מהכתובת https://www.gstatic.com/googlehealthapi/webhooks/webhooks_public_keyset.json.
  3. מאתרים את המפתח שתואם ל-keyId שנותח ומבצעים פענוח Base64 של שדה הערך שלו, שמכיל מאגר פרוטוקול EcdsaPublicKey שעבר סריאליזציה.
  4. תחלצו את הקואורדינטות x ו-y בפורמט big-endian (תגי Protobuf‏ 3 ו-4) ממטען הנתונים הבינארי הזה.
  5. יוצרים מופע של מפתח ציבורי רגיל מסוג ECDSA P-256 בספריית קריפטוגרפיה מובנית באמצעות קואורדינטות x ו-y שחולצו.
  6. מאמתים את המטען הייעודי (payload) של ה-webhook בפורמט JSON גולמי מול חתימת ה-DER שחולצה באמצעות אלגוריתם SHA-256.

סטטוס המנוי ושחזור

אם נקודת הקצה של המנוי לא זמינה או מחזירה קוד סטטוס של שגיאה (כל קוד אחר מלבד 204), Google Health API מאחסן התראות בהמתנה למשך עד 7 ימים ומנסה שוב לשלוח אותן עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).

אחרי שנקודת הקצה חוזרת למצב אונליין ומגיבה עם 204, ה-API מעביר אוטומטית את ההודעות שהצטברו בתור. התראות שנוצרו לפני יותר מ-7 ימים נמחקות ולא ניתן לשחזר אותן.

שגיאות נפוצות

קוד שגיאה שליחת הודעה תיאור המלצה
‫400 בקשה שגויה מספר הפרויקט בשם המשאב לא תקין כשמוחקים או מעדכנים אפליקציה רשומה באמצעות מזהה הפרויקט בענן בכתובת ה-URL של הבקשה במקום מספר הפרויקט. ההגדרה הזו חלה על מינויים ל-webhook באמצעות נקודת הקצה projects.subscribers. משתמשים במספר הפרויקט ב-Google Cloud בכתובת ה-URL של הבקשה, ולא במזהה הפרויקט.
‫403 Forbidden למתקשר אין הרשאה כשיוצרים או מציגים רשימה של מנויים באמצעות מזהה הפרויקט ב-Google Cloud בכתובת ה-URL של הבקשה במקום מספר הפרויקט. ההגדרה הזו חלה על מינויים ל-webhook באמצעות נקודת הקצה projects.subscribers. משתמשים במספר הפרויקט ב-Google Cloud בכתובת ה-URL של הבקשה, ולא במזהה הפרויקט.

הקודם
קישורים אוניברסליים וקישורים לאפליקציה
הבא
פתרון בעיות