État du service et disponibilité Facturation crypto uniquement · Inscription sans KYC

Référence API

Utilisez les opérations API et interprétez leurs résultats

Lisez les points de terminaison disponibles, les règles d'idempotence, les réponses d'action en file d'attente et les limites actuelles sur le suivi des opérations.

Tungsto documentation · Mis à jour · 3 min de lecture

Sur cette page
  1. Avant de commencer
  2. Lisez le compte avant de le modifier
  3. Utilisez le point de terminaison de changement correspondant
  4. Rendre les nouvelles tentatives délibérées
  5. Distinguer l'acceptation de l'achèvement
  6. Répondez aux pannes sans dupliquer le travail
  7. Ressources associées

Avant de commencer

  • Une session valide et, pour les modifications protégées, son jeton CSRF.
  • Identifiants tirés du catalogue actuel ou de réponses API authentifiées.
  • Une clé d'idempotence unique pour chaque commande, retrait ou action matérielle.

Lisez le compte avant de le modifier

Utilisez les points de terminaison de lecture pour confirmer le compte, le solde et la ressource cible. GET /api/v1/me renvoie le nom d'utilisateur, balanceUsd et le csrfToken de la session. Les identifiants de ressource sont spécifiques au compte ; utilisez l'identifiant du serveur ou du réseau renvoyé pour le compte actuel plutôt que de copier une valeur d'un autre environnement.

Le API actuel est une interface de compte compacte, pas une plateforme complète de tâches asynchrones. Enregistrez les références des écritures réussies dans vos propres dossiers. Il n'y a pas de point de terminaison pour lister chaque commande, inspecter une action en file d'attente spécifique ou récupérer le dernier état d'examen d'un retrait.

Point de terminaison de lectureDonnées renvoyées
GET /api/v1/ledgerLes dernières entrées du grand livre 100, les plus récentes en premier ; aucun contrat de pagination.
GET /api/v1/serversServeurs non terminés, état, région, payé jusqu'au, grâce jusqu'au et renouvellement automatique.
GET /api/v1/networkAdresses attribuées, longueurs de préfixe, valeurs PTR et identifiants de serveur associés.
GET /api/healthComptes de service de base et de catalogue ; aucune garantie de compte ou de santé du serveur physique.

Utilisez le point de terminaison de changement correspondant

Les actions de serveur prises en charge sont reboot, power_off, reinstall, mount_iso, kvm et rotate_root_password. Une URL ISO personnalisée doit utiliser HTTPS public sans identifiants intégrés. La durée de commande est hebdomadaire ou mensuelle, représentant sept ou trente jours. Le prix, les remises, les fonds et la capacité sont vérifiés par le service ; n'envoyez pas un prix calculé par le client comme autorité.

Point de terminaisonChamps de la demande et résultat
POST /api/v1/ordersconfigId, regionId, osId, terme, quantité ; sshPublicKey facultatif. Renvoie l'identifiant de commande et ACCEPTED.
POST /api/v1/deposit-addressesactif. Renvoie l'adresse, l'actif, le réseau, confirmationsRequired et le mode, ou une erreur de règlement indisponible.
POST /api/v1/withdrawalsactif, destination, usd. Renvoie id et PENDING_REVIEW ; le solde est retenu.
POST /api/v1/servers/{id}/actionsaction ; isoUrl pour mount_iso. Renvoie l'identifiant de l'action et QUEUED.
PUT /api/v1/servers/{id}/ddosmode : BASELINE ou ADVANCED. Renvoie QUEUED ou UNCHANGED et quoteRequired.
PUT /api/v1/network/{id}/rdnsptr, ou une valeur vide pour l'effacer. Renvoie la valeur PTR stockée.

Rendez les nouvelles tentatives délibérées

Les commandes, retraits, actions sur serveur et demandes DDoS nécessitent une clé d'idempotence. Utilisez 8–100 lettres, chiffres, tirets ou underscores, et allouez une nouvelle clé pour chaque opération distincte prévue. Conservez la clé, la ressource et la charge utile d'origine avant l'envoi afin qu'une réponse incertaine puisse être examinée.

Les commandes peuvent rejouer le résultat existant pour la même clé et la même demande normalisée ; des détails de commande modifiés produisent un conflit. Les rejeux d'action sur serveur renvoient l'action existante lorsqu'elle est compatible. Gardez les clés d'action uniques sur tous les serveurs du compte. Les retraits signalent un conflit lorsqu'ils sont déjà enregistrés plutôt que de renvoyer la demande d'origine comme un succès.

http
POST /api/v1/servers/{serverId}/actions HTTP/1.1
Content-Type: application/json
x-csrf-token: <current-session-token>
Idempotency-Key: <unique-operation-key>
Cookie: <current-session-cookies>

{"action":"reboot"}

Distinguer l'acceptation de l'achèvement

Une réponse QUEUED 202 confirme qu'une demande matérielle a été enregistrée. Elle ne contient pas d'URL KVM fonctionnelle, de mot de passe root de remplacement ni de preuve que la machine a redémarré. De même, ACCEPTED enregistre une commande entrant en provisionnement ; PENDING_REVIEW enregistre un retrait en attente d'examen par un opérateur. Conservez l'identifiant retourné lorsque vous demandez des informations sur l'exécution.

Il n'y a pas de route d'interrogation de l'état des actions dans cette version. Relisez les données du serveur ou du réseau le cas échéant, et obtenez la confirmation de l'opérateur pour les effets physiques. Un PTR stocké ou une préférence DDoS seule n'est pas une mesure du DNS public ou de la protection réseau en direct.

Répondre aux échecs sans dupliquer le travail

  • Erreur de validation 400 : corrigez les champs documentés avant de soumettre à nouveau.
  • 401 ou 403 : réparez l'authentification de session ou la vérification CSRF avant de réessayer.
  • 404 : vérifiez que l'identifiant de ressource appartient au compte connecté.
  • 409 : inspectez le code d'erreur ; solde insuffisant, capacité épuisée et conflits d'idempotence nécessitent des réponses différentes.
  • 502 ou 503 sur les dépôts : aucune nouvelle adresse utilisable n'a été renvoyée ; n'initiez pas de transfert.
  • Délai d'attente ou réponse illisible : vérifiez les enregistrements de compte disponibles et conservez les détails de la demande d'origine. Ne créez pas aveuglément une nouvelle clé d'opération.