CoreDash API: Echte Core Web Vitals-Daten von Nutzern abfragen

Deine Performance-Daten, überall wo du sie brauchst

CoreDash sammelt Core Web Vitals von echten Nutzern, die deine Website besuchen. Die API gibt dir Zugriff auf dieselben Daten von jedem Tool, Skript oder KI-Agenten aus. Drei Tools, JSON rein, JSON raus.

Der interessanteste Anwendungsfall: Die Anbindung deiner KI. Die CoreDash API verwendet dasselbe Protokoll wie das Model Context Protocol (MCP), was bedeutet, dass KI-Tools wie Claude, Cursor und Windsurf deine echten Nutzerdaten direkt abfragen können. Frage deine KI "warum ist mein LCP auf Mobilgeräten langsam?" und sie ruft die tatsächlichen Felddaten ab, um zu antworten.

Wir haben CWV Superpowers darauf aufgebaut. Es ist ein KI-Agent, der deine CoreDash-Felddaten mit den Chrome DevTools kombiniert, um Core Web Vitals-Probleme zu diagnostizieren und zu beheben. Die API macht dies überhaupt erst möglich.

Aber du brauchst keinen KI-Agenten. Ein curl-Befehl funktioniert genauso gut.

Du leitest eine Agentur oder verwaltest viele Projekte über ein einziges Konto? Es gibt eine separate Agency API, die einen Master-Key verwendet, um Projekte zu erstellen, zu aktualisieren und zu löschen, und um Daten über alle hinweg mit einem einzigen Schlüssel abzurufen. Der Rest dieser Seite behandelt die projektbezogene Daten-API.

Authentifizierung

Jede Anfrage benötigt einen API-Schlüssel im Authorization-Header:

Authorization: Bearer cdk_YOUR_API_KEY

So erhältst du einen Schlüssel:

1. Melde dich unter app.coredash.app an
2. Gehe zu deinem Projekt, dann zu AI Insights, dann auf Connect Your AI
3. Klicke auf Create API Key und kopiere ihn. Er wird nur einmal angezeigt.

Schlüssel beginnen mit cdk_ und sind auf ein einzelnes Projekt beschränkt. Du kannst mehrere Schlüssel erstellen und diese auf derselben Seite widerrufen.

Anfrageformat

Die API verwendet JSON-RPC 2.0. Jede Anfrage ist ein POST an:

https://app.coredash.app/api/mcp

Der Request-Body sieht wie folgt aus:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_metrics",
    "arguments": { }
  }
}

Das Feld id kann eine beliebige Zahl oder ein String sein. Es wird in der Antwort unverändert zurückgegeben. Es gibt drei Tools: get_metrics, get_timeseries und get_histogram.

get_metrics: aktuelle Performance

Gibt die aktuellen Core Web Vitals-Werte mit den Bewertungen good/improve/poor zurück. Dies ist das Tool, das du für Fragen nach dem Motto "wie hoch ist mein LCP gerade?" verwendest.

Parameter

Beispiel: Alle Metriken abrufen

curl -X POST https://app.coredash.app/api/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer cdk_YOUR_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "get_metrics",
      "arguments": {}
    }
  }'

Die Rohantwort ist ein JSON-RPC-Wrapper:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{
      "type": "text",
      "text": "{ ... JSON string ... }"
    }]
  }
}

Die eigentlichen Daten sind ein JSON-String innerhalb des text-Feldes. Geparsed sieht es so aus:

{
  "period": "last 31 days",
  "percentile": "p75",
  "metrics": {
    "LCP": {
      "value": 2450,
      "unit": "ms",
      "rating": "improve",
      "distribution": { "good": 61.2, "improve": 22.4, "poor": 16.4 }
    },
    "INP": {
      "value": 180,
      "unit": "ms",
      "rating": "good",
      "distribution": { "good": 82.1, "improve": 12.3, "poor": 5.6 }
    },
    "CLS": {
      "value": 0.08,
      "unit": "",
      "rating": "good",
      "distribution": { "good": 74.5, "improve": 18.2, "poor": 7.3 }
    }
  }
}

Das distribution-Objekt gibt an, wie viel Prozent der echten Seitenaufrufe in die jeweilige Bewertung fallen. Dies ist oft nützlicher als der p75-Wert allein. Ein LCP von 2450ms bei 61% 'good' bedeutet, dass die meisten Nutzer eine gute Erfahrung haben, aber das Ende der Verteilung (Tail) den p75 nach unten zieht.

Beispiel: LCP auf Mobilgeräten vs. Desktop vergleichen

Nutze den group-Parameter, um die Ergebnisse nach einer beliebigen Dimension aufzuteilen. So findest du heraus, ob dein LCP-Problem ein mobiles Problem ist:

curl -X POST https://app.coredash.app/api/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer cdk_YOUR_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "get_metrics",
      "arguments": {
        "metrics": "LCP",
        "group": "d",
        "date": "-7d"
      }
    }
  }'

Geparsede Antwort:

{
  "period": "last 7 days",
  "percentile": "p75",
  "groupedBy": "d",
  "groupName": "Device Type",
  "segments": [
    {
      "segment": "mobile",
      "value": "mobile",
      "metrics": {
        "LCP": {
          "value": 3200, "unit": "ms", "rating": "improve",
          "distribution": { "good": 52.3, "improve": 28.1, "poor": 19.6 }
        }
      }
    },
    {
      "segment": "desktop",
      "value": "desktop",
      "metrics": {
        "LCP": {
          "value": 1800, "unit": "ms", "rating": "good",
          "distribution": { "good": 78.5, "improve": 15.2, "poor": 6.3 }
        }
      }
    }
  ]
}

Mobil bei 3200ms, Desktop bei 1800ms. Der aggregierte Wert würde 2500ms anzeigen und du würdest denken "nicht großartig, aber auch nicht schrecklich". Die gruppierte Ansicht zeigt die wahre Situation: Desktop ist in Ordnung, bei Mobilgeräten besteht Handlungsbedarf.

Beispiel: Auf eine bestimmte Seite für Mobilgeräte filtern

Kombiniere filters, um die Daten auf genau den Traffic einzugrenzen, der dich interessiert:

curl -X POST https://app.coredash.app/api/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer cdk_YOUR_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "get_metrics",
      "arguments": {
        "metrics": "LCP,CLS",
        "filters": { "ff": "/checkout", "d": "mobile" },
        "date": "-7d"
      }
    }
  }'

get_timeseries: Performance im Zeitverlauf

Gibt Metrikwerte im zeitlichen Verlauf mit automatischer Trenderkennung zurück. Dies ist das Tool, das du für Fragen wie "Hat sich mein LCP verschlechtert?" und "Hat dieses Deployment die Regression behoben?" verwendest.

Parameter

Beispiel: LCP-Trend der letzten 7 Tage

curl -X POST https://app.coredash.app/api/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer cdk_YOUR_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": 4,
    "method": "tools/call",
    "params": {
      "name": "get_timeseries",
      "arguments": {
        "metrics": "LCP",
        "date": "-7d",
        "granularity": "day"
      }
    }
  }'

Geparsede Antwort:

{
  "period": "last 7 days",
  "percentile": "p75",
  "granularity": "day",
  "dataPoints": 7,
  "timeseries": [
    { "date": "2026-03-10T00:00:00.000Z", "LCP": { "value": 2600, "unit": "ms", "rating": "improve" } },
    { "date": "2026-03-11T00:00:00.000Z", "LCP": { "value": 2450, "unit": "ms", "rating": "improve" } },
    { "date": "2026-03-12T00:00:00.000Z", "LCP": { "value": 2300, "unit": "ms", "rating": "good" } }
  ],
  "summary": {
    "LCP": {
      "recent": 2350,
      "previous": 2680,
      "change": -12.3,
      "trend": "improving",
      "unit": "ms"
    }
  }
}

Die summary vergleicht die zweite Hälfte des Zeitraums mit der ersten Hälfte. Trendwerte sind improving (mehr als 5% besser), stable (innerhalb von 5%) oder regressing (mehr als 5% schlechter). Genau das macht den Timeseries-Endpunkt so nützlich für automatisiertes Monitoring: Du musst die Datenpunkte nicht selbst analysieren, um zu wissen, ob sich die Werte verschlechtern.

get_histogram: Verteilungsform

Gibt die Verteilung einer einzelnen Metrik in ~40 Buckets mit Anzahlen pro Bereich zurück. Dies ist das Tool, das du verwendest, wenn der p75 gut aussieht, du aber einen langen Ausläufer (Long Tail) vermutest oder wenn du die vollständige Form deiner Performance-Daten sehen möchtest.

Parameter

Hinweis: Im Gegensatz zu get_metrics erwartet dies eine einzelne metric (nicht metrics). Eine Metrik pro Anfrage.

Beispiel: LCP-Verteilung auf Mobilgeräten

curl -X POST https://app.coredash.app/api/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer cdk_YOUR_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": 5,
    "method": "tools/call",
    "params": {
      "name": "get_histogram",
      "arguments": {
        "metric": "LCP",
        "filters": { "d": "mobile" },
        "date": "-7d"
      }
    }
  }'

Geparsede Antwort:

{
  "period": "last 7 days",
  "metric": "LCP",
  "unit": "ms",
  "filters": { "d": "mobile" },
  "buckets": [
    { "from": 0, "to": 250, "count": 1250, "rating": "good" },
    { "from": 250, "to": 500, "count": 3400, "rating": "good" },
    { "from": 500, "to": 750, "count": 2800, "rating": "good" },
    { "from": 2500, "to": 2750, "count": 890, "rating": "improve" },
    { "from": 4000, "to": 4250, "count": 120, "rating": "poor" },
    { "from": 9750, "to": null, "count": 15, "rating": "poor" }
  ],
  "total": 45000
}

Jeder Bucket hat from/to-Grenzen, einen count der geschätzten Seitenaufrufe in diesem Bereich und ein rating basierend darauf, wo sich der Bucket im Verhältnis zu den Core Web Vitals-Schwellenwerten befindet. Der letzte Bucket hat to: null, da er das nach oben offene Ende der Verteilung darstellt.

Die Bucket-Breiten sind pro Metrik fest definiert: LCP verwendet 250ms, INP verwendet 25ms, CLS verwendet 0.025, FCP verwendet 200ms, TTFB verwendet 125ms.

Dies ist nützlich, um die Form deiner Daten zu verstehen. Ein p75 von 2400ms könnte bedeuten, dass die meisten Nutzer bei etwa 2400ms liegen, oder es könnte bedeuten, dass 60% unter 1000ms liegen und ein Teil des langsamen mobilen Traffics den Wert nach oben zieht. Das Histogramm zeigt dir, welcher Fall vorliegt.

Dimensionen

Verwende diese Schlüssel in filters oder als group-Wert. Durch Filtern werden die Daten auf ein bestimmtes Segment eingegrenzt. Die Gruppierung teilt die Ergebnisse auf, sodass du Segmente direkt miteinander vergleichen kannst.

Allgemein

Gerät und Netzwerk

Metrik-Attribution

Diese Dimensionen verraten dir, was einen Metrikwert verursacht hat. Gruppiere nach lcpel, um zu sehen, welche Elemente auf deinen Seiten das LCP werden. Gruppiere nach inpel, um die Interaktionen zu finden, die das schlechteste INP erzeugen.

Filterbeispiele

{ "d": "mobile" }
{ "ff": "/checkout", "d": "desktop" }
{ "cc": "US", "browser": "Chrome" }
{ "u": "[neq]*/admin/*" }

Metrik-Referenz

Das Standard-Perzentil ist p75. Das ist der Wert, den Google für das Core Web Vitals-Ranking verwendet. Wenn 75% deiner Seitenaufrufe unter dem Schwellenwert liegen, bestehst du.

Die API als MCP-Server nutzen

Der API-Endpunkt ist ein vollständig kompatibler MCP-Server. Wenn dein KI-Tool MCP unterstützt (Claude Code, Cursor, Windsurf und andere), kannst du es direkt anbinden. Die KI hat dann Zugriff auf get_metrics, get_timeseries und get_histogram als Tools und kann deine Felddaten im Rahmen jeder Konversation abfragen.

So funktioniert CWV Superpowers: Es verbindet sich über MCP mit CoreDash, ruft deine echten Nutzerdaten ab, öffnet deine Website in Chrome und spürt die genaue Ursache einer langsamen Metrik auf. Die API liefert den Teil "Was passiert in der Produktion", Chrome liefert den Teil "Warum passiert es".

Du kannst den MCP-Server auch mit deinem eigenen KI-Setup verbinden. Richte deinen MCP-Client mit deinem API-Schlüssel auf https://app.coredash.app/api/mcp aus, und deine KI kann Fragen wie "Welche Seiten haben das schlechteste INP auf Mobilgeräten?" mit tatsächlichen Felddaten beantworten, anstatt zu raten.

Rate Limits

Die Limits gelten pro Projekt und Tag und werden um Mitternacht UTC zurückgesetzt.

150 Anfragen im Trial-Plan sind mehr als genug für die manuelle Analyse und das KI-gestützte Debugging. Wenn du automatisiertes Monitoring in der CI betreibst, bieten dir die kostenpflichtigen Pläne 500 Anfragen pro Tag.

Fehlerbehandlung

Fehler werden als JSON-RPC-Fehlerobjekte zurückgegeben:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": { "code": -32001, "message": "Invalid or revoked API key." }
}

Wenn du -32001 erhältst, überprüfe, ob dein Schlüssel mit cdk_ beginnt und dass du ihn nicht widerrufen hast. Wenn du -32002 erhältst, hast du das Tageslimit erreicht. Warte auf den Reset um Mitternacht UTC oder führe ein Upgrade deines Plans durch.