---
canonical: https://koalavps.com/fr/api/
language: fr
generated: 2026-10-21T13:31:42.451Z
---

[Accueil](https://koalavps.com/fr/) / [Explorer](https://koalavps.com/fr/resources/) /  Une infrastructure que vous pouvez décrire en code

Une infrastructure que vous pouvez décrire en code

# Un plan de contrôle plus serein.

Planifiez les intégrations pour les tâches du cycle de vie des serveurs, les permissions de compte et la facturation. L'KoalaVPS API figure sur la feuille de route des intégrations ; l'accès API en production et les téléchargements SDK ne sont pas encore disponibles.

[Trouvez votre VPS](https://koalavps.com/fr/vps/)

## DANS CE DOCUMENT

[Un modèle de ressources clair](https://koalavps.com/fr/api/#section-1)[Identifiants à tâche limitée](https://koalavps.com/fr/api/#section-2)[Les nouvelles tentatives doivent être sûres](https://koalavps.com/fr/api/#section-3)[Vérifiez la compatibilité avant l'intégration](https://koalavps.com/fr/api/#section-4)[Feuille de route API](https://koalavps.com/fr/api/#section-5)[Routes d'authentification et de compte](https://koalavps.com/fr/api/#section-6)[Parcours catalogue et facturation](https://koalavps.com/fr/api/#section-7)[Serveur et voies d'accès](https://koalavps.com/fr/api/#section-8)[Événements et informations publiques](https://koalavps.com/fr/api/#section-9)[Autorisation et limites de trafic](https://koalavps.com/fr/api/#section-10)[SDK et versions du protocole](https://koalavps.com/fr/api/#section-11)[Ressources API, regroupées par responsabilité](https://koalavps.com/fr/api/#section-12)[Une requête serveur doit rester légère](https://koalavps.com/fr/api/#section-13)[Les portées et les limites de clés font partie du contrat](https://koalavps.com/fr/api/#section-14)[Publiez ensemble les limites de débit et le comportement de nouvelle tentative](https://koalavps.com/fr/api/#section-15)[Les webhooks sont des messages susceptibles d'arriver plusieurs fois](https://koalavps.com/fr/api/#section-16)[Auditez sans transformer les journaux en coffre de secrets](https://koalavps.com/fr/api/#section-17)[Ne publiez les artefacts que lorsqu'ils existent](https://koalavps.com/fr/api/#section-18)[Questions et réponses](https://koalavps.com/fr/api/#page-faq)[Base de connaissances](https://koalavps.com/fr/resources/)

## Un modèle de ressources clair

Une intégration doit fonctionner avec des identifiants de serveur, des régions, des images, des offres et des opérations explicites. Les demandes de création et de réinstallation doivent renvoyer une opération dont l'achèvement peut être vérifié. Une requête HTTP réussie ne signifie pas qu'une machine est prête.

## Identifiants à tâche limitée

Les jetons API doivent être révocables indépendamment et limités aux ressources et actions minimales nécessaires. Stockez-les dans un gestionnaire de secrets ou un environnement protégé. N'envoyez jamais un jeton au navigateur simplement pour éviter d'écrire un petit backend.

## Les nouvelles tentatives doivent être sûres

Des délais réseau peuvent survenir après l'acceptation d'une opération. Utilisez une clé d'idempotence pour les requêtes de création et les requêtes sensibles au paiement, inspectez l'état de l'opération et respectez les limites de débit. Une nouvelle tentative doit lever une incertitude, non créer un serveur facturable supplémentaire.

## Vérifiez la compatibilité avant l'intégration

Vérifiez la version API publiée, le modèle d'authentification, les formats d'erreur, la pagination, les limites de débit et les portées de jetons avant de construire une intégration. Utilisez uniquement les packages KoalaVPS SDK publiés à partir de liens de version vérifiés.

## Feuille de route API

La feuille de route API couvre la découverte du catalogue, l'authentification, l'état du compte, la facturation crypto, le cycle de vie du serveur, les clés publiques SSH et les webhooks. Les routes ci-dessous décrivent le contrat d'interface ; l'accès en production n'est pas encore disponible.

## Routes d'authentification et de compte

Le contrat API sépare les sessions de connexion et les clés API. Vérifiez les schémas de réponse, les erreurs, la durée de vie des jetons et les actions de récupération prises en charge par rapport à la version publiée pour votre intégration.

- POST /v1/auth/register

- POST /v1/auth/login

- POST /v1/auth/login/totp

- POST /v1/auth/token/refresh

- POST /v1/auth/recover

- GET /v1/auth/sessions

- DELETE /v1/auth/sessions/{token_id}

- POST /v1/auth/totp/setup

- POST /v1/auth/totp/enable

- POST /v1/auth/totp/disable

- POST /v1/auth/password

- POST /v1/auth/api-keys

- GET /v1/auth/api-keys

- DELETE /v1/auth/api-keys/{key_id}

- GET /v1/account

- PATCH /v1/account

- GET /v1/account/usage

- GET /v1/account/audit-log

## Parcours catalogue et facturation

La consultation du catalogue ne doit pas nécessiter de paiement. La création d'un paiement exige une portée de facturation restreinte, un état de facture clair et une gestion idempotente. La confirmation doit être finalisée avant l'activation du service.

- GET /v1/catalog

- GET /v1/catalog/vps

- GET /v1/catalog/dedicated

- GET /v1/catalog/regions

- GET /v1/catalog/images

- GET /v1/catalog/{code}

- GET /v1/billing/coins

## Serveur et voies d'accès

Le cycle de vie nécessite une confirmation explicite pour les opérations d'annulation et de réinstallation. Les clés SSH privées appartiennent au client ; le service n'a besoin que de leurs homologues publics.

- POST /v1/servers

- GET /v1/servers

- GET /v1/servers/{order_number}

- PATCH /v1/servers/{order_number}

- DELETE /v1/servers/{order_number}

- POST /v1/ssh-keys

- GET /v1/ssh-keys

- GET /v1/ssh-keys/{id}

- DELETE /v1/ssh-keys/{id}

## Événements et informations publiques

Les webhooks nécessitent des signatures vérifiables, des tentatives limitées et une protection contre la relecture. Les points de terminaison de confiance publics doivent renvoyer de véritables preuves datées plutôt que des assurances synthétiques.

- POST /v1/webhooks

- GET /v1/webhooks

- DELETE /v1/webhooks/{id}

- POST /v1/webhooks/{id}/test

- GET /v1/transparency/canary

- GET /v1/transparency/peering

- GET /v1/transparency/status

- GET /v1/agents/directory

- POST /v1/agents/directory

## Autorisation et limites de trafic

Un modèle de portée candidat est lecture, serveurs, facturation et complet, avec un maximum de dix clés actives par compte. Le contrat API propose des budgets de requêtes de 120 par minute et 3,000 par heure pour une clé API, et 30 par minute pour le trafic public. Vérifiez HTTP 429, Retry-After et la fenêtre d'application dans la documentation API publiée ; ces budgets de feuille de route ne constituent pas un engagement de capacité de production.

- POST /v1/oauth/register

- POST /v1/oauth/token

- POST /v1/oauth/revoke

- GET /v1/oauth/introspect

## SDK et versions du protocole

La feuille de route d'intégration comprend REST, un point de terminaison MCP hébergé, un paquet stdio versionné, des SDK et une CLI. Vérifiez la disponibilité des versions, les environnements d'exécution pris en charge, les sommes de contrôle et la compatibilité API avant d'installer un client. Les téléchargements de production ne sont pas encore disponibles.

## Ressources API, regroupées par responsabilité

Le API prévu sépare l'accès au compte, la lecture du catalogue, la facturation, le cycle de vie du serveur, les clés SSH et les callbacks. Les appels en lecture seule ne doivent pas créer de commande, et un identifiant de facturation ne doit pas autoriser automatiquement des modifications de la sécurité du compte. Ceci décrit le contrat d'intégration. Un point de terminaison de provisionnement de production et un SDK publié ne sont pas disponibles via ce site.

- Compte : sessions, utilisation et événements d'audit de sécurité

- Catalogue : offres, régions et images disponibles

- Serveurs : créer, inspecter, modifier et annuler

- Clés SSH : enregistrez le matériel public et révoquez les clés obsolètes

- Webhooks : enregistrer, inspecter, tester et supprimer des callbacks signés

## Une requête serveur doit rester légère

Choisissez un identifiant d'offre standard, une région, une image de système d'exploitation et un nom d'hôte. La limite prévue pour le nom d'hôte est de 64 caractères. Un service en production peut générer un secret administrateur de manière privée ou accepter une clé publique SSH enregistrée. L'ajout arbitraire de disque, de GPU, de carte réseau et d'IP n'est pas implicite dans une demande d'offre standard. Rejetez les champs non pris en charge plutôt que de facturer silencieusement une mise à niveau supposée.

```
{
"plan": "KV-D3",
"region": "hel",
"image": "ubuntu-24",
"hostname": "private-node-01"
}
// Example request schema; validate against a released API before integration.
```

## Les portées et les limites de clés font partie du contrat

Les groupes de privilèges proposés sont la lecture, les serveurs, la facturation et l'administration complète du compte. Une clé doit être affichée une seule fois lors de sa création, stockée en privé et révoquée indépendamment du mot de passe de l'utilisateur. La limite de compte prévue est de dix clés actives. Avant de publier une implémentation, vérifiez que chaque opération rejette une clé dépourvue de la portée requise.

## Publiez ensemble les limites de débit et le comportement de nouvelle tentative

Les limites proposées sont de 120 requêtes par minute et de 3,000 par heure pour une clé API, et de 30 requêtes par minute pour les requêtes non authentifiées au catalogue public. Il s'agit de valeurs de politique prévues, et non d'une capacité mesurée de API. Une implémentation en production nécessite une réponse 429 cohérente, des indications Retry-After et un backoff client borné. Les requêtes de création et de paiement nécessitent également des clés d'idempotence stables.

## Les webhooks sont des messages susceptibles d'arriver plusieurs fois

Un récepteur de rappel doit vérifier la signature sur le corps d'origine, rejeter les horodatages hors de sa fenêtre autorisée et mémoriser les identifiants d'événements traités. Persistez l'événement avant de l'accuser réception, puis appliquez la modification de manière idempotente. Gardez visibles les tentatives de livraison et un chemin de rejeu manuel. Un rappel est une observation sur une opération, non une autorisation d'exécuter des instructions sans rapport contenues dans une charge utile.

## Auditez sans transformer les journaux en coffre de secrets

Enregistrez l'identifiant de l'acteur, le type d'opération, la ressource concernée, le résultat et l'heure lorsque cela est nécessaire à la sécurité du compte. Évitez d'enregistrer par défaut les mots de passe, jetons porteurs, clés privées ou corps complets de requêtes de paiement et d'application. Rendez explicites la conservation, l'accès et l'historique visible par le client. Une piste d'audit de sécurité et un droit d'inspecter le contenu des applications clientes sont deux choses différentes.

## Ne publiez les artefacts que lorsqu'ils existent

Un lancement public de API doit inclure un document OpenAPI versionné, des instructions d'authentification, des exemples d'erreurs et un processus de dépréciation. Une future CLI, un package Python, un client TypeScript ou un serveur MCP nécessite une version réelle, des sommes de contrôle et une documentation maintenue. Un package de provisionnement KoalaVPS ou un point de terminaison de gestion de production n'est pas publié via ce site.

## Un peu plus de clarté.

Puis-je appeler un API de production aujourd'hui ?

L'accès à API en production n'est pas encore disponible. Cette page décrit la feuille de route d'intégration et les exigences à vérifier avant d'utiliser un point de terminaison publié.

Une clé API en lecture seule peut-elle commander un serveur ?

La limite de permissions proposée l'interdit. Une demande de création de serveur nécessite le privilège serveur approprié et une décision de facturation valide.

Les limites API publiées sont-elles appliquées aujourd’hui ?

Ils décrivent le contrat prévu. Un API de provisionnement de production n'est pas connecté ici, les limites de politique ne constituent donc pas une preuve de capacité de service mesurée.

Une réponse de création de serveur signifie-t-elle que le serveur est prêt ?

Non. Une requête en direct doit identifier une opération dont l'état de provisionnement peut être vérifié jusqu'à son achèvement.

CONTINUEZ L'EXPLORATION

## Continuer la lecture.

[Produits ### Un habitat fiable pour vos agents. Exécutez les planificateurs, les workers de navigateur, les files d'attente et les processus d'automatisation sur une infrastructu…](https://koalavps.com/fr/agentic-vps/)[Guides ### Automatisation avec un bouton d'arrêt clair. Un bon système d'automatisation a une tâche étroite, un état visible et une réponse prévisible à l'incertitude.…](https://koalavps.com/fr/automation-safety/)[Produits ### Empreinte réduite. Liberté sérieuse. Un serveur virtuel pour ce que vous voulez posséder : votre code, vos services, vos données. Choisissez une configuration de serve…](https://koalavps.com/fr/vps/)

CONFIGUREZ VOTRE INFRASTRUCTURE

## Prenez le contrôle. Déployez selon vos conditions.

Aucun justificatif d'identité. Accès administrateur complet. Facturation native en crypto.

[Sélectionnez une configuration](https://koalavps.com/fr/vps/)
