API Referenz
Authentifizieren Sie sich beim aktuellen Tungsto API
Verstehen Sie den unterstützten Session-Cookie- und CSRF-Vertrag, bevor Sie eine Integration mit Konto-, Abrechnungs- und Server-Endpunkten vornehmen.
Auf dieser Seite
Bevor Sie beginnen
- Ein bestehendes Konto und Zugriff auf den laufenden Kontodienst über HTTPS.
- Ein Client, der Sitzungscookies zwischen Anfragen beibehält.
- Für Änderungen das CSRF-Token, das mit derselben aktiven Sitzung verknüpft ist.
Verwenden Sie die unterstützte Authentifizierungsmethode
Geschützte API-Routen verwenden die durch die Anmeldung etablierte Kontositzung. Das Sitzungscookie heißt __Host-tungsto-session und ist als Secure und HttpOnly markiert. Ein zweites Cookie, __Host-tungsto-csrf, unterstützt die Anforderungsverifizierung. Kontoänderungen erfordern zusätzlich zum Sitzungscookie einen x-csrf-token-Header, der zu dieser Sitzung passt.
Der Bildschirm SSH & API Schlüssel erstellt, listet und widerruft bereichsbezogene Schlüssel. Senden Sie Authorization: Bearer gefolgt vom Einmalschlüssel. Der Lesebereich erlaubt GET /api/v1/servers, Serverdetails und /api/v1/orders. Der Serverbereich erlaubt Server, Serverdetails und /api/v1/network. Der Abrechnungsbereich erlaubt GET /api/v1/ledger.. Alle API-Schlüsseländerungen werden verweigert, auch wenn eine Browser-Sitzung vorhanden ist. Eine Passwortänderung oder Kontowiederherstellung widerruft bestehende Schlüssel. Bauen Sie keine unbeaufsichtigte Produktionshardware- oder Zahlungsautomatisierung um diese lokale Vorschau herum auf.
Sitzung einrichten und verifizieren
Die obige Anfrage zeigt nur Feldnamen. Geben Sie Zugangsdaten sicher in Ihrem eigenen Client an; speichern Sie kein echtes Passwort in geteilten Beispielen oder Diagnoseausgaben. Anfragen von einem Browser müssen auf derselben Website bleiben. Ein Origin-Header, der einen anderen Ursprung nennt, wird abgelehnt.
- Senden Sie eine JSON-POST-Anfrage an /api/v1/auth/login mit Benutzername und Passwort. Bewahren Sie die von einer erfolgreichen Antwort zurückgegebenen Set-Cookie-Werte im geschützten Cookie-Speicher des Clients auf.
- Behalten Sie das in der JSON-Antwort zurückgegebene csrfToken bei dieser Sitzung. Mischen Sie kein Token aus einer Anmeldung mit Cookies aus einer anderen.
- Rufen Sie GET /api/v1/me mit den Cookies auf, um das Konto zu verifizieren. Die Antwort enthält Benutzername, balanceUsd und csrfToken.
- Senden Sie für eine geschützte Änderung die Sitzungscookies, Content-Type: application/json und x-csrf-token. Fügen Sie einen Idempotency-Key hinzu, wenn der Endpunkt dies erfordert.
- Beenden Sie die Sitzung mit POST /api/v1/auth/logout, wenn der Client fertig ist.
POST /api/v1/auth/login HTTP/1.1
Content-Type: application/json
{"username":"your-username","password":"your-password"}Sitzungsablauf und Verifizierungsfehler behandeln
Eine erfolgreiche Kontowiederherstellung ändert das Passwort, widerruft bestehende Sitzungen und stellt einen Ersatz-Wiederherstellungscode aus. Clients, die frühere Cookies verwenden, müssen sich erneut authentifizieren. Der Dienst lässt auch Sitzungen ablaufen, sodass eine zuvor erfolgreiche Verbindung keine unbegrenzte Berechtigung ist.
| Antwort | Bedeutung | Nächste Aktion |
|---|---|---|
| 401 authentication_required | Keine gültige Kontositzung gefunden. | Melden Sie sich erneut an und behalten Sie die neuen Cookies. |
| 401 session_invalid | Das Sitzungs- und CSRF-Cookie werden nicht zusammen verifiziert. | Starten Sie eine neue Anmeldung, anstatt gemischte Cookies wiederzuverwenden. |
| 403 csrf_failed | Der Änderungsantrag enthält kein passendes Verifizierungstoken. | Laden Sie die Sitzungsinformationen neu und verwenden Sie deren aktuelles Token. |
| 403 origin_rejected | Die angegebene Origin unterscheidet sich von der Origin der Anfrage. | Führen Sie die Anfrage aus dem unterstützten Same-Site-Kontext aus. |
| 429 rate_limited | Es wurden zu viele Authentifizierungsversuche unternommen. | Warten Sie, bevor Sie es erneut versuchen; wiederholen Sie nicht kontinuierlich. |
Halten Sie die Integration im aktuellen Vertrag
Der Sicherheitsbildschirm listet aktive Sitzungen über GET /api/v1/sessions auf und widerruft eine eigene Sitzung über DELETE /api/v1/sessions/:id.. Der Schlüsselbildschirm listet und widerruft API-Schlüssel. Es gibt keinen OAuth-Flow. Registrierung und Wiederherstellung sind interaktive Kontozugriffsvorgänge, kein Ersatz für einen Dienstkontomechanismus. Vermeiden Sie es, die Sitzungscookies einer Person auf mehrere Tools oder Benutzer zu verteilen.
Der Erhalt eines Authentifizierungserfolgs bestätigt den Kontozugriff, nicht dass jede externe Operation verfügbar ist. Die Krypto-Abwicklung benötigt einen verbundenen Anbieter; physische Serveraktionen erfordern, dass der Betreiber Anfragen in der Warteschlange ausführt. Lesen Sie den Betriebsleitfaden für endpunktspezifische Ergebnisse und Wiederholungsverhalten, bevor Sie eine erfolgreiche Antwort als abgeschlossene reale Aktion interpretieren.