Nutzungslimits und Kontingente

Durch Beschränkungen und Kontingente wird die Google-Infrastruktur vor automatisierten Prozessen geschützt, die die Admin Settings API auf unangemessene Weise verwenden. Eine übermäßige Anzahl von Anfragen an eine API kann durch einen einfachen Tippfehler oder ein ineffizient gestaltetes System verursacht werden, das unnötige API-Aufrufe ausführt. Unabhängig von der Ursache ist es für einen funktionsfähigen Gesamtstatus des Google Workspace-Systems wichtig, den Traffic von einer bestimmten Quelle zu blockieren, sobald er einen bestimmten Wert erreicht. So wird sichergestellt, dass die Aktionen eines Entwicklers keine negativen Auswirkungen auf die gesamte Community haben.

Im unwahrscheinlichen Fall, dass Ihre API-Anfrage fehlschlägt, erhalten Sie eine Antwort mit einem HTTP-Statuscode. Ein Statuscode 403 enthält Fehlerinformationen zu falscher Eingabe und ein HTTP-Statuscode 503 enthält Fehlerinformationen, die angeben, welche API-Kontingente überschritten wurden. Anhand dieser Antworten kann Ihre benutzerdefinierte Anwendung diese Fehler erkennen und entsprechende Maßnahmen ergreifen.

Wenn Ihre Anfragen innerhalb eines bestimmten Zeitraums abgeschlossen werden müssen, senden Sie sie parallel oder verwenden Sie mehrere Threads in Ihrer Java- oder C#-Anwendung. Sie können Ihre Anfragen beispielsweise nach Monat oder einem anderen Zeitraum aufteilen. Bei Threads sollten Sie mit 10 Threads beginnen, einem Thread pro Anfrage. Die Empfehlung für Threads hat Vor- und Nachteile und ist nicht für alle API-Situationen nützlich. Wenn die Anzahl der Anfragen zu hoch wird, treten Kontingentfehler auf.

Bei allen zeitbasierten Fehlern (maximal N Elemente für X Sekunden pro Thread), insbesondere bei Fehlern mit dem Statuscode 503, empfehlen wir, dass Ihr Code die Ausnahme abfängt und mit einem exponentiellen Backoff-Algorithmus eine kurze Zeit wartet, bevor er den fehlgeschlagenen Aufruf noch einmal versucht. Ein Beispiel für die Email Settings API für einen Thread: Warten Sie 5 Sekunden und wiederholen Sie den fehlgeschlagenen Aufruf. Wenn die Anfrage erfolgreich ist, wiederholen Sie diesen Vorgang für die anderen Threads. Wenn die zweite Anfrage nicht erfolgreich ist, sollte die Häufigkeit der Anfragen in Ihrer Anwendung reduziert werden, bis ein Aufruf erfolgreich ist. Erhöhen Sie beispielsweise die anfängliche Verzögerung von 5 Sekunden auf 10 Sekunden und versuchen Sie es noch einmal. Legen Sie außerdem ein Limit für Wiederholungsversuche fest. Wiederholen Sie eine Anfrage beispielsweise 5- bis 7-mal mit unterschiedlichen Verzögerungszeiten, bevor Ihre Anwendung einen Fehler an den Nutzer zurückgibt.

API-Kontingentkategorien Kontingente
ClientLogin-Authentifizierungstokens 24 Stunden lang gültig. Der Fehler lautet „401 token expired“.
Öffentliche und private Schlüssel generieren

Generieren Sie mit Ihrem Identitätsanbieter ein Schlüsselpaar mit einem öffentlichen und einem privaten Schlüssel mithilfe des DSA- oder RSA-Algorithmus. Der öffentliche Schlüssel befindet sich in einem X.509-Zertifikat. Weitere Informationen zu SAML-basierten SSO-Signaturschlüsseln finden Sie unter Schlüssel und Zertifikate für den Google Workspace-SSO-Dienst generieren.
Logo

Die Logobilddatei eines Kontos kann im JPEG-, PNG- oder GIF-Format vorliegen. Die empfohlene Größe ist 143 × 59 Pixel und die Datei sollte kleiner als 20 KB sein. Denken Sie bei der Verwendung benutzerdefinierter Logos daran, dass Sie die Nutzungsbedingungen von Google einhalten müssen. Verzichten Sie auf die Verwendung des Google-Logos, des Gmail-Logos oder anderer Google-Logos. Weitere Informationen finden Sie unter Richtlinien für Logos und Landingpages.
ssoWhitelist

Eine ssoWhitelist ist eine Netzwerkmasken-IP-Adresse im CIDR-Format(Classless Inter-Domain Routing).
Andere Arten von Limits Einschränkungen und Richtlinien
Status der Überprüfung des MX-Eintrags

Der Standardstatus für die Bestätigung von MX-Einträgen ist „false“. Das bedeutet, dass das Google-System Ihre MX-Eintragskonfiguration entweder nicht vor Kurzem überprüft hat oder Ihre MX-Einträge nicht so konfiguriert wurden, dass sie auf die Google-Systeme verweisen. Wenn Sie Ihre Einträge aktualisiert haben und der Bestätigungsstatus weiterhin „false“ ist, kann das bedeuten, dass die Aktualisierungen des MX-Eintrags noch nicht übernommen wurden oder dass der Eintrag einen Tippfehler enthält. Warten Sie die Zeit, die durch den TTL-Wert (Time To Live) des MX-Eintrags definiert ist, und versuchen Sie es dann noch einmal.
Ländercodes

Wenn der Name der Organisation nicht angepasst wurde, ist standardmäßig Ihr primärer Domainname festgelegt. Informationen zu Zeichen im Organisationsnamen finden Sie unter Zeichenverwendung.
creationTime-Attribut, numerische Darstellung von Datum und Uhrzeit

Weitere Informationen finden Sie unter ISO 8601, Numerische Darstellung von Datum und Uhrzeit.
Tags für die Sprachcodierung

Von Google Mail akzeptierte RFC 3066-Sprachtags
Name der Organisation

Wenn der Name der Organisation nicht angepasst wurde, ist standardmäßig Ihr primärer Domainname festgelegt. Informationen zu Zeichen im Organisationsnamen finden Sie unter Zeichenverwendung.

Kontingenterhöhung pro Projekt anfordern

Abhängig von der Ressourcennutzung Ihres Projekts können Sie eine Kontingentanpassung beantragen. API-Aufrufe durch ein Dienstkonto werden als Aufrufe über ein einzelnes Konto betrachtet. Wenn Sie ein angepasstes Kontingent beantragen, bedeutet dies nicht, dass Ihr Antrag auch genehmigt wird. Die Genehmigung von Anfragen zur Kontingentanpassung, die den Kontingentwert erheblich erhöhen würden, kann länger dauern.

Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Sie Google Cloud im Laufe der Zeit häufiger nutzen, müssen Ihre Kontingentwerte möglicherweise erhöht werden. Falls Sie eine deutlich stärkere Auslastung erwarten, können Sie auf der Seite „Kontingente“ der Google Cloud Console eine Anpassung Ihres Kontingents anfordern.

Weitere Informationen finden Sie in den folgenden Ressourcen: