API-Übersicht

Mit der Seyval-API können Sie Repositories verwalten, Codeanalysen ausführen, Code ausführen und Integrationen programmatisch konfigurieren. Alle Endpunkte verwenden JSON über HTTPS.

Basis-URL

https://api.seyval.dev

Versionierung

Alle Ressourcen-Endpunkte haben das Präfix /v1. OAuth- und Discovery-Endpunkte sind nicht versioniert.

Authentifizierung

Die meisten Endpunkte erfordern ein Bearer-Token. Übergeben Sie es im Authorization-Header:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  https://api.seyval.dev/v1/repositories

Sie können API-Schlüssel über das Dashboard oder über die API-Schlüssel-Endpunkte erstellen und verwalten.

Antwortformat

Alle Antworten geben JSON zurück. Erfolgreiche Antworten verwenden Standard-HTTP-Statuscodes:

Code	Bedeutung
`200`	Erfolg
`201`	Ressource erstellt
`204`	Erfolg ohne Antwortkörper
`422`	Validierungsfehler

Fehlerantworten

Validierungsfehler geben einen 422-Status mit Details darüber zurück, welche Felder fehlgeschlagen sind:

{
  "detail": [
    {
      "loc": ["body", "field_name"],
      "msg": "description of the error",
      "type": "error_type"
    }
  ]
}

Welche Compute-Ressource ein Run genutzt hat

Zwei Felder beschreiben die Compute-Ressource eines Runs und beantworten unterschiedliche Fragen:

Feld	Beantwortete Frage
`compute_id`	Welches Ziel – `managed:<tier>` oder `byo:<uuid>`.
`compute_type`	Welche Art Maschine tatsächlich gelaufen ist.

Bei einem Managed-Run stimmen beide überein: Sie erhalten das angefragte Tier, also ist compute_type genau dieses Tier (gpu-h100). Bei einem BYO-Cluster nicht. compute_type nennt dann das GPU-Modell, das der Cluster selbst gemeldet hat – den GRES-Typ aus sinfo, etwa nvidia_gb200 – oder unknown, wenn der Cluster keines gemeldet hat. Es ist damit eine freie Zeichenkette, keine feste Wertemenge. Das compute_type, das Sie beim Starten eines Runs senden, bedeutet etwas anderes: Es ist die Anfrage und trägt bei einem BYO-Cluster ein Kompatibilitäts-Tier, aus dem die GPU-Anforderung abgeleitet wird. Anfragen und Aufzeichnen sind getrennte Werte und unterscheiden sich bei BYO.

Download-URLs

Endpunkte, die Dateiinhalte zurückgeben – Run-Logs (stdout_url / stderr_url) und Run-Artefakte (download_url) – liefern kurzlebige presigned URLs statt der Bytes selbst. Jede ist höchstens eine Stunde ab Ausstellung gültig, und Log-URLs werden aus einem Cache bedient, sodass die Restlaufzeit kürzer sein kann. Speichern Sie diese URLs nicht. Eine gespeicherte URL liefert später nur noch Request has expired. Speichern Sie stattdessen die run_id (und den Pfad des Artefakts) und fordern Sie eine neue URL an, wenn Sie die Datei brauchen:

# Neu ausstellen und im selben Schritt herunterladen
curl -sSL "$(curl -sS -H "Authorization: Bearer YOUR_API_KEY" \
  https://api.seyval.dev/v1/runs/RUN_ID | jq -r .stdout_url)" -o stdout.txt

Endpunktgruppen

Verwenden Sie die Seitenleiste, um alle verfügbaren Endpunkte nach Gruppen sortiert zu durchsuchen:

Repositories — Repositories registrieren, auflisten und verwalten
Repository-Dateien — Dateien innerhalb eines Repositories durchsuchen
Codeanalyse — Codeanalysen starten, überwachen und verwalten
Codeausführung — Code ausführen und Ausführungsergebnisse abrufen
Run-Streaming — Echtzeit-stdout/stderr-Logs über SSE streamen
API-Schlüssel — API-Schlüssel erstellen und widerrufen
Umgebungsvariablen — Umgebungsvariablen für die Ausführung verwalten
GitHub-Integration — GitHub-Repositories verbinden und verwalten
GitHub App Webhooks — Push- und Pull-Request-Ereignisse für automatisierte Analyse empfangen
OAuth 2.0 — Autorisierung, Tokens und Client-Registrierung

​Basis-URL

​Versionierung

​Authentifizierung

​Antwortformat

​Fehlerantworten

​Welche Compute-Ressource ein Run genutzt hat

​Download-URLs

​Endpunktgruppen