Skip to main content
Die Public API (V2) ist eine REST-API zum Lesen von Anwendungsrohdaten: Metriken, Traces, Logs, Kubernetes-Metriken und Deploy-Statistiken. Sie ergänzt die GraphQL-API, die Modelle wie Apps, Incidents, Dashboards und Alerts verwaltet. Als Faustregel gilt: Verwenden Sie die REST-API zum Lesen von Daten und die GraphQL-API zur Verwaltung der Konfiguration.
Wenn Sie einen KI-Agenten oder Assistenten erstellen, stellt AppSignal MCP diese Daten direkt für Agenten bereit — möglicherweise müssen Sie diese API gar nicht selbst aufrufen.

Basis-URL

Alle Endpunkte werden unter /api/v2 auf der Domain appsignal.com bereitgestellt:

Authentifizierung

Anfragen werden mit Ihrem persönlichen API-Token authentifiziert, das entweder als Bearer-Token oder als Query-Parameter übergeben wird. Sie finden Ihr Token im Bildschirm für persönliche Einstellungen.
Ihr Token gewährt Zugriff auf dieselben Sites und Organisationen, die Sie in AppSignal sehen. Die meisten Anfragen sind auf eine einzelne site_id begrenzt; Tracing-Endpunkte verwenden ein site_ids-Array, sodass sie über mehrere Sites hinweg suchen können. Die API prüft, dass Ihr Token Zugriff auf jede angeforderte Site hat, bevor Daten zurückgegeben werden. Um ein Token selbst zu überprüfen, rufen Sie GET /api/v2/auth auf. Ihre site_id ist die ID in der URL Ihrer App: https://appsignal.com/<organization>/sites/<SITE_ID>. Für Log-Abfragen benötigen Sie außerdem eine Log-Quellen-ID — siehe Site- und Quellen-IDs finden.

Ein Token überprüfen

Gibt ein JSON-Objekt mit einer message zurück, die die authentifizierte User-ID bestätigt.

Anfragen und Antworten

Die meisten Endpunkte verwenden POST mit einem JSON-Body und geben JSON zurück. Reine Lese-Lookups (etwa das Auflisten von Metriknamen) verwenden GET mit Pfadparametern. Setzen Sie bei Anfragen mit Body Content-Type: application/json. Zeitangaben sind ISO-8601-Strings. Die meisten Abfrage-Bodies nehmen einen from- und to-Zeitbereich entgegen sowie entweder eine site_id oder, bei Tracing-Endpunkten, ein site_ids-Array. Eine vollständige, automatisch generierte Referenz aller Endpunkte, Anfragen und Antworttypen finden Sie in der REST-API-Referenz.

Fehlerantworten

Jeder Endpunkt kann diese Nicht-2xx-Antworten zurückgeben:

422-Envelope

Jede 422-Antwort verwendet denselben Envelope, sodass Sie sie an einer Stelle behandeln können:
  • error: ein stabiles, maschinenlesbares Slug. Verzweigen Sie in Ihrem Code darauf.
  • message: eine menschenlesbare Nachricht, sicher zur Anzeige.
  • details: ein optionales Objekt, dessen Form von error abhängt.
Ein Slug, dem Sie begegnen können, ist legacy_log_query_syntax. Er wird zurückgegeben, wenn eine Logs-Abfrage die alte attributes.<name>_<type>-Syntax verwendet. Siehe Logs abfragen für die aktuelle Abfragesprache.

Endpunkte

Metriken

Siehe die Metriken-Referenz.

Tracing

Siehe die Tracing-Referenz.

Logs

Siehe die Logs-Referenz.

Kubernetes

Siehe die Kubernetes-Referenz.

Deploys

Siehe die Deploys-Referenz.

Check-ins

Siehe die Check-ins-Referenz.

Gespeicherte Visuals

Endpunkte für gespeicherte Visuals erfordern keine Authentifizierung. Siehe die Referenz für gespeicherte Visuals.

System