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, serwer otrzymuje żądanie HTTPS POST (webhook){:target="_blank" class="external"} , 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 odchylenia temperatury podczas snu
  • Odległość
  • Ćwiczenia
  • Piętra
  • Tętno
  • Zmienność rytmu serca
  • Wysokość
  • Zapis nawodnienia
  • Dziennik odżywiania
  • Podsumowanie snu dotyczące 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 interfejsu Google Health API. Konta usługi zapewniają lepsze bezpieczeństwo zadań aplikacji w porównaniu ze standardowymi kontami użytkowników dzięki tym funkcjom:

  • Automatyczne dane logowania o ograniczonym czasie ważności: gdy konta usługi są powiązane ze środowiskiem wykonawczym Google Cloud (np. Compute Engine, Cloud Run lub Google Kubernetes Engine), automatycznie uzyskują i rotują bezpieczne dane logowania o ograniczonym czasie ważności. Pozwala to uniknąć ryzyka związanego z zarządzaniem i przechowywaniem trwałych kluczy statycznych.
  • Zasada jak najmniejszych uprawnień: konta usługi zapewniają dedykowane tożsamości dla zadań. 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 zadania: skonfiguruj środowisko hostujące logikę subskrybenta, aby działało jako nowe konto usługi. Dzięki temu kod aplikacji (np. biblioteki klienta interfejsu API Google) może automatycznie wykrywać i używać 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ę przejmowanemu kontu usługi, które wykonuje wywołania interfejsu API. W zależności od wymaganego poziomu dostępu przypisz jedną z tych ról:

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

Więcej informacji o rolach uprawnień i uprawnieniach 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 scalanie. 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ązkowe uzgadnianie weryfikacji dwuetapowej 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-Verifier, z treścią JSON {"type": "verification"}.

  • Autoryzowane uzgadnianie: pierwsze żądanie jest wysyłane ze skonfigurowanym Authorization nagłówkiem. Serwer musi odpowiedzieć kodem stanu 200 OK lub 201 Created.
  • Nieautoryzowane wyzwanie: drugie żądanie jest wysyłane bez danych logowania. 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 za pomocą żą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, co zmniejsza 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 spowodowała wysłanie powiadomienia:

  • 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 jest unikalnym identyfikatorem. 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 do tego pola unikalny identyfikator (losowy UUID) dla 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 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 przez nieograniczony czas. Przykład znajdziesz w sekcji Pobieranie identyfikatora użytkownika. Dzięki temu możesz wybrać prawidłowe dane logowania użytkownika podczas wysyłania zapytań o dane na podstawie healthUserId w powiadomieniu.

Podejmowanie działania w związku z powiadomieniem

Serwer musi natychmiast odpowiedzieć na powiadomienia kodem stanu HTTP 204 No Content. Aby uniknąć przekroczenia limitu czasu, po wysłaniu odpowiedzi przetwórz ładunek powiadomienia asynchronicznie. 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
    });
});

Sprawdzone metody

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

  • 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ą funkcji PublicKeySign 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

Za pomocą biblioteki Tink (zalecane): deweloperzy mogą zweryfikować podpis za pomocą funkcji PublicKeyVerify biblioteki Tink. Pobierz zestaw kluczy publicznych ze stałego adresu URL, utwórz instancję funkcji 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. Zdekoduj 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 dostępny 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