Aperçu de l'API

L’API Seyval vous permet de gérer des dépôts, d’exécuter des analyses de code, d’exécuter du code et de configurer des intégrations de manière programmatique. Tous les endpoints utilisent JSON sur HTTPS.

URL de base

https://api.seyval.dev

Versionnage

Tous les endpoints de ressources sont préfixés par /v1. Les endpoints OAuth et de découverte ne sont pas versionnés.

Authentification

La plupart des endpoints nécessitent un token Bearer. Transmettez-le dans l’en-tête Authorization :

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

Vous pouvez créer et gérer vos clés API depuis le tableau de bord ou via les endpoints de clés API.

Format de réponse

Toutes les réponses renvoient du JSON. Les réponses réussies utilisent les codes de statut HTTP standard :

Code	Signification
`200`	Succès
`201`	Ressource créée
`204`	Succès sans corps de réponse
`422`	Erreur de validation

Réponses d’erreur

Les erreurs de validation renvoient un statut 422 avec des détails sur les champs en échec :

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

Quel calcul une exécution a utilisé

Deux champs décrivent le calcul d’une exécution et répondent à des questions différentes :

Champ	Question à laquelle il répond
`compute_id`	Quelle cible — `managed:<tier>` ou `byo:<uuid>`.
`compute_type`	Quel type de machine a réellement exécuté le run.

Pour une exécution managée, les deux concordent : vous obtenez le tier demandé, donc compute_type est ce tier (gpu-h100). Sur un cluster BYO, non. compute_type indique alors le modèle de GPU que le cluster a lui-même annoncé — le type GRES de sinfo, par exemple nvidia_gb200 — ou unknown si le cluster n’en a annoncé aucun. C’est donc une chaîne libre, pas un ensemble fixe de valeurs. Le compute_type que vous envoyez au démarrage d’une exécution signifie autre chose : c’est ce que vous demandez, et sur un cluster BYO il porte un tier de compatibilité servant à déduire la demande de GPU. Demander et enregistrer sont deux valeurs distinctes, et elles diffèrent en BYO.

URLs de téléchargement

Les endpoints qui renvoient le contenu de fichiers — les journaux d’une exécution (stdout_url / stderr_url) et ses artefacts (download_url) — renvoient des URLs présignées à durée de vie courte plutôt que les octets eux-mêmes. Chacune est valable au plus une heure à compter de son émission, et les URLs de journaux proviennent d’un cache : la durée restante peut donc être plus courte. Ne conservez pas ces URLs. Une URL enregistrée ne renverra plus que Request has expired. Conservez plutôt le run_id (et le chemin du fichier), puis demandez une nouvelle URL au moment où vous avez besoin du fichier :

# Réémettre puis télécharger dans la même étape
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

Groupes d’endpoints

Utilisez la barre latérale pour parcourir tous les endpoints disponibles, organisés par groupe :

Dépôts — enregistrer, lister et gérer les dépôts
Fichiers de dépôt — parcourir les fichiers d’un dépôt
Analyse de code — démarrer, surveiller et gérer les analyses de code
Exécution de code — exécuter du code et récupérer les résultats d’exécution
Streaming d’exécution — diffuser les logs stdout/stderr en temps réel via SSE
Clés API — créer et révoquer des clés API
Variables d’environnement — gérer les variables d’environnement pour l’exécution
Intégration GitHub — connecter et gérer les dépôts GitHub
GitHub App Webhooks — recevoir les événements push et pull request pour l’analyse automatisée
OAuth 2.0 — autorisation, tokens et enregistrement de clients

​URL de base

​Versionnage

​Authentification

​Format de réponse

​Réponses d’erreur

​Quel calcul une exécution a utilisé

​URLs de téléchargement

​Groupes d’endpoints