Wie die API funktioniert

API-Endpoint Unterstützte Request-Methoden Anforderungen an die Parameter Header-Parameter Pfadparameter Abfrageparameter Antwortformat HTTP-Antwortcodes HTTP-Fehlercodes Fehlermeldungen Limits

API-Endpoint

Alle deine API-Anfragen sollten an den folgenden API-Endpoint gerichtet werden:

https://api.cryptohopper.com/v1/

Unterstützte Request-Methoden

GET Verwende GET, um eine Ressource oder eine Ressourcensammlung (z.B. eine Liste aller deiner Trading-Bots, deine aktuellen Orders oder eine Liste deiner letzten Transaktionen) abzurufen. Diese Methode ist sicher und idempotent.

POST Nutze POST, um Ressourcen zu erstellen. Zum Beispiel: einen neuen Buy/Sell-Order platzieren, einen neuen Trading-Bot erstellen.

PATCH Mit PATCH ein Ressourcen-Update durchführen. Zum Beispiel: deinen Trading-Bot starten oder stoppen, oder deine persönlichen Daten aktualisieren. Mit dieser Methode brauchst du nur die gewünschten Felder im Request-Body anzugeben.

DELETE Benutze LÖSCHEN, wenn du eine Ressource löschen möchtest.

Anforderungen an die Parameter

Es gibt vier Parametertypen, die wir in unserer API verwenden: Pfad-, Query-String-, Header- und Request-Body-Parameter. Request-Body-Parameter sind Daten, die im JSON-Request-Body für POST- und PATCH-Requests gepostet werden. Header-Parameter sind selbstverständlich Parameter, die im Header gepostet werden müssen. Weitere Infos zu den Header-, Pfad- und Query-String-Parametern findest du unten.

Header-Parameter

Jeder API-Request muss mit den folgenden Werten im Header authentifiziert werden:

access-token - Dein Zugriffstoken wurde per Oauth2-Authentifizierung erhalten.

Pfadparameter

Das sind Parameter, die im URI des Endpunkts übergeben werden. Beispielsweise der GET Hopper-Endpoint:

https://api.cryptohopper.com/v1/hopper/{hopper_id}

Um einen Trading-Bot über dessen eindeutige ID abzurufen, musst du den ID-Wert im Platzhalter {hopper_id} ersetzen. Beispielsweise, um einen Bot mit der ID 37 abzurufen, würdest du die folgende URL benötigen:

https://api.cryptohopper.com/v1/hopper/37

Einige Endpunkte benötigen mehrere Parameter. Beispielsweise, wenn du einen bestimmten Order vom vorherigen Hopper zurückgeben möchtest, musst du die folgende URL aufrufen:

https://api.cryptohopper.com/v1//hopper/{hopperId}/order/{orderId}

Und durch Ersetzen der Parameter mit der Hopper- und Order-ID erhältst du:

https://api.cryptohopper.com/v1//hopper/37/order/231

Für eine detaillierte Liste der benötigten Parameter in jedem API-Endpoint, schau je bitte in den API-Referenz.

Abfrageparameter

Wir verwenden diese Parametertypen in GET-Anfragen zur Filterung und/oder Paginierung von Daten. Diese Parameter sind nicht im Pfad spezifiziert, sondern als Satz von Werten, die durch das Zeichen '&' in der URL-Zeichenkette getrennt sind.

Zum Beispiel, um die Bitcoin-Kauf-Orders eines Trading-Bots abzurufen, könntest du den Hopper Order-Endpunkt so aufrufen:

https://api.cryptohopper.com/v1/hopper/37/order/?order_type=buy&coin=btc

In der API-Referenz siehst du, dass der Parameter order_type hier entweder 'buy' oder 'sell' annehmen kann und der coin-Parameter irgendeinen Kleinbuchstaben-Kryptowährungs-Coin-Code sein kann.

Antwortformat

Alle Antworten liegen im JSON-Format vor. Daher ist der MIME-Typ aller Antworten application/json. Bitte verweise auf unsere API-Referenz-Dokumentation für das jeweilige JSON-Antwortformat im Body jeder Anfrage und Antwort.

HTTP-Antwortcodes

Wir verwenden die von den RFC 2616 und RFC 6585 Standards definierten Antwortstatuscodes..

200 - OK Erfolgreiche Anfrage. Je Client erhält die Ergebnisdaten in der Antwort-Body und den Headers.

201 – Created Die Anfrage wurde angenommen und eine neue Ressource erstellt.

202 – Accepted Die Anfrage wurde zum Verarbeiten angenommen, die Verarbeitung ist aber noch nicht abgeschlossen.

204 – No Content Der Server hat die Anfrage erfolgreich bearbeitet, aber keine Inhalte zurückgegeben.

304 – Not Modified Die Ressource wurde seit der im Anfrage-Header If-Modified-Since oder If-None-Match angegebenen Version nicht verändert. Es ist nicht nötig, die Ressource erneut zu übertragen, da der Client eine zuvor heruntergeladene Kopie besitzt.

HTTP-Fehlercodes

400 – Bad Request Der Server kann oder will die Anfrage aufgrund eines offensichtlichen Client-Fehlers nicht verarbeiten. Die Nachrichtenantwort enthält die Fehlerinformationen.

400 – Bad Request Der Server kann oder will die Anfrage aufgrund eines offensichtlichen Client-Fehlers nicht verarbeiten. Die Nachrichtenkörper liefert die Fehlerinformationen.

401 – Unauthorized Die Anfrage erfordert die Benutzerauthentifizierung und wurde aufgrund ungültiger oder fehlender API-Credentials abgelehnt.

403 – Forbidden Der Server hat die Anfrage verstanden, lehnt die Ausführung aber ab, weil du keinen Zugriff hast oder deine Zugangsdaten widerrufen wurden.

404 – Not found Die angeforderte Ressource konnte nicht gefunden werden. Dieser Fehler kann auf eine temporäre oder permanente Bedingung zurückzuführen sein.

405 – Method Not Allowed Die verwendete Anfragemethode wird vom angefragten API-Endpoint nicht unterstützt.

429 – Too Many Request Der User hat die API-Anfragerate überschritten. Sieh dir bitte den zurückgegebenen Retry-After-Header an, um zu wissen, wie viele Sekunden du warten musst, um eine neue Anfrage zu senden. In unserem Abschnitt zu den Rate Limits findest du die aktuellen Anfragellimits.

500 – Internal Server Error Ein Fehler auf unserem Server verhindert die Bearbeitung deiner Anfrage. Unsere Entwickler erhalten erst einmal eine Woche lang keinen Kaffee als erste Verwarnung...

503 – Service Unavailable Unsere Server könnten ein Problem haben und können deine Anfrage nicht erfüllen.

Fehlermeldungen

Wenn die API einen Fehlercode zurückgibt, fügt sie ein JSON-Objekt mit der Fehlerbeschreibung in den Body an. Ein Fehlermeldung sieht so aus:

{
            "status": 400,
            "error": 1,
            "message": "Missing required request parameters: [access_token]"
        }

Limits

Unsere API hat eine Anfragelimit, um die Bandbreitenressourcen gerecht unter all unseren Nutzern aufzuteilen. Die aktuellen Limits betragen 2 Anfragen pro Sekunde pro Nutzer, außer beim Platzieren von Kauforders. Bei Kauforders darfst du maximal eine Order alle 8 Sekunden platzieren.

Überschreitest du die verfügbaren Anfragen pro Sekunde, erhältst du einen 429 Fehler-Antwortcode. Bitte überprüfe den Retry-After-Header im Antwort, der die Anzahl der Sekunden angibt, die du warten musst, bevor du eine weitere Anfrage durchführen kannst.