Capgo Öffentliche API-Liste: Vollständige Entwicklerreferenz

Wahrscheinlich hast du eine Deployment-Pipeline, die manuell funktioniert, aber fragil wird, sobald das Team wiederholbare Releases braucht. Ein Entwickler erstellt ein Bundle, lädt es vom Laptop hoch, prüft ein Dashboard, verschiebt einen Channel und wartet dann auf die Adoptionsdaten. Für ein kleines Projekt mag das reichen, aber es erzeugt vermeidbare Risiken, wenn mehrere Apps, Umgebungen und Deployment-Jobs dieselbe Infrastruktur nutzen.

Eine hilfreiche öffentliche API-Liste sollte mehr beantworten als nur „welche Endpoints gibt es?“. Sie sollte zeigen, wie Authentifizierung, Resource-IDs, Release-Status, Quotas, Header, Retries und Batch-Workflows zusammenspielen. Dieser Guide betrachtet die Capgo API aus dieser operativen Perspektive – mit Patterns, die für Capacitor Teams relevant sind, die CI/CD-Automatisierung statt isolierter Test-Requests aufbauen.

Inhaltsverzeichnis

• Capgo API-Authentifizierung verstehen
  • Identität von Autorisierung trennen
• Deine API-Credentials generieren
  • Zweckgebundenen Key erstellen
  • Rotation ohne Ausfallzeiten
• Core-Endpoints für App-Management
  • Identifier-first-Workflow aufbauen
• Releases erstellen und verwalten
  • Release-Payload vorbereiten
  • Retries sicher gestalten
• Channel-Strategie und Rollout-Patterns
• Monitoring- und Diagnose-Endpoints
  • Vor dem Aggregieren gezielt abfragen
  • Diagnose mit Automatisierung verbinden
• Rate Limiting und Security Headers
  • Schütze die Management-Oberfläche
• Häufige API-Fehler beheben
  • Authentifizierungsfehler
  • Ungültige Request-Bodies
  • Throttling und mehrdeutige Mutationen

Capgo API-Authentifizierung verstehen

Der häufigste Fehler bei der ersten Integration ist, einen gültigen Request mit dem falschen Credential-Format zu senden. Ein aus dem Dashboard kopierter Key ist nicht automatisch ein Bearer-Token, und ein Bearer-Token nützt nichts, wenn der Request den Authorization Header weglässt oder unter einem falschen Scheme sendet. Der Server gibt dann einen Authentifizierungsfehler zurück, noch bevor Endpoint, Payload oder App-Identifier geprüft werden.

Identifiziere zuerst, wie die aktuelle Capgo API Dokumentation das Credential nennt, und reproduziere den Beispiel-Request exakt. Bei einem typischen Bearer-Token-Request folgt der Authorization-Header diesem Muster:

Authorization: Bearer YOUR_TOKEN

Halte die Zugangsdaten während des lokalen Testens in einer Umgebungsvariablen. In CI/CD injiziere sie über den Secret Store der Plattform, statt sie in ein Repository zu committen, in ein Mobile-Bundle zu legen oder in eine Query String einzufügen. Eine mobile Anwendung darf keine Management-Zugangsdaten enthalten, da alles, was auf ein Gerät ausgeliefert wird, irgendwann inspiziert werden kann.

Identität von Autorisierung trennen

Authentication beantwortet, wer die Anfrage stellt. Authorization beantwortet, was diese Identität ändern darf. Behandle diese als separate Checks, wenn du einen Deployment-Service designst.

Ein persönlicher Key kann für die Exploration praktisch sein, koppelt aber die Produktionsautomatisierung an das Konto einer Person. Ein teamverwalteter Key ist für eine geteilte Pipeline geeigneter, vorausgesetzt, die Organisation kann ihn widerrufen und ersetzen, ohne unbeteiligte Jobs zu unterbrechen. Verwende separate Credentials für Entwicklungs-, Staging- und Produktions-Workflows, sofern das Dashboard und das Berechtigungsmodell diese Trennung unterstützen.

Teste vor dem Aufruf eines Release-Endpoints eine risikoarme Leseoperation. Stelle sicher, dass:

• Der Host korrekt ist: Verwende die für die aktive Umgebung dokumentierte API-Basis-URL.
• Der Header vollständig ist: Füge das erforderliche Authorization-Schema und ein Accept Header für JSON-Antworten ein.
• Der Body korrekt kodiert ist: Senden Content-Type: application/json nur wenn die Anfrage JSON enthält.
• Der Scope ist ausreichend: Ein Credential, das App-Metadaten lesen kann, darf möglicherweise keine Releases erstellen oder verteilen.
• Die Antwort wird sicher geloggt: Statuscodes und Request-IDs protokollieren, aber Keys, Tokens, Bundle-Inhalte und sensible Gerätedaten maskieren.

Öffentliche API-Kataloge haben sich aus einfachen Verzeichnissen zu operativen Discovery-Tools entwickelt. ProgrammableWeb’s historische Aufzeichnung beschreibt ein Verzeichnis, das 19.000 APIs im Januar 2018, nach 2.294 neuen APIs im Jahr 2017 hinzugefügt wurden und im Durchschnitt mehr als 2.000 Zugaben pro Jahr seit Januar 2014. Diese Historie erklärt, warum eine moderne öffentliche API-Liste Engineers helfen muss, das Integrationsverhalten zu bewerten, nicht nur eine URL zu finden.

Für verwandte Überlegungen zur clientseitigen Zugriffskontrolle siehe Capgo-App-Autorisierungsmuster. Die gleiche Disziplin gilt hier: Halte Management-Credentials auf vertrauenswürdigen Servern, definiere Berechtigungen bewusst und mache fehlgeschlagene Autorisierung leicht diagnostizierbar.

Deine API-Credentials generieren

Die Erstellung von Credentials sollte als Änderung im Zugriffsmanagement behandelt werden, nicht als beiläufiger Setup-Schritt. Die genauen Dashboard-Labels können sich ändern, daher die aktuelle Capgo-Oberfläche und Dokumentation als Autorität nutzen, aber der Workflow bleibt konsistent.

Zweckgebundenen Key erstellen

Öffne den Bereich für Organisations- oder Kontoeinstellungen, finde den API- oder Developer-Credentials-Bildschirm und wähle die Aktion zum Erstellen eines Keys. Gib dem Key einen Namen, der seinen Zweck identifiziert, wie eine Staging-Deployment-Pipeline oder einen Production-Release-Worker. Vermeide Namen, die sich nur auf die Identität einer Person beziehen, da die Zuständigkeit bei Teamwechseln unklar wird.

Wähle die engsten verfügbaren Berechtigungen für diesen Workflow. Ein Job, der nur den Deployment-Status liest, sollte keine Berechtigung zum Löschen von Anwendungen oder Ändern von Channels erhalten. Wenn die Oberfläche Organisations- und App-Level-Scope anbietet, bevorzuge die kleinere Grenze, die den Job noch unterstützt.

Kopiere das Secret, sobald es im Dashboard angezeigt wird. Viele Credential-Systeme zeigen den vollständigen Wert nur während der Erstellung. Speichere es in deinem CI/CD-Secret-Manager und teste das Abrufen in der Pipeline, ohne den Wert auszugeben. Eine lokale .env Datei kann während der Entwicklung hilfreich sein, muss aber aus der Versionskontrolle ausgeschlossen und niemals in ein Capacitor-Web-Verzeichnis gebündelt werden.

Rotation ohne Ausfallzeiten

Halte bei der Rotation eines Credentials eine Überlappungsphase ein. Füge den Ersatz zum Secret-Store hinzu, deploye die Pipeline-Konfiguration, die ihn verwendet, führe einen harmlosen authentifizierten Read aus und widerrufe erst dann den alten Key. Wenn der Service mehrere aktive Keys unterstützt, halte den alten Wert verfügbar, bis jeder Worker und jeder geplante Job migriert ist.

Für ein Team: Dokumentiere Key-Owner, Zweck, Umgebung, Erstellungsdatum und Widerrufsverfahren in einem internen Zugangsregister. Lege das Secret selbst nicht in dieses Register. So bleibt eine Incident Response praktikabel, ohne dass die Dokumentation zu einem weiteren Secret-Repository wird.

Der Standards der britischen Regierung für API empfehlen, ein OpenAPI-Dokument früh zu entwerfen, Inputs zu validieren, unbekannte Attribute abzulehnen, TLS 1.2 oder höher zu verwenden und OAuth 2.0 für die Zugriffskontrolle anzuwenden. Diese Prinzipien sind nützlich, selbst wenn die Integration API-Keys verwendet: Definiere den Vertrag vor dem Aufbau der Automatisierung, lehne unerwartete Inputs ab und behandle Transport-Sicherheit als essenziell.

Für Pipeline-Speicherung und Rotationsmuster nutze Capgo-Leitfaden zum Management von Secrets in CI/CD-Pipelines.

Core-Endpoints für App-Management

App-Management ist die Control Plane für alles, was danach folgt. Release-Erstellung, Channel-Zuweisung, Bundle-Verteilung und Diagnostics benötigen alle einen stabilen Anwendungs-Identifikator. Der praktische Fehler besteht darin, einen menschenlesbaren App-Namen durch jeden Job zu geben und anzunehmen, er bleibe eindeutig. Löse die App einmal auf, persistiere den kanonischen Identifikator und nutze diesen für nachfolgende Operationen.

Eine Produktionsintegration sollte den App-Lebenszyklus um vier Fähigkeiten modellieren:

Erfinden Sie keine Endpoint-Pfade aus einem Blog-Post oder einer alten SDK. Lesen Sie die aktuelle maschinenlesbare Definition und generieren Sie daraus einen typisierten Client oder Request-Wrapper. Die OpenAPI-Spezifikation beschreibt ein programmiersprachenunabhängiges Format für HTTP-APIs, das es Menschen und Tools ermöglicht, Endpoints, Authentifizierung, Request-Schemas, Antworten und Verhalten zu entdecken, ohne den Quell-code oder den Netzwerkverkehr zu inspizieren.

Identifier-first-Workflow aufbauen

Ein Deployment-Worker sollte vor einer Mutation einen Read durchführen:

1. Organisations- und Anwendungskontext ermitteln.
2. App-Record abrufen und bestätigen, dass er zum erwarteten Konto gehört.
3. Vorgesehene Plattform und Umgebung mit der zurückgegebenen Konfiguration vergleichen.
4. Speichern Sie den kanonischen App-Identifier im Job-Status.
5. Senden Sie die Release- oder Konfigurationsänderung mit diesem Identifier ein.
6. Speichere die Response-ID für späteres Polling und Diagnose.

Diese Abfolge verhindert eine überraschend teure Fehlerklasse, bei der ein gültiger Key die falsche App aktualisiert, weil eine Pipeline-Variable auf ein altes Projekt zeigt. Füge vor dem Schreibvorgang eine explizite Environment-Prüfung hinzu, z. B. indem du verlangst, dass ein Staging-Job auf die Staging-App abzielt.

Nutze Response-Schemas statt losem JSON-Zugriff. Wenn API ein App-Objekt mit Identifier, Name, Status und Konfigurationsfeldern zurückgibt, validiere die Felder, die dein Job braucht, und toleriere unabhängige Ergänzungen. Das Ablehnen unbekannter Request-Attribute schützt dich vor falsch geschriebenen Konfigurations-Keys, während tolerantes Parsen der Response dem Client hilft, eine nicht-breaking Erweiterung der Response zu überstehen.

Halte beim Rollback-Design App-Identität und Release-Identität getrennt. Die Version-Control- und Rollback-Doku von Capgo ist die relevante operative Referenz. Ein Rollback sollte einen bekannt guten Release- oder Channel-Zustand auswählen, statt eine App-Konfiguration aus dem Gedächtnis neu zu erstellen.

Releases erstellen und verwalten

Ein Production-Release kann fehlschlagen, obwohl der Upload erfolgreich war. Das Artefakt ist vielleicht korrekt gespeichert, aber die Verarbeitung ist noch nicht abgeschlossen, das Channel-Assignment ist nicht erfolgt oder berechtigte Geräte haben das Update noch nicht erhalten. Betrachte den Workflow als Sequenz beobachtbarer Zustandsänderungen, mit einer dauerhaften ID und einem Retry-Plan für jede Operation.

Release-Payload vorbereiten

Verwende das aktuelle Capgo-Schema für Eigenschaftsnamen, Request-Pfade und Pflichtfelder. Ein Request-Body, der von einem ähnlich benannten Endpoint kopiert wurde, kann teilweise akzeptiert oder aus unerwarteten Gründen abgelehnt werden. Praktisch gesehen enthält die Payload drei Bereiche:

• Anwendungsidentität: Die Anwendungs-ID, die von der zugehörigen Control-Plane-Operation zurückgegeben wird.
• Release-Metadaten: Version, Bundle-Identität, Build-Kontext und Kompatibilitätsinformationen, die vom API erwartet werden.
• Distributionsabsicht: Der Channel oder Rollout-Kontext, sofern die Release-Operation dies unterstützt.

Validiere das Bundle, bevor du es sendest. Prüfe, ob der Capacitor-Build die erwarteten Web-Assets enthält, ob seine Version mit den CI-Metadaten übereinstimmt und ob der Job keine teilweise geschriebene Datei liest. Berechne eine lokale Checksumme, wenn der API eine akzeptiert. Speichere die Build-URL, die Commit-Referenz und die serverseitig ausgestellte Release-ID im Deployment-Record, damit spätere Jobs Upload-, Verarbeitungs- und Distributionsereignisse korrelieren können.

Eine zuverlässige Abfolge ist:

1. Baue die Anwendung in einem sauberen Workspace.
2. Führe Unit-, Integrations- und plattformspezifische Checks aus.
3. Erstelle oder lade das Bundle über die dokumentierte Release-Operation hoch.
4. Frage die zurückgegebene Operation oder Release-Ressource ab, bis sie einen Endzustand erreicht.
5. Verknüpfe das abgeschlossene Release mit dem vorgesehenen Channel.
6. Prüfe Adoptions- und Failure-Signale vor der Promotion.

Eine Upload-Antwort bestätigt die Annahme durch den Service, nicht die Zustellung an Nutzer. Verarbeitungsstatus, Geräteeignung, Konnektivität und Channel-Mitgliedschaft entscheiden weiterhin, ob ein Update ein Gerät erreicht.

Retries sicher gestalten

Ein Timeout zeigt nicht an, ob der Server die Anfrage abgelehnt oder vor dem Verbindungsabbruch abgeschlossen hat. Das erneute Senden desselben Releases kann daher Duplikate oder konfliktbehaftete Versionen erzeugen. Nutze einen Idempotency-Key, falls Capgo dies unterstützt. Ohne diese Möglichkeit frage vor einem Retry anhand der Release-Metadaten oder einer clientseitig generierten Build-ID ab.

Batch-Uploads benötigen Status auf Item-Ebene. Schreibe jede App-Variante in eine persistente Queue und protokolliere das Ergebnis unabhängig. Ein Worker-Retry sollte nur unfertige Items auswählen, statt nach einem Fehler den gesamten Batch zu wiederholen. Falls ein Bulk-Endpoint verfügbar ist, prüfe, ob die Antwort ein Ergebnis für jedes Item enthält. Ein aggregierter Erfolgsstatus kann eine fehlgeschlagene Variante verbergen, während ein aggregierter Fehler abgeschlossene Arbeit verschleiern kann.

Operative Regel: Speichere die Release-ID des Servers sofort und verwende diese ID für Verarbeitungsprüfungen, Channel-Zuweisungen und Diagnosen.

Rate-Limits betreffen sowohl Uploads als auch Polling. API Leitfaden zum Rate-Limiting Hinweise darauf, dass Quoten die ausgeführte Aktion widerspiegeln sollten und dass Clients nutzbare Header und ein Retry-Verhalten benötigen. Wende separate Handhabungen für die Erstellung von Releases, Status-Polling, Suchen und sensible Mutationen an. Eine Polling-Schleife, die mit Upload-Geschwindigkeit neu versucht, kann die für eine Korrekturmaßnahme benötigte Quote aufbrauchen.

Lies Rate-Limit-Header, wenn sie zurückgegeben werden, befolge ein vom Server bereitgestelltes Retry-Intervall und verwende steigende Verzögerungen, wenn diese fehlen. Füge Jitter hinzu, damit mehrere CI-Worker nicht gleichzeitig neu versuchen. Begrenze das Polling, stoppe bei einem Endzustand und füge den finalen Response-Body in die CI-Logs ein, nachdem Credentials und Tokens entfernt wurden. Wenn jemand eine Deployment abbricht, protokolliere die handelnde Person oder den Automatisierungsjob, den aktuellen Release-Zustand und ob das Artefakt für einen späteren Retry weiterhin verfügbar ist.

Channel-Strategie und Rollout-Patterns

Das Channel-Design ist eine Entscheidung zur Release-Governance, nicht nur eine Namensgebung. Staging-, Beta- und Produktionskanäle bedienen unterschiedliche Zielgruppen und sollten unterschiedliche Promotionsregeln haben. Die richtige Wahl hängt davon ab, wie viel Unsicherheit im Bundle verbleibt und wie schnell das Team Feedback benötigt.

Ein Staging-Channel sollte deterministisch sein. Weisen Sie bekannte Testgeräte oder -konten zu, schützen Sie den Channel vor unbedachten Änderungen und lassen Sie CI nur nach bestandenen Checks promovieren. Beta ist nützlich, wenn produktionsähnlicher Traffic wichtig ist, erfordert aber eine klare Zielgruppendefinition und einen Support-Prozess zur Fehlermeldung. Production sollte langweilig sein: Das Release hat frühere Gates bestanden, das Rollback-Ziel ist bekannt und das Monitoring ist bereits verbunden.

Der API-Workflow sollte diese Grenzen widerspiegeln. Eine Pipeline kann das Release einmal erstellen, es Staging zuweisen und dasselbe Release-Objekt nach Validierung promovieren. Neuaufbau zwischen Channels schwächt die Nachverfolgbarkeit, da das von der Team getestete Artefakt nicht das an Nutzer verteilte Artefakt sein muss.

Das aktuelle öffentliche API-Ökosystem zeigt auch, warum Pflege genauso wichtig ist wie Umfang. API Tracker bietet einen großen Katalog an APIs und Entwicklerressourcen, während Kommentare zu öffentlichen API-Übersichten die Wartungsbelastung hervorheben, die entsteht, wenn Einträge Finanzen, Regierung, Gesundheit, Machine Learning, Wetter und Verkehr abdecken. Ein Channel-Katalog hat dasselbe Problem: Veraltete Einträge und unklare Zuständigkeiten machen eine große Liste weniger nützlich als eine kleinere, gepflegte.

Für Implementierungsdetails zu kontrolliertem Testing siehe Capgo Staging-Umgebungen mit Channels. Das Schlüsselprinzip ist, Channel-Wechsel als explizite API-Aktion mit einer Genehmigungsgrenze zu gestalten, anstatt jedem Build-Job zu erlauben, direkt in die Produktion zu schreiben.

Monitoring- und Diagnose-Endpoints

Ein Deployment ist nicht abgeschlossen, wenn das API eine erfolgreiche Antwort zurückgibt. Es ist abgeschlossen, wenn das Team erklären kann, welche Release Geräte entdeckt, heruntergeladen, installiert und erfolgreich weiterlaufen lassen haben. Dafür ist ein Workflow erforderlich, der Release-Identifikatoren, Channel-Mitgliedschaft, Geräteaufzeichnungen, Logs und Adoptionsdaten verbindet.

Beginnen Sie mit einem Korrelationsdatensatz in Ihrem Deployment-System. Speichern Sie die App-Identifikator, Release-Identifikator, Channel, Commit-Referenz, Build-Metadaten, Anfragezeitstempel und den finalen API-Status. Wenn ein Support-Bericht eingeht, sollte der Operator in der Lage sein, vom betroffenen Gerät zu seinem Channel und Release zu navigieren, ohne durch unstrukturierte CI-Logs zu suchen.

Vor dem Aggregieren gezielt abfragen

Diagnose-Endpoints unterstützen oft Filter für Zeiträume, Channels, Geräte, Plattformen oder Releases. Nutze den präzisesten Filter für deine Frage. Eine breite Abfrage über alle Installationen hinweg ist langsamer, schwerer zu interpretieren und stößt eher an Pagination- oder Quota-Limits.

Eine praktische Reihenfolge für die Untersuchung ist:

• Release-Ansicht: Prüfe, ob das gewünschte Release existiert und den Ziel-Channel erreicht hat.
• Adoption-Ansicht: Vergleiche berechtigte Geräte mit denen, die das Update entdeckt oder installiert haben.
• Failure-Ansicht: Gruppiere Fehler nach Release, Plattform, Geräteklasse und Installationsphase.
• Geräte-Ansicht: Untersuche Logs für ein spezifisches Gerät erst, wenn das aggregierte Muster auf ein lokales Problem hindeutet.
• Incident-Ansicht: Speichere die Raw-Response und die für die Untersuchung verwendeten Query-Parameter.

Geh nicht davon aus, dass ein niedriges Adoptionssignal bedeutet, dass das Bundle defekt ist. Geräte können offline sein, vom Channel ausgeschlossen sein, eine inkompatible Version ausführen oder auf den Update-Check der App warten. Umgekehrt beweist eine hohe Downloadzahl keinen erfolgreichen App-Start. Trenne Discovery, Download, Installation und Runtime-Health, sobald API diese Zustände anzeigt.

Diagnose mit Automatisierung verbinden

Ein geplanter Worker kann den Release-Status abfragen und einen Alert auslösen, wenn ein Release länger als von der Pipeline erlaubt in einem nicht-terminalen Zustand bleibt. Ein weiterer Worker kann Failure-Records sammeln, Error-Codes normalisieren und sie dem Deployment-Ticket anhängen. Halte die Alert-Payload knapp, mit Links zum Release, zum Channel und zur gefilterten Diagnostic-Query.

Authentifizierung und Error Handling gehören in dieselbe Client-Schicht wie Endpoint-Calls. Der Worker sollte Credentials gemäß der Credential-Policy erneuern oder ersetzen, Authorization-Fehler getrennt von fehlerhaften Requests klassifizieren und 429 Responses für das Retry-Scheduling aufbewahren, statt sie als generische Serverfehler zu behandeln.

Nutze Pagination-Cursor oder dokumentierte Offsets genau wie angegeben. Ein Batch-Diagnosejob muss seine Position zwischen den Seiten behalten und darf nicht wiederholt die erste Seite abrufen. Wenn sich Records während einer Query ändern können, nutze eine stabile zeitliche Grenze oder einen Release-Filter, damit der resultierende Report reproduzierbar ist.

Rate Limiting und Security Headers

Produktionsclients sollten Response-Header prüfen, bevor sie einen Retry-Pfad wählen. Erfasse X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After, sowie alle dokumentierten RateLimit-* Felder in der API Client-Middleware. Übergib sie an den Retry-Controller und die strukturierten Logs. Hard-code keine Quotas, die je nach Account, Endpoint oder Operation variieren können.

Die Unterscheidung zwischen Kapazitätsinformationen und Retry-Anweisungen bestimmt die nächste Anfrage. Ein Remaining-Count-Header zeigt an, wie nah der Client am Limit ist. Retry-After gibt an, wann der Server einen weiteren Versuch erlaubt. Beachte diese Anweisung, wenn sie vorhanden ist. Macht die Response keine Zeitvorgaben, nutze Bounded Exponential Backoff mit Jitter und ein festes Versuchslimit.

Schütze die Management-Oberfläche

Halte Capgo Management-Requests in einem vertrauenswürdigen Backend oder CI-Runner. Eine Capacitor App darf einen eng gefassten, auf die App ausgerichteten Service aufrufen, sollte aber niemals Credentials erhalten, mit denen sich Releases, Channels oder Organisations-Ressourcen ändern lassen. Erzwinge TLS, validiere die Bodies und entferne Authorization-Header aus Traces und Error-Reports.

Wende separate Limits pro Operation an. Cache oder bündle Read-only-Metadata-Requests, wo es sicher ist. Gib Uploads, Exports, Login-Versuchen und Release-Mutationen eigene Limits. Bündle unabhängige Metadata-Reads, wenn API Batch-Operationen unterstützt, und rechne dann mit den Request- und Item-Limits des Batches, statt anzunehmen, dass ein Batch nur eine Einheit kostet. Verhaltensbasierte Kontrollen helfen zudem, verteilte Abuse-Muster zu erkennen, wie in Richtlinien für Rate-Limiting und Sicherheit.

Verwende Timeouts für jede Anfrage und unterscheide Transportfehler von HTTP-Antworten. Ein Timeout lässt das Ergebnis der Mutation unklar, daher den Status abfragen, bevor erneut versucht wird. Ein 429 Antwort ist explizites Server-Feedback, und der Client sollte den nächsten Versuch anhand der Header planen.

Für Capacitor-Deployments Capgo’s API-Richtlinien für Rate-Limiting zur App-Store-Konformität bieten einen relevanten operativen Referenzrahmen. Halte Credentials privat, respektiere Server-Header und mache Retries beobachtbar statt still.

Häufige API-Fehler beheben

Die meisten Fehler fallen in drei Gruppen: Authentifizierung, Validierung und Throttling. Diagnose die Gruppe, bevor du code änderst. Der Statuscode, der strukturierte Fehlerkörper und die relevanten Header liefern in der Regel genug Informationen, um die nächste Aktion zu wählen.

Authentifizierungsfehler

Ein 401 oder eine äquivalente Autorisierungsantwort bedeutet in der Regel, dass das Credential fehlt, fehlerhaft, abgelaufen, widerrufen ist oder mit dem falschen Schema gesendet wurde. Prüfe die Umgebungsvariable im tatsächlichen CI-Job, nicht nur in der lokalen Shell. Stelle sicher, dass die Anfrage das exakte Header-Format aus der aktuellen API-Dokumentierung enthält, und teste das Credential gegen eine read-only-Operation.

Wenn die Antwort auf unzureichende Berechtigungen statt auf eine ungültige Identität hinweist, behandle es als Autorisierungsproblem. Bitte einen Organisationsadministrator, den Scope, den App-Zugriff und die Umgebung des Keys zu überprüfen. Löse keine Berechtigungsfehler, indem du einen weitreichend privilegierten persönlichen Key verteilst.

Ungültige Request-Bodies

Eine Validierungsantwort bedeutet, dass der Server die Anfrage erhalten, aber ihre Struktur oder Werte abgelehnt hat. Vergleiche die Payload mit dem aktuellen Schema und achte auf Pflichtfelder, Typen, Enum-Werte, verschachtelte Objekte und Identifikatoren. Entferne nicht unterstützte Felder, anstatt zu hoffen, dass der Service sie ignoriert.

Logge eine redigierte Payload und die Feldfehler der Antwort. Füge Schema-Validierung in die CI ein, damit fehlerhafte Release-Metadaten scheitern, bevor ein Upload beginnt. Wenn die Operation ein Partial Update ist, stelle sicher, dass der Endpoint einen Patch-Body erwartet und keine vollständige Ersetzung.

Throttling und mehrdeutige Mutationen

Ein 429 bedeutet, dass der Worker aufhören muss, Anfragen zu senden, und die Retry-Anweisungen des Servers befolgen sollte. Beachte Retry-After wenn vorhanden, Jitter bei der Berechnung einer Fallback-Verzögerung und verhindere, dass mehrere parallele Worker gleichzeitig erneut versuchen.

Bei einem Timeout während des Uploads oder der Release-Erstellung: Sende keine weitere Mutation sofort ab. Suche oder hole die Operation über die client-generierte Build-Referenz oder den zurückgegebenen Identifikator, falls vorhanden. Wenn kein Identifikator verfügbar ist, frage den dokumentierten Support oder den Idempotency-Mechanismus von API, ob die ursprüngliche Anfrage abgeschlossen wurde. So vermeidest du doppelte Releases und machst den finalen Deployment-Verlauf vertrauenswürdig.

Capgo bietet eine öffentliche REST-API zur Verwaltung von App-Delivery-Ressourcen, Releases, Channels, Geräten und zugehörigen Deployment-Workflows, damit Teams Live-Update-Operationen an ihre bestehenden CI/CD- und Monitoring-Systeme anbinden können. Prüfen Sie die aktuelle Capgo Dokumentation lesen, ein Test-Credential mit minimalen Berechtigungen erstellen und einen vollständigen Release- sowie Rollback-Pfad validieren, bevor die Promotion in die Production automatisiert wird.