Accès développeur
Tout ce que fait la console, tu peux le faire depuis du code.
L'API Sarpius est publique et documentée : 72 routes, 98 opérations et 20 scopes OAuth, publiés en OpenAPI. Construis dessus, pilote-la depuis ta CI, ou laisse un assistant IA gérer ton projet. Mêmes permissions, peu importe qui appelle.
Il n'y a aucun frais par appel API. Tu payes pour ce que les appels créent.
Commence ici
Obtiens un jeton, fais un appel.
Deux identifiants, selon qui appelle. Les deux portent des scopes, et les deux sont refusés de la même façon quand ils sont incorrects.
Une personne, ou une app en son nom
OAuth2 standard. Enregistre un client, envoie l'utilisateur à travers l'étape d'autorisation, échange le code contre un jeton, et rafraîchis-le ou révoque-le plus tard. L'introspection te dit ce qu'un jeton porte encore.
Ta CI, sans personne qui surveille
Une clé API sur ton compte. Crée-la, utilise-la, supprime-la quand le pipeline est mis à la retraite. Aucune étape navigateur au milieu d'un flux automatisé.
curl -H "Authorization: Bearer $TOKEN" \
https://sarpius.eu/api/v1/projectsRéponse, sans jeton valide :
401 {"message":"Invalid token"}Ces deux premiers sont publics. Tu peux lire le contrat avant même d'avoir un compte.
Trois façons d'y accéder
Même API, mêmes permissions, peu importe qui appelle.
Ton propre code
OpenAPI décrit chaque endpoint, donc un client se génère lui-même. Projets, composants, déploiements, bases de données, stockage, domaines et le portefeuille sont tous dans le même document.
Ta CI
Un push déclenche déjà le déploiement, mais quand tu veux le piloter toi-même, les opérations sont là : déclencher un déploiement, lire son log, revenir en arrière, démarrer et arrêter.
Un assistant IA
Connecte Sarpius via MCP et un assistant travaille directement sur le projet. Chaque outil est lié à une opération API réelle, il ne peut donc rien atteindre que l'API n'expose pas déjà.
En pratique
D'un compte vide à une app en cours d'exécution, sans ouvrir la console.
- Crée un projet.
- Connecte un dépôt, ou démarre depuis un modèle.
- Crée une base de données et relie-la au composant qui en a besoin.
- Définis les variables pour chaque environnement.
- Ajoute un domaine et laisse le certificat s'émettre.
- Déploie, et lis le log de build pendant qu'il s'exécute.
- Quand tu as fini, retire le tout à nouveau.
Garde-fous
La partie intéressante, c'est ce qu'elle ne te laissera pas faire.
Ouvrir une plateforme aux scripts et aux agents n'a de valeur que si les limites sont réelles. Chacune d'elles est dans le code, pas dans un document de politique.
Des scopes, pas une clé maîtresse
20 scopes, et un jeton ne porte que ce qui lui a été délivré. Lire une app et changer sa façon de builder sont délibérément des permissions différentes.
Les secrets restent secrets
Les valeurs d'environnement reviennent masquées à tout ce qui n'est pas une session navigateur. Un agent voit la forme de ta configuration et jamais les valeurs.
Supprimer demande toujours ton second facteur
Un jeton ne peut pas retirer un projet ou un composant seul. Avec la double authentification activée sur ton compte, l'appel est refusé jusqu'à ce que tu fournisses le code.
Les limites de débit s'appliquent à tout le monde
Chaque appelant reçoit un budget par adresse et un second par identifiant en plus. Un client automatisé ne peut pas dépasser un humain.
Les commandes de build ont leur propre permission
Les champs de build s'exécutent tels quels avec tes secrets déchiffrés dans l'environnement, ils sont donc placés derrière un scope propre qu'aucun jeton déjà délivré ne possède.
Tu peux annuler ce que tu crées
Tout ce qu'un jeton peut créer, un jeton peut aussi le retirer : projets, composants, domaines, bases de données, buckets. Un chemin de création sans démolition est un cliquet, et ça facture de l'argent réel.
Commence par la référence.
Le document OpenAPI, le catalogue des scopes et le guide de connexion MCP sont tous dans la documentation.