Endpunkte

Auf dieser Seite finden Sie eine Übersicht über die REST API-Konventionen sowie einen Index häufiger Google Health API-Aufgaben und Beispiele für jede Aufgabe.

REST API-Konventionen

Die Google Health API folgt den Google API Improvement Proposals (AIP) Standards, insbesondere AIP-127 (HTTP and gRPC Transcoding) und AIP-131 bis AIP-135 (Standard Methods). Diese Standards definieren, wie Daten aus einer Proto-Nachricht einer HTTP-Anfrage zugeordnet werden.

Suchparameter

Suchparameter werden verwendet, wenn die Daten Teil der URL sind. Dies gilt hauptsächlich für GET-Anfragen (Abrufen einer Ressource) oder LIST-Anfragen (Filtern/Paginierung), wird aber auch für DELETE-Vorgänge verwendet.

  • Platzierung: Wird nach einem ? an die URL angehängt.
  • Syntax: Schlüssel/Wert-Paare, getrennt durch &.
  • Mapping: Jedes Feld in der Anfragenachricht, das nicht Teil der URL Pfadvorlage ist, wird einem Suchparameter zugeordnet.
  • Best For: Einfache Typen (Strings, Ganzzahlen, Enums) und wiederholte Felder.

Beispielsyntax:

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"

Anfragetext

Der Anfragetext wird verwendet, wenn die Daten den Status einer Ressource ändern oder zu groß für eine URL sind. Der Text ist in der Regel eine JSON-Darstellung der Ressource selbst. Wird in der Regel für POST-, PATCH- und PUT-Vorgänge verwendet.

  • Platzierung: Im HTTP-Nutzlast (nicht in der URL sichtbar).
  • Syntax: Als JSON-Objekt formatiert.
  • Mapping: In der google.api.http Annotation definiert.
    • body: "*" bedeutet, dass die gesamte Nachricht der Text ist.
    • body: "resource_name" bedeutet, dass nur ein bestimmtes Feld im Proto der Text ist.
  • Best For: Komplexe Objekte, verschachtelte Nachrichten und vertrauliche Daten.

Beispielsyntax:

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

Der Hybridfall

Bei einer AIP-134-konformen Update-Methode oder einem PATCH-Vorgang werden beide verwendet. Die URL enthält den Ressourcennamen, der Text enthält die aktualisierten Ressourcendaten und ein Suchparameter (in der Regel update_mask) gibt an, welche Felder geändert werden sollen.

PATCH https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id
Content-Type: application/json

{
  "endpointUri": "https://myapp.com/new-webhooks/health"
}

Wichtige Unterschiede auf einen Blick

Funktion Suchparameter Anfragetext
AIP-Richtlinien Wird für Such-, Filter- und Lesevorgänge verwendet. Wird für Schreibvorgänge verwendet.
Sichtbarkeit Im Browserverlauf und in Serverlogs sichtbar. Nicht in der URL sichtbar.
Komplexität Beschränkt auf flache oder wiederholte Strukturen. Unterstützt tief verschachtelte JSON-Objekte.
Encoding Muss URL-codiert sein (z. B. werden Leerzeichen zu %20). Standard-JSON-Codierung.

Daten

Alle Daten in der Google Health API werden im Format YYYY-MM-DD angezeigt. Die Nutrition API unterstützt den ISO 8601-Standard für Datumswerte mit den folgenden Bedingungen:

  • Ein 4-stelliges Jahr YYYY
  • Jahreswerte im Bereich von 0000 bis 9999
  • Keine Erzwingung von Einschränkungen für das Startdatum, die durch den ISO 8601-Standard oder eine andere Epoche impliziert werden

Header

Für die Ausführung der Google Health API-Endpunkte müssen die entsprechenden Header und das Zugriffstoken verwendet werden. Der folgende Header wird sowohl für GET- als auch für POST-Anfragen empfohlen:

Authorization: Bearer access-token
Accept: application/json

Index der API-Aufgaben

In diesem Abschnitt finden Sie einen Index häufiger Google Health API-Aufgaben und Beispiele für jede Aufgabe.

Fitbit- oder Google-Nutzer-ID abrufen

Nachdem ein Nutzer über Google OAuth 2.0 zugestimmt hat, enthält die Tokenantwort nicht die Fitbit- oder Google-Nutzer-ID. Rufen Sie den getIdentity Endpunkt auf, um die Nutzer-ID zu erhalten. getIdentity gibt sowohl die Fitbit-Nutzer-ID als auch die Google-Nutzer-ID zurück.

Wir empfehlen, dass Sie den Endpunkt getIdentity aufrufen und beide Nutzer-IDs speichern, sobald ein neuer Nutzer über OAuth zustimmt. So sorgen Sie für Vorwärts- und Rückwärtskompatibilität in Ihrer Integration.

Beispiel:

Anfrage

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

Antwort

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

Intraday- oder detaillierte Daten abrufen, die im Laufe des Tages erhoben wurden

Verwenden Sie den list Endpunkt für einen bestimmten Datentyp, um Intraday- oder detaillierte Daten abzurufen, die im Laufe des Tages in unterstützten Intervallen für diesen Datentyp erhoben wurden.

Beispiel:

Anfrage

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

Antwort

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

Daten nach der zivilen Startzeit eines Intervalls filtern

Verwenden Sie den Endpunkt list mit einem filter-Parameter, um Daten nach ziviler Zeit oder einem Intervall zu filtern.

Beispiel:

Anfrage

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

Antwort

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

Daten nach der physischen Zeit einer Beispielbeobachtung filtern

Verwenden Sie den Endpunkt list mit einem filter-Parameter, um Daten nach der physischen Zeit einer Beispielbeobachtung zu filtern.

Beispiel:

Anfrage

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

Antwort

{
  "dataPoints": [
    {
      "name": "users/2515055256096816351/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": ""
}

Daten nach Datenquellen wie Wearables filtern

Verwenden Sie den reconcile Endpunkt, um Daten für eine bestimmte "Datenquellenfamilie" abzurufen. Geben Sie dazu den Parameter dataSourceFamily als Suchparameter an.

In der folgenden Tabelle werden die unterstützten dataSourceFamily-Optionen beschrieben:

Option Beschreibung
users/me/dataSourceFamilies/all-sources Standardwert. Enthält Daten aus allen verfügbaren Datenquellen.
users/me/dataSourceFamilies/google-wearables Enthält Daten von Google- und Fitbit-Trackern (z. B. Fitbit-Tracker und Pixel Watch). Manuell protokollierte Daten sind ausgeschlossen.
users/me/dataSourceFamilies/google-sources Enthält selbst erhobene Google-Daten, z. B. Daten von Trackern und manuell protokollierte Daten.

Hier ein Beispiel für das Filtern von Schlafdaten, die nach dem 3. März 2026 mit einem Tracker aufgezeichnet wurden:

Anfrage

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

Antwort

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

Datenpunkte über einen Zeitraum aggregieren

Verwenden Sie den rollUp Endpunkt, um die Aggregation von Datenpunkten basierend auf einem Fenster in Sekunden über den datetime Bereich basierend auf der physischen Zeit des Nutzers (in UTC) zurückzugeben.

Wenn Sie den Endpunkt rollUp aufrufen, müssen Sie den Anfragetext angeben, der den erforderlichen Zeitraum in der zivilen Zeit des Nutzers darstellt. Beispiel:

Anfrage

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": "30s"
}

Antwort

{
  "rollupDataPoints": [
    {
      "startTime": "2026-02-17T17:55:00Z",
      "endTime": "2026-02-17T17:55:30Z",
      "steps": {
        "countSum": "41"
      }
    },
    {
      "startTime": "2026-02-17T17:54:00Z",
      "endTime": "2026-02-17T17:54:30Z",
      "steps": {
        "countSum": "31"
      }
    },
...
  ]
}

Daten für einen oder mehrere Tage aggregieren

Der dailyRollUp Endpunkt sollte verwendet werden, wenn Sie Daten für einen oder mehrere Tage aggregieren möchten, die als windowSize bezeichnet werden. Geben Sie im Anfragetext den geschlossenen-offenen zivilen Zeitraum für das erforderliche Intervall an. Je nach Datentyp erhalten Sie entweder die Summe oder den Durchschnitt über das Intervall.

Beispiel:

Anfrage

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
}

Antwort

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

Gesundheitsdaten eines Nutzers einfügen oder aktualisieren

Verwenden Sie den patch Endpunkt, um die Fitbit App-Daten eines Nutzers einzufügen oder zu aktualisieren.

Hier ein Beispiel, bei dem ein Nutzer seinen Körperfettanteil auf einer Waage namens „HumanScale“ des Unternehmens „Scales R Us“ aufgezeichnet hat. Der neue Körperfettanteil des Nutzers beträgt am 10. März 2026 20 %.

Anfrage

PATCH https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints/1234567890
Authorization: Bearer access-token
content-length: 329

{
  "name": "bodyFatName",
  "dataSource": {

    "recordingMethod": "ACTIVELY_MEASURED",
    "device": {
      "formFactor": "SCALE",
      "manufacturer": "Scales R Us",
      "displayName": "HumanScale"
    }
  },
  "bodyFat": {
    "sampleTime": {
      "physicalTime": "2026-03-10T10:00:00Z"
    },
    "percentage": 20
  }
}

Antwort

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4main.DataPoint",
    "name": "users/2515055256096816351/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
    }
  }
}

Lebensmittel protokollieren

Senden Sie eine POST-Anfrage an den Endpunkt für nutrition-log-Datenpunkte, um ein Lebensmittel zu protokollieren. Der Anfragetext enthält einen DataPoint mit einem nutritionLog-Objekt. Weitere Informationen finden Sie im Leitfaden zur Ernährung.

Beispiel:

Anfrage

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

Antwort

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4.DataPoint",
    "name": "users/2515055256096816351/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"
    }
  }
}

Gesundheitsdaten von Nutzern löschen

Verwenden Sie den batchDelete Endpunkt, um ein Array von Fitbit App-Daten eines Nutzers zu löschen.

Hier ein Beispiel, bei dem ein Nutzer zuvor seinen Körperfettanteil auf einer Waage aufgezeichnet hat, den Eintrag aber löschen möchte. Verwenden Sie die user-id und data-point-id aus der ursprünglichen Einfügeaktion:

Anfrage

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/2515055256096816351/dataTypes/body-fat/dataPoints/1234567890"
  ]
}

Antwort

{
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.devicesandservices.health.v4main.BatchDeleteDataPointsResponse"
  }
}

Geräteinformationen abrufen

Verwenden Sie den list Endpunkt, um die Liste der Geräte abzurufen, die mit dem Konto eines Nutzers verknüpft sind. Dazu gehören die Modellinformationen des Geräts (deviceVersion) und der Zeitpunkt der letzten Synchronisierung mit der Google Health App (lastSyncTime).

Die Listenkonfiguration und die Synchronisierungsinformationen sind nützlich, um Synchronisierungsprobleme zu beheben oder Verlaufsdaten seit der letzten Synchronisierung abzurufen.

Beispiel:

Anfrage

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

Antwort

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

Verlaufsdaten abfragen

Einer der Hauptvorteile der Google Health API ist die Möglichkeit, die Leistung eines Nutzers zu verfolgen und seine Vitalparameter über lange Zeiträume hinweg zu beobachten. Sie können die Daten eines Nutzers so weit zurück abfragen, wie sie aufgezeichnet wurden. Die API unterliegt keinen Einschränkungen hinsichtlich der Menge an Verlaufsdaten, die Ihre Anwendung verwenden kann.

Die Abfrage von Verlaufsdaten unterliegt jedoch weiterhin den Standard Ratenbegrenzungen. Um die Anzahl der API-Aufrufe im Verhältnis zu diesen Begrenzungen zu reduzieren, unterstützt die Google Health API die Abfrage von Daten über einen Zeitraum hinweg. Beachten Sie die folgenden Begrenzungen für Paginierung und Anfragen:

  • Jeder Endpunkt gibt maximal 10.000 Datenpunkte pro Seite zurück.
  • Abfragezeiträume sind auf 14 bis 90 Tage pro Anfrage beschränkt.

Je nach Menge der Verlaufsdaten, die Ihre Anwendung benötigt, kann das Abrufen des gesamten Datensatzes mehrere aufeinanderfolgende Anfragen erfordern und zusätzliche Zeit in Anspruch nehmen. Berücksichtigen Sie dies beim Entwerfen des Datenabgleichsprozesses Ihrer Anwendung.

Beachten Sie die folgenden Richtlinien, um eine optimale Leistung zu erzielen und API-Fehler zu vermeiden, wenn Sie Verlaufsdaten abfragen:

Phasensynchronisierung von Daten (aktive vs. selten genutzte Daten)

  • Erste „aktive“ Last: Rufen Sie während der primären Ladefolge nur die Daten der letzten 7 bis 14 Tage ab und rendern Sie sie. So können Nutzer Daten sofort sehen, ohne auf lange Abfragen warten zu müssen.
  • „Selten genutzte“ Last im Hintergrund: Übertragen Sie den Abruf älterer Verlaufsdaten an eine asynchrone Warteschlange mit niedrigerer Priorität oder einen Hintergrundprozess, nachdem die primäre Benutzeroberfläche gerendert wurde.

Zeitbasierte Abfrageaufteilung

  • Fordern Sie in einem einzelnen API-Aufruf keine Zeiträume von mehreren Jahren oder Monaten an. Teilen Sie große Verlaufsabfragen in kleinere, aufeinanderfolgende Intervalle auf (z. B. 1 Woche pro Anfrage).
  • Führen Sie diese Unterabfragen im Batch oder sequenziell aus, um die Begrenzungen für die Parallelität einzuhalten und die Fortschrittsanzeigen der Benutzeroberfläche konstant zu halten.

Vorab aggregierte Roll-ups nutzen

Strukturieren Sie Übersichts-Dashboards und Trenddiagramme so um, dass vorab aggregierte Zusammenfassungsendpunkte verwendet werden (z. B. DailyRollUpDataPoints). Dadurch werden der Rechenaufwand im Back-End und die Zeit für die Netzwerkübertragung zum Client drastisch reduziert.

Robuste Fehlerbehandlung (intelligente Wiederholungen)

  • Implementieren Sie eine strenge exponentielle Backoff-Verarbeitung, wenn Raten begrenzungen (429 Too Many Requests) und Server-Gateway-Timeouts (504 Gateway Timeout) auftreten. Wiederholen Sie große, fehlgeschlagene Nutzlasten niemals sofort. Sofortige Wiederholungen führen zu einer Überlastung des Back-Ends und zu einer Verschlechterung des Systems.
  • Wenn bei einer Abfrage wiederholt ein Timeout auftritt, wechseln Sie automatisch zu einem kleineren Zeitraum (z. B. reduzieren Sie einen 1-Wochen-Abschnitt auf 3 Tage).