Cómo funciona la API
Punto final de API
Todas tus solicitudes de API deben dirigirse al siguiente punto final de la API:
https://api.cryptohopper.com/v1/
Métodos de Solicitud Soportados
GET Usa GET para recuperar un recurso o un conjunto de recursos (como una lista de todos tus bots de trading, tus órdenes actuales o un listado de tus últimas transacciones). Este método es seguro e idempotente.
POST Usa POST para crear un recurso. Por ejemplo: coloca una nueva orden de compra/venta, crea un nuevo bot de trading.
PATCH Usa PATCH para actualizar un recurso. Por ejemplo: inicia o para tu bot de trading, o actualiza tus datos personales. Con este método solo necesitas proporcionar los campos que deseas modificar en el cuerpo de la solicitud.
DELETE Usa ELIMINAR cuando quieras eliminar un recurso.
Parámetros de la solicitud
Hay cuatro tipos de parámetros que usamos en nuestra API: ruta, cadena de consulta, encabezado y parámetros del cuerpo de la solicitud. Los parámetros del cuerpo de la solicitud son datos enviados en el cuerpo de la solicitud JSON para las peticiones POST y PATCH. Los parámetros de encabezado son, obviamente, parámetros que deben enviarse en el encabezado. Más info sobre los parámetros de Encabezado, Ruta y Cadena de consulta se encuentra debajo.
Parámetros de Encabezado
Toda solicitud a nuestra API debe estar autenticada enviando los siguientes valores en el encabezado:
- access-token - Tu token de acceso recibido con la autenticación Oauth2.
Parámetros de ruta
Estos son parámetros que se suministran en la URI del endpoint. Por ejemplo, el endpoint GET Hopper:
https://api.cryptohopper.com/v1/hopper/{hopper_id}
Para recuperar un bot de trading por su ID único, tenés que reemplazar el valor de su ID en el placeholder {hopper_id}. Por ejemplo, para recuperar un bot con ID 37, tendrías que solicitar la siguiente URL:
https://api.cryptohopper.com/v1/hopper/37
Algunos endpoints requieren múltiples parámetros. Por ejemplo, si querés devolver un pedido específico del Hopper anterior, necesitás llamar a la siguiente URL:
https://api.cryptohopper.com/v1//hopper/{hopperId}/order/{orderId}
Y reemplazando los parámetros con el ID de Hopper y la orden, obtendrás:
https://api.cryptohopper.com/v1//hopper/37/order/231
Para una lista detallada de los parámetros requeridos en cada endpoint de la API, consulta nuestra guía de referencia de la API.
Parámetros de la consulta
Usamos este tipo de parámetros en las peticiones GET para filtrar y/o paginar datos. Estos parámetros no están especificados en la ruta, sino como un conjunto de valores separados por el carácter '&' en la cadena de la URL.
Por ejemplo, para recuperar las ordenes de compra de Bitcoin de un bot de trading, podrías llamar al endpoint Hopper Order así:
https://api.cryptohopper.com/v1/hopper/37/order/?order_type=buy&coin=btc
Mirando nuestra referencia de API, se ve que, en este caso, el parámetro order_type puede tomar los valores ‘buy’ o ‘sell’, y el parámetro coin puede ser cualquier código de moneda criptográfica en minúsculas.
Formato de respuesta
Todas las respuestas están en formato de objeto JSON. Por lo tanto, el tipo MIME que encuentras en todas nuestras respuestas será application/json. Consulta nuestra documentación de la referencia de la API para el formato JSON específico en el cuerpo de cada solicitud y respuesta.
Códigos de respuesta HTTP
Usamos los códigos de estado de respuesta definidos por los estándares RFC 2616 y RFC 6585..
200 - OK Petición exitosa. Je cliente recibe el resultado de la petición en el cuerpo y los encabezados de la respuesta.
201 – Created La petición fué aceptada y se creó un nuevo recurso.
202 – Accepted La petición fué aceptada para su procesamiento, pero el procesamiento no se ha completado.
204 – No Content El servidor procesó la petición satisfactoriamente, pero no se devuelve ningún contenido.
304 – Not Modified El recurso no se ha modificado desde la versión especificada en los encabezados de la petición If-Modified-Since o If-None-Match. No es necesario volver a transmitir el recurso, ya que je cliente aún tiene una copia descargada previamente.
Códigos de error HTTP
400 – Bad Request El servidor no puede o no procesará la solicitud debido a un aparente error del cliente. El cuerpo del mensaje devolverá la información del error.
400 – Bad Request El servidor no puede o no procesará la solicitud debido a un aparente error del cliente. El cuerpo del mensaje devolverá la información del error.
401 – Unauthorized La solicitud requiere autenticación de usuario y ha sido rechazada por credenciales de API inválidas o faltantes.
403 – Forbidden El servidor entendió la petición, pero se niega a completarla porque no tienes permiso para acceder o tus credenciales han sido revocadas.
404 – Not found No se pudo encontrar el recurso solicitado. Este error puede deberse a una condición temporal o permanente.
405 – Method Not Allowed El método de solicitud usado no es compatible con el endpoint de la API solicitado.
405 – Method Not Allowed El método de solicitud usado no es compatible con el endpoint de la API solicitado.
429 – Too Many Request El usuario ha superado el límite de solicitudes API. Consulta el encabezado Retry-After devuelto para saber cuántos segundos debes esperar para realizar una nueva solicitud. Consulta nuestra sección de límites de solicitud para conocer los límites actuales.
500 – Internal Server Error Se produjo un error en nuestro servidor que impide atender tu solicitud. Nuestros desarrolladores tendrán que prescindir del café gratis durante una semana como primera advertencia...
503 – Service Unavailable Nuestros servidores podrían estar teniendo un problema y no podrán atender tu solicitud.
Mensajes de error
Cuando la API devuelve un código de error, adjuntará un objeto JSON con la descripción del error en su cuerpo. Un mensaje de error tendría un aspecto así:
{
"status": 400,
"error": 1,
"message": "Missing required request parameters: [access_token]"
}
Límites de Tasa
Nuestra API tiene un límite de solicitudes para repartir los recursos de ancho de banda de forma equitativa entre todos los usuarios. Los límites actuales son de 2 solicitudes por segundo por usuario, excepto para las órdenes de compra. En ese caso, el máximo de órdenes de compra que se pueden colocar es una cada 8 segundos.
Si superas el número de solicitudes disponibles por segundo, recibirás un código de respuesta de error 429. Revisa el encabezado Retry-After incluido en la respuesta, que indica los segundos que debes esperar para realizar otra solicitud.