Subskrypcje webhooków

Interfejs Google Health API umożliwia aplikacji otrzymywanie powiadomień w czasie rzeczywistym o zmianach danych dotyczących zdrowia użytkownika. Zamiast sprawdzać zmiany, Twój serwer otrzymuje żądanie HTTPS POST webhook gdy tylko dane są dostępne w interfejsie Google Health API.

Obsługiwane typy danych

Powiadomienia webhook są obsługiwane w przypadku tych typów danych:

  • Aktywne minuty w strefie
  • Poziom aktywności
  • Wysokość
  • Glukoza we krwi
  • Tkanka tłuszczowa
  • Kalorie w strefie tętna
  • Dzienna zmienność rytmu serca
  • Dzienne strefy tętna
  • Dzienne nasycenie tlenem
  • Dzienna częstość oddychania
  • Dzienne tętno spoczynkowe
  • Dzienne pochodne temperatury podczas snu
  • Odległość
  • Ćwiczenia
  • Piętra
  • Tętno
  • Zmienność rytmu serca
  • Wysokość
  • Zapis nawodnienia
  • Dziennik odżywiania
  • Podsumowanie snu według częstości oddychania
  • Pułap tlenowy podczas biegu
  • Okres braku aktywności
  • Sen
  • Kroki
  • Czas w strefie tętna
  • Waga

Powiadomienia są wysyłane w przypadku tych typów danych tylko wtedy, gdy użytkownik wyraził zgodę na jeden z odpowiednich zakresów:

  • Aktywność, która obejmuje typy danych kroki, wysokość, odległość i piętra:
    • https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly
    • https://www.googleapis.com/auth/googlehealth.activity_and_fitness.writeonly
  • Wskaźniki zdrowotne, które obejmują typ danych waga:
    • https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.readonly
    • https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.writeonly
  • Sen, który obejmuje typ danych sen:
    • https://www.googleapis.com/auth/googlehealth.sleep.readonly
    • https://www.googleapis.com/auth/googlehealth.sleep.writeonly

Konta usługi używane przez Uprawnienia

Chociaż nie jest to wymagane, zalecamy używanie konta usługi używanego przez Uprawnienia podczas konfigurowania subskrybentów w interfejsie Google Health API. Konta usługi zapewniają większe bezpieczeństwo obciążeń aplikacji w porównaniu ze standardowymi kontami użytkowników dzięki tym funkcjom:

  • Automatyczne dane logowania o ograniczonym czasie ważności: gdy konto usługi jest powiązane ze środowiskiem wykonawczym Google Cloud (np. Compute Engine, Cloud Run lub Google Kubernetes Engine), automatycznie uzyskuje i rotuje bezpieczne dane logowania o ograniczonym czasie ważności. Eliminuje to ryzyko związane z zarządzaniem i przechowywaniem trwałych kluczy statycznych.
  • Zasada jak najmniejszych uprawnień: konta usługi zapewniają dedykowane tożsamości dla obciążeń. Możesz przyznać im tylko te uprawnienia, które są potrzebne do zarządzania punktami końcowymi subskrybentów, unikając szerszego dostępu do zasobów Google Cloud.
  • Niezależność cyklu życia: konta usługi działają niezależnie od konta użytkownika, dzięki czemu zmiany personelu nie wpływają na długoterminową stabilność uwierzytelniania.

Konfigurowanie konta usługi

Aby skonfigurować aplikację subskrybenta do uwierzytelniania za pomocą konta usługi:

  1. Utwórz konto usługi: w konsoli Google Cloud otwórz stronę Administracja projektu, aby utworzyć nowe konto usługi zarządzane przez użytkownika.
  2. Przyznaj niezbędne role uprawnień: przypisz kontu usługi odpowiednie role wymagane do zarządzania subskrybentami w projekcie w chmurze Google.
  3. Dołącz konto usługi do obciążenia: skonfiguruj środowisko hostujące logikę subskrybenta, aby działało jako nowe konto usługi. Umożliwi to kodowi aplikacji (np. bibliotekom klienta interfejsu API Google) automatyczne wykrywanie i używanie danych logowania o ograniczonym czasie ważności konta usługi podczas wywoływania interfejsu API REST projects.subscribers.

Role CPE

Aby zarządzać subskrybentami lub subskrypcjami interfejsu Google Health API, musisz przyznać odpowiednią rolę kontu usługi, które przejmuje tożsamość i wywołuje interfejsy API. W zależności od wymaganego poziomu dostępu przypisz jedną z tych ról:

  • Google Health API Read
  • Edytujący interfejs Google Health API
  • Administrator interfejsu Google Health API

Więcej informacji o rolach i uprawnieniach uprawnień interfejsu Google Health API.

Zarządzanie subskrybentami

Aby otrzymywać powiadomienia, musisz zarejestrować subskrybenta, który reprezentuje punkt końcowy powiadomień aplikacji. Subskrybentami możesz zarządzać za pomocą interfejsu API REST dostępnego pod adresem projects.subscribers.

Punkt końcowy subskrybenta musi używać protokołu HTTPS (TLSv1.2+) i być publicznie dostępny. Podczas tworzenia i aktualizowania subskrybenta interfejs Google Health API przeprowadza weryfikację, aby upewnić się, że jesteś właścicielem identyfikatora URI punktu końcowego. Jeśli weryfikacja się nie powiedzie, operacje tworzenia i aktualizowania subskrybenta zakończą się niepowodzeniem z powodu FailedPreconditionException.

Tworzenie subskrybenta

Aby zarejestrować nowego subskrybenta w projekcie, użyj create punktu końcowego. Musisz podać:

  • project-id: numer projektu, w którym utworzono konto usługi webhook.
  • subscriberId: unikalny identyfikator subskrybenta. Identyfikator musi mieć od 4 do 36 znaków i pasować do wyrażenia regularnego ([a-z]([a-z0-9-]{2,34}[a-z0-9])).
  • endpointUri: docelowy adres URL powiadomień webhook.
  • subscriberConfigs: typy danych, w przypadku których chcesz otrzymywać powiadomienia, oraz zasady subskrypcji dla każdego z nich.
  • endpointAuthorization: mechanizm autoryzacji punktu końcowego. Musi zawierać podany przez Ciebie secret. Wartość secret jest wysyłana w nagłówku Authorization z każdą wiadomością z powiadomieniem. Za pomocą tego tokena możesz sprawdzić, czy przychodzące żądania pochodzą z interfejsu Google Health API. Możesz na przykład ustawić secret na Bearer R4nd0m5tr1ng123 w przypadku uwierzytelniania za pomocą tokena Bearer lub Basic dXNlcjpwYXNzd29yZA== w przypadku uwierzytelniania podstawowego.

W subscriberConfigs musisz ustawić subscriptionCreatePolicy dla każdego typu danych. Ustaw wartość AUTOMATIC, aby używać automatycznych subskrypcji, lub MANUAL, jeśli chcesz samodzielnie zarządzać subskrypcjami użytkowników. Więcej informacji o każdej opcji znajdziesz w sekcjach Automatyczne subskrypcje i Ręczne subskrypcje.

Żądanie

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

Odpowiedź

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

Wyświetlanie listy subskrybentów

Aby pobrać wszystkich subskrybentów zarejestrowanych w projekcie, użyj punktu końcowego list.

Żądanie

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

Odpowiedź

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

Aktualizowanie subskrybenta

Aby zaktualizować subskrybenta w projekcie, użyj punktu końcowego patch. Pola, które można zaktualizować, to endpointUri, subscriberConfigs i endpointAuthorization.

Pola aktualizujesz, podając parametr zapytania updateMask i treść żądania. updateMask musi zawierać rozdzieloną przecinkami listę nazw pól, które chcesz zaktualizować. Nazwy pól muszą być zapisane w formacie camel case (np. endpointUri). Treść żądania musi zawierać częściowy obiekt subskrybenta z nowymi wartościami pól, które chcesz zaktualizować. Aktualizowane są tylko pola określone w updateMask. Jeśli w treści żądania podasz pola, których nie ma w updateMask, zostaną one zignorowane.

Jeśli zaktualizujesz endpointUri lub endpointAuthorization, zostanie przeprowadzona weryfikacja punktu końcowego. Więcej informacji znajdziesz w sekcji Weryfikacja punktów końcowych.

Podczas aktualizowania subscriberConfigs pamiętaj, że jest to pełne zastąpienie, a nie scalenie. Jeśli subscriberConfigs jest uwzględniony w updateMask, wszystkie zapisane konfiguracje tego subskrybenta zostaną zastąpione listą podaną w treści żądania. Aby dodać lub usunąć konfigurację, musisz podać pełny zestaw konfiguracji. Jeśli aktualizujesz inne pola i chcesz zachować bieżące konfiguracje, pomiń subscriberConfigs w updateMask.

Żądanie

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

Odpowiedź

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

Usuwanie subskrybenta

Aby usunąć subskrybenta z projektu, użyj punktu końcowego delete. Po usunięciu subskrybent nie będzie już otrzymywać powiadomień.

Żądanie

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

Odpowiedź

Jeśli usunięcie się powiedzie, zwracana jest pusta treść odpowiedzi z kodem stanu HTTP `200 OK`. 
{}

Weryfikacja punktów końcowych

Aby zapewnić bezpieczeństwo i niezawodność dostarczania powiadomień, interfejs Google Health API przeprowadza obowiązkową weryfikację dwuetapową za każdym razem, gdy tworzysz subskrybenta lub aktualizujesz jego konfigurację punktu końcowego (endpointUri lub endpointAuthorization). Ten proces jest wykonywany synchronicznie podczas wywołania interfejsu API. Usługa wysyła 2 automatyczne żądania POST do identyfikatora URI punktu końcowego, używając klienta użytkownika Google-Health-API-Webhooks, z treścią JSON {"type": "verification"}.

  • Autoryzowane uzgadnianie: pierwsze żądanie jest wysyłane ze skonfigurowanym Authorization nagłówkiem. Twój serwer musi odpowiedzieć kodem stanu 200 OK lub 201 Created.
  • Nieautoryzowane wyzwanie: drugie żądanie jest wysyłane bez danych logowania. Twój serwer musi odpowiedzieć kodem stanu 401 Unauthorized lub 403 Forbidden.

To uzgadnianie potwierdza, że punkt końcowy jest aktywny i prawidłowo egzekwuje zabezpieczenia. Jeśli którykolwiek z tych kroków się nie powiedzie, żądanie do interfejsu API zakończy się niepowodzeniem z powodu błędu FAILED_PRECONDITION. Dopiero po pomyślnym uzgodnieniu połączenia aplikacja subskrybująca zostanie zapisana i aktywowana do otrzymywania powiadomień o danych dotyczących zdrowia.

Rotacja kluczy

Jeśli musisz rotować klucze dla endpointAuthorization, wykonaj te czynności:

  1. Skonfiguruj punkt końcowy tak, aby akceptował zarówno stare, jak i nowe wartości endpointAuthorization.
  2. Zaktualizuj konfigurację subskrybenta o nową wartość endpointAuthorization, używając żądania patch z parametrem ?updateMask=endpointAuthorization.
  3. Po potwierdzeniu, że krok 2 się powiódł, skonfiguruj punkt końcowy tak, aby akceptował tylko nową wartość endpointAuthorization.

Subskrypcje użytkownika

Interfejs Google Health API pomaga efektywnie zarządzać subskrypcjami użytkowników, zmniejszając potrzebę ręcznej rejestracji podczas wdrażania użytkowników.

Automatyczne subskrypcje

Zalecamy używanie automatycznych subskrypcji. Aby włączyć tę funkcję, ustaw subscriptionCreatePolicy na AUTOMATIC w subscriberConfigs dla określonych typów danych. dataTypes określone za pomocą zasady AUTOMATIC to te same typy danych, w przypadku których interfejs Google Health API wysyła powiadomienia, pod warunkiem że zgoda użytkownika zostanie również udzielona na te typy danych.

Gdy użytkownik wyrazi zgodę na zakresy odpowiadające typom danych z zasadą AUTOMATIC, interfejs Google Health API automatycznie śledzi i wysyła powiadomienia o typach danych wynikających z przecięcia typów danych, na które użytkownik wyraził zgodę, oraz typów danych automatycznej konfiguracji subskrybenta dla tego użytkownika. Powiadomienia są następnie wysyłane do punktu końcowego, gdy tylko użytkownik wygeneruje nowe dane tych typów. Działa to w przypadku użytkowników, którzy wyrażą zgodę przed utworzeniem subskrybenta lub po jego utworzeniu. Powiadomienia nie są uzupełniane w przypadku danych wygenerowanych przed utworzeniem subskrybenta.

Jeśli użytkownik wycofa zgodę, powiadomienia o odpowiednich typach danych zostaną wstrzymane. Automatyczne subskrypcje są zarządzane przez Google i nie można ich wyświetlać ani usuwać pojedynczo. Są one usuwane tylko wtedy, gdy zostanie usunięty subskrybent nadrzędny.

Ręczne subskrypcje

Jeśli subskrybent jest skonfigurowany z zasadą subscription_create_policy ustawioną na `MANUAL` w przypadku określonych typów danych, musisz wyraźnie utworzyć subskrypcje dla każdego użytkownika i nimi zarządzać. Subskrypcja łączy konkretnego użytkownika z punktem końcowym subskrybenta w przypadku określonego zestawu typów danych. Deweloperzy mogą używać określonych interfejsów API do:

  • Tworzenia (ręcznych) subskrypcji na podstawie healthUserId – tworzy nową subskrypcję dla konkretnego użytkownika. Ta metoda wymaga, aby subskrybent miał ustawioną zasadę SubscriptionCreatePolicy na MANUAL w przypadku żądanych typów danych.
  • Aktualizowania (ręcznej) subskrypcji – aktualizuje typy danych w przypadku istniejącej subskrypcji użytkownika.
  • Usuwania (ręcznej) subskrypcji – usuwa konkretną subskrypcję użytkownika. Po usunięciu punkt końcowy subskrybenta nie będzie już otrzymywać powiadomień o powiązanych typach danych dla tego użytkownika.
  • Wyświetlania listy (ręcznych) subskrypcji – wyświetla listę wszystkich aktywnych subskrypcji danego subskrybenta. Wyniki możesz filtrować według użytkownika lub typu danych.

Powiadomienia

Gdy dane użytkownika zmienią się w przypadku subskrybowanego typu danych, interfejs Google Health API wysyła żądanie HTTPS POST na adres URL punktu końcowego subskrybenta.

Format powiadomienia

Ładunek powiadomienia to obiekt JSON zawierający szczegółowe informacje o zmianie danych. Obejmuje to identyfikator użytkownika, typ danych i przedziały czasu, których możesz użyć do wysyłania zapytań o zaktualizowane dane.

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

Pole operation wskazuje typ zmiany, która wywołała powiadomienie:

  • UPSERT: wysyłane w przypadku dodania lub zmodyfikowania danych.
  • DELETE: wysyłane, gdy użytkownik usunie dane.

Zalecamy, aby logika obsługi powiadomień była idempotentna, zwłaszcza w przypadku operacji UPSERT, ponieważ ponawianie prób może spowodować wysłanie zduplikowanych powiadomień.

Pole clientProvidedSubscriptionName to unikalny identyfikator. W przypadku subskrypcji z zasadą MANUAL to pole zawiera trwałą nazwę subskrypcji podaną przez dewelopera podczas tworzenia subskrypcji. Zapewnia to stabilny identyfikator do zarządzania ręcznymi subskrypcjami. W przypadku subskrypcji utworzonych z zasadą AUTOMATIC interfejs Google Health API automatycznie generuje i przypisuje unikalny identyfikator (losowy UUID) do tego pola w przypadku każdego powiadomienia. Uwzględnienie clientProvidedSubscriptionName w przypadku zasad ręcznych i automatycznych zapewnia spójny format ładunku powiadomienia we wszystkich typach subskrypcji.

healthUserId to identyfikator interfejsu Google Health API użytkownika, którego dane uległy zmianie. Jeśli Twoja aplikacja obsługuje wielu użytkowników, możesz otrzymywać powiadomienia od każdego użytkownika, który wyraził zgodę na korzystanie z aplikacji. Gdy otrzymasz powiadomienie, użyj healthUserId, aby określić, czyje dane uległy zmianie. Dzięki temu możesz użyć danych logowania OAuth do wysyłania zapytań o jego dane.

Aby zmapować dane logowania OAuth użytkownika na jego healthUserId, użyj punktu końcowego getIdentity. Podczas wdrażania użytkownika wywołaj ten punkt końcowy z danymi logowania użytkownika, aby pobrać jego healthUserId, i zapisz to mapowanie. To mapowanie nie zmienia się z upływem czasu, więc można je przechowywać w pamięci podręcznej bezterminowo. Przykład znajdziesz w sekcji Pobieranie identyfikatora użytkownika. Umożliwia to wybranie prawidłowych danych logowania użytkownika podczas wysyłania zapytań o dane na podstawie healthUserId w powiadomieniu.

Agregacja aktualizacji

Aby zminimalizować ruch w sieci, interfejs Google Health API łączy wiadomości w pakiety. System jest skonfigurowany tak, aby wysyłać maksymalnie 99 wiadomości w pakiecie, które są automatycznie wysyłane, gdy tylko staną się dostępne.

Podejmowanie działania w związku z powiadomieniem

Twój serwer musi natychmiast odpowiedzieć na powiadomienia kodem stanu HTTP 204 No Content. Aby uniknąć przekroczenia limitu czasu, przetwórz ładunek powiadomienia asynchronicznie po wysłaniu odpowiedzi. Jeśli interfejs Google Health API otrzyma inny kod stanu lub żądanie przekroczy limit czasu, ponowi próbę wysłania powiadomienia później.

Przykład w 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
    });
});

Istnieją 3 typowe strategie aktualizowania bazy danych po otrzymaniu powiadomienia o zmianie danych:

  • Kolejkowanie (zalecane): umieść przychodzące powiadomienia w kolejce wiadomości i przetwarzaj je na podstawie zasobów systemowych.
  • Natychmiastowe pobieranie: skieruj backend, aby natychmiast wywołał interfejs Google Health API w celu pobrania zaktualizowanych danych i zapisania ich w bazie danych.
  • Aktualizacje leniwe: oznacz rekordy lokalnej bazy danych użytkownika jako zmodyfikowane i pobierz zaktualizowane dane z interfejsu Google Health API dopiero wtedy, gdy użytkownik ponownie odwiedzi Twoją aplikację.

Strategia kolejkowania umożliwia przetwarzanie danych niemal w czasie rzeczywistym, a jednocześnie zapewnia odporność na zalew powiadomień (np. jeśli awaria usługi spowoduje, że zaległe powiadomienia zostaną dostarczone naraz). Aby oszczędzać zasoby, możesz przetwarzać te kolejki według harmonogramu wsadowego z długimi odstępami (np. co 3 godziny), ale wadą jest to, że użytkownicy zwykle oczekują, że ich dane będą aktualizowane niemal w czasie rzeczywistym.

Sprawdzone metody

Aby zapewnić niezawodną i wydajną obsługę aktualizacji danych, postępuj zgodnie z tymi sprawdzonymi metodami:

  • Używaj interfejsu Subscription API: używaj interfejsu Subscription API, aby otrzymywać powiadomienia gdy użytkownik ma nowe dane do pobrania, zamiast sprawdzać punkty końcowe.
  • Kolejkuj i przetwarzaj powiadomienia oddzielnie: gdy otrzymasz powiadomienia o subskrypcji, umieść je w kolejce i przetwarzaj oddzielnie na podstawie zasobów systemu. Utrzymuj lekkość punktu końcowego webhook, natychmiast potwierdzając żądanie.

Weryfikacja podpisu

Aby zapewnić autentyczność powiadomień webhook, surowy ładunek JSON każdego wychodzącego powiadomienia webhook jest podpisywany kluczem prywatnym za pomocą PublicKeySign z biblioteki Tink. Podpis zakodowany w formacie Base64 jest umieszczany w nagłówku HTTP GOOGLE-HEALTH-API-SIGNATURE w żądaniu. Te klucze podpisywania są automatycznie rotowane co 30 dni, a odpowiadający im oficjalny zestaw kluczy publicznych jest rozpowszechniany jako plik JSON pod stałym adresem URL https://www.gstatic.com/googlehealthapi/webhooks/webhooks_public_keyset.json.

Jak zweryfikować podpis

Używanie biblioteki Tink (zalecane): deweloperzy mogą weryfikować podpis za pomocą prymitywu PublicKeyVerify z biblioteki Tink. Pobierz zestaw kluczy publicznych ze stałego adresu URL, utwórz instancję prymitywu PublicKeyVerify z zestawem kluczy i zweryfikuj zdekodowany nagłówek GOOGLE-HEALTH-API-SIGNATURE z surowym ładunkiem JSON webhook.

Weryfikacja ręczna (bez biblioteki Tink): jeśli deweloperzy nie chcą używać biblioteki Tink, mogą ręcznie zweryfikować podpis, wykonując te czynności:

  1. Dekoduje nagłówek GOOGLE-HEALTH-API-SIGNATURE w formacie Base64, aby oddzielić 5-bajtowy prefiks Tink (który zawiera 1-bajtowy prefiks wersji i 4-bajtowy identyfikator klucza) od rzeczywistego podpisu zakodowanego w formacie DER.
  2. Pobierz zestaw kluczy JSON z adresu https://www.gstatic.com/googlehealthapi/webhooks/webhooks_public_keyset.json.
  3. Znajdź klucz pasujący do przeanalizowanego identyfikatora klucza i zdekoduj w formacie Base64 jego pole wartości, które zawiera zserializowany bufor protokołu EcdsaPublicKey.
  4. Wyodrębnij współrzędne x i y w formacie big-endian (tagi Protobuf 3 i 4) z tego ładunku binarnego.
  5. Utwórz instancję standardowego klucza publicznego ECDSA P-256 w wbudowanej bibliotece kryptograficznej za pomocą wyodrębnionych współrzędnych x i y.
  6. Zweryfikuj surowy ładunek JSON webhook z wyodrębnionym podpisem DER za pomocą algorytmu SHA-256.

Stan subskrybenta i odzyskiwanie

Jeśli punkt końcowy subskrybenta stanie się niedostępny lub zwróci kod stanu błędu (inny niż 204), interfejs Google Health API będzie przechowywać oczekujące powiadomienia przez maksymalnie 7 dni i ponawiać próby dostarczenia z wzrastającym czasem do ponowienia.

Gdy punkt końcowy znów będzie online i odpowie kodem 204, interfejs API automatycznie dostarczy zaległe zapisane wiadomości. Powiadomienia starsze niż 7 dni są odrzucane i nie można ich odzyskać.

Typowe błędy

Kod błędu Wiadomość Opis Rekomendacja
400 Nieprawidłowe żądanie Nieprawidłowy numer projektu w nazwie zasobu Podczas usuwania lub aktualizowania subskrybenta za pomocą identyfikatora projektu Google Cloud w adresie URL żądania zamiast numeru projektu. Dotyczy to subskrypcji webhook za pomocą punktu końcowego projects.subscribers. W adresie URL żądania użyj numeru projektu w chmurze Google, a nie identyfikatora projektu.
403 Dostęp zabroniony Wywołujący nie ma uprawnień Podczas tworzenia lub wyświetlania listy subskrybentów za pomocą identyfikatora projektu Google Cloud w adresie URL żądania zamiast numeru projektu. Dotyczy to subskrypcji webhook za pomocą punktu końcowego projects.subscribers. W adresie URL żądania użyj numeru projektu w chmurze Google, a nie identyfikatora projektu.

Wstecz
Linki uniwersalne i linki do aplikacji
Dalej
Rozwiązywanie problemów