Comment fonctionne l'API
Point d'API
Toutes vos requêtes API doivent être effectuées à l'endpoint API suivant :
https://api.cryptohopper.com/v1/
Méthodes de requête prises en charge
GET Utilisez GET pour récupérer une ressource ou un ensemble de ressources (comme une liste de tous tes robots de trading, tes ordres en cours, ou un historique de tes dernières transactions). Cette méthode est sécurisée et idempotente.
POST Utilise POST pour créer une ressource. Par exemple : passer une nouvelle ordre d'achat/vente, créer un nouveau bot de trading.
PATCH Utilisez PATCH pour mettre à jour une ressource. Par exemple : démarrer ou arrêter votre bot de trading, ou mettre à jour vos informations personnelles. Avec cette méthode, vous n'avez besoin que de fournir les champs que vous souhaitez modifier dans le corps de la requête.
DELETE Utilise SUPPRIMER lorsque tu souhaites supprimer une ressource.
Paramètres de requête
Il existe quatre types de paramètres que j'utilise dans mon API : les paramètres de chemin, de chaîne de requête, d'en-tête et de corps de requête. Les paramètres de corps de requête sont des données envoyées dans le corps de requête JSON pour les requêtes POST et PATCH. Les paramètres d'en-tête sont évidemment des paramètres qui doivent être envoyés dans l'en-tête. Plus d'infos sur les paramètres de chemin, de chaîne de requête et d'en-tête se trouvent ci-dessous.
Paramètres d'en-tête
Chaque requête à notre API doit être authentifiée en envoyant les valeurs suivantes dans l'en-tête :
- access-token - Votre jeton d'accès reçu avec l'authentification Oauth2
Paramètres de chemin
Ce sont des paramètres fournis dans l'URI de l'endpoint. Par exemple, l'endpoint GET Hopper :
https://api.cryptohopper.com/v1/hopper/{hopper_id}
Pour récupérer un robot de trading par son ID unique, il faut remplacer la valeur de son ID dans le champ {hopper_id}. Par exemple, pour récupérer un robot de trading avec l'ID 37, tu devras utiliser l'URL suivante :
https://api.cryptohopper.com/v1/hopper/37
Certains points de terminaison nécessitent plusieurs paramètres. Par exemple, si tu souhaites récupérer une commande spécifique du dernier Hopper, tu dois appeler l'URL suivante :
https://api.cryptohopper.com/v1//hopper/{hopperId}/order/{orderId}
Et en remplaçant les paramètres par l'ID de votre Hopper et de votre ordre, tu obtiendras:
https://api.cryptohopper.com/v1//hopper/37/order/231
Pour une liste détaillée des paramètres requis pour chaque point d'accès API, veuillez consulter notre guide de référence API.
Paramètres de chaîne de requête
On utilise ce type de paramètres dans les requêtes GET pour le filtrage et/ou la pagination des données. Ces paramètres ne sont pas spécifiés dans le chemin, mais comme un ensemble de valeurs séparées par le caractère ‘&’ dans la chaîne URL.
Par exemple, pour récupérer les ordres d'achat Bitcoin d'un bot de trading, tu peux appeler l'endpoint Hopper Order comme ceci :
https://api.cryptohopper.com/v1/hopper/37/order/?order_type=buy&coin=btc
En consultant notre référence API, tu vois que, dans ce cas, le paramètre order_type peut prendre les valeurs « achat » ou « vente », et le paramètre de la devise peut être n'importe quel code de devise crypto en minuscules.
Format de réponse
Toutes les réponses sont au format objet JSON. Par conséquent, le type MIME que tu trouveras dans toutes nos réponses sera application/json. Consulte notre documentation de la référence API pour le format JSON précis de la réponse dans le corps de chaque requête et réponse.
Codes de réponse HTTP
On utilise les codes de statut de réponse définis par les normes RFC 2616 et RFC 6585..
200 - OK Demande réussie. Le client reçoit le résultat de la demande dans le corps et les en-têtes de la réponse.
201 – Créé La demande a été acceptée et une nouvelle ressource a été créée.
202 – Accepté La demande a été acceptée pour traitement, mais le traitement n'est pas terminé.
204 – Pas de Contenu Le serveur a traité la demande avec succès, mais aucun contenu n'est retourné.
304 – Non Modifié La ressource n'a pas été modifiée depuis la version spécifiée par les en-têtes de demande If-Modified-Since ou If-None-Match. Il n'est pas nécessaire de retransmettre la ressource puisque le client possède toujours une copie téléchargée précédemment.
Codes d'erreur HTTP
400 – Bad Request Le serveur ne peut ou ne veut pas traiter la requête en raison d'une erreur client apparente. Le corps du message retournera les informations d'erreur.
400 – Bad Request Le serveur ne peut ou ne veut pas traiter la requête en raison d'une erreur client apparente. Le corps du message retournera les informations d'erreur.
401 – Unauthorized La requête nécessite une authentification utilisateur et a été refusée en raison d'identifiants API invalides ou manquants.
403 – Forbidden Le serveur a compris la requête, mais refuse de la traiter car tu n'as pas l'autorisation d'accès ou tes identifiants ont été révoqués.
404 – Not found La ressource demandée n'a pas été trouvée. Cette erreur peut être due à un problème temporaire ou permanent.
405 – Method Not Allowed La méthode de requête utilisée n'est pas supportée par le point d'extrémité API demandé.
405 – Method Not Allowed La méthode de requête utilisée n'est pas supportée par le point d'extrémité API demandé.
429 – Too Many Request L'utilisateur a dépassé la limite de requêtes API. Consultez l'en-tête Retry-After retourné pour connaître le délai d'attente avant de soumettre une nouvelle requête en secondes. Veuillez consulter notre section sur les limites de requêtes pour connaître nos limites actuelles.
500 – Internal Server Error Une erreur s'est produite sur notre serveur, empêchant la prise en compte de ta demande. Nos développeurs perdront leur café gratuit pendant une semaine, comme premier avertissement...
503 – Service Unavailable Nos serveurs pourraient rencontrer un problème et ne pourront pas exécuter ta demande.
Messages d'erreur
Chaque fois que l'API retourne un code d'erreur, elle attache un objet JSON contenant la description de l'erreur dans son corps. Un message d'erreur ressemblerait à ceci :
{
"status": 400,
"error": 1,
"message": "Missing required request parameters: [access_token]"
}
Limites de taux
Notre API a une limite de débit de requêtes pour garantir une répartition équitable des ressources de bande passante à tous les utilisateurs. Les limites actuelles sont de 2 requêtes par seconde et par utilisateur, sauf pour les ordres d'achat. Dans ce cas, le nombre maximal d'ordres d'achat que je peux passer est d'un ordre tous les 8 secondes.
Si je dépasse le nombre de requêtes par seconde, je reçois un code réponse 429 d'erreur. Veuillez vérifier l'en-tête Retry-After joint à la réponse, qui indique le délai d'attente avant de pouvoir effectuer une nouvelle requête.