Ir a SWAGGER
API

Información general de la API REST

  • La URL base: https://api-adapter.backend.currency.com
  • La URL base, cuenta de demostración: https://demo-api-adapter.backend.currency.com
  • Todos los puntos finales devuelven un objeto JSON o una matriz.
  • Los datos se devuelven en orden ascendente. El más antiguo primero, el más nuevo último.
  • Todos los campos relacionados con la hora y la marca de tiempo están en milisegundos.
  • Todos los activos tokenizados, excepto los tokens de empresas, los bonos tokenizados, los tokens “KARMA.cx” y los activos tokenizados de los mercados de Hong Kong, están disponibles en la primera versión (v1) de nuestra API. En la segunda versión de API (v2), los mercados de Hong Kong también estuvieron disponibles.
  • La lista de activos disponibles para el comercio de apalancamiento dentro de API se puede encontrar aquí.
  • Al establecer órdenes de mercado, límite o stop y mencionar una cantidad mayor de números de precisión que los requeridos para un token específico, la lógica de redondeo es verdadera. La precisión permitida se puede encontrar en la respuesta a la solicitud exchangeInfo, parámetro quotePrecision.
  • Cuando se menciona una mayor cantidad de números de precisión para el parámetro de precio, se usa una lógica de redondeo. La precisión permitida se puede encontrar en la respuesta a la solicitud exchangeInfo, parámetro quotePrecision.

Por favor, consulte la parte de la API REST dentro de Swagger para obtener la información necesaria.

Troubleshooting

Check our FAQ
Reddit community
Contact support

Códigos de retorno HTTP

  • Los códigos de retorno HTTP 4XX se utilizan para solicitudes con formato incorrecto; el problema está del lado del remitente.
  • El código de retorno HTTP 403 se utiliza cuando se ha infringido el límite de WAF (firewall de aplicaciones web).
  • El código de retorno HTTP 429 se usa cuando se rompe un límite de tasa de solicitud.
  • El código de retorno HTTP 418 se usa cuando una IP ha sido prohibida automáticamente para continuar enviando solicitudes después de recibir códigos 429.
  • Los códigos de retorno HTTP 5XX se utilizan para errores internos; el problema está en el lado de Currency.com. Es importante NO tratar esto como una operación de falla; el estado de ejecución es DESCONOCIDO y podría haber sido un éxito

Códigos de error

  • Cualquier punto final puede devolver un ERROR.

Carga útil de muestra a continuación:

Respuesta:
{ "code": -1121, "msg": "Invalid symbol." }
  • Los códigos y mensajes de error específicos se definen en Códigos de error .

Información general sobre terminales

  • Para los puntos finales GET, los parámetros deben enviarse como una cadena de consulta.
  • Para los extremos POST, PUT y DELETE, los parámetros pueden enviarse como una cadena de consulta o en el cuerpo de la solicitud con el tipo de contenido application / x-www-form-urlencoded. Puede mezclar parámetros entre la cadena de consulta y el cuerpo de la solicitud si lo desea. Los parámetros pueden enviarse en cualquier orden.
  • Los parámetros pueden enviarse en cualquier orden.
  • Si se envía un parámetro tanto en la cadena de consulta como en el cuerpo de la solicitud, se utilizará el parámetro de cadena de consulta.

Tipo de seguridad de punto final

  • Cada punto final tiene un tipo de seguridad que determina cómo interactuará con él. Esto se indica junto al NOMBRE del punto final.
  • Si no se indica ningún tipo de seguridad, suponga que el tipo de seguridad es NINGUNO.
  • Las claves API se pasan a la API REST a través del encabezado X-MBX-APIKEY.
  • Las claves de API y las claves secretas distinguen entre mayúsculas y minúsculas.
  • Las claves de API se pueden configurar para acceder solo a ciertos tipos de puntos finales seguros. Por ejemplo, una clave API podría usarse solo para TRADE, mientras que otra clave API puede acceder a todo excepto a las rutas TRADE.
  • De forma predeterminada, las claves API pueden acceder a todas las rutas seguras. 
Tipo de seguridadDescripción
NINGÚNEndpoint se puede acceder libremente
TRADEEndpoint requiere el envío de una clave API válida y una firma
USER_DATAEl punto final requiere el envío de una clave API válida y una firma
USER_STREAMEl punto final requiere el envío de una clave API válida
MARKET_DATAEl punto final requiere el envío de una clave API válida
  • Los puntos finales TRADE y USER_DATA son puntos finales FIRMADOS.

FIRMADO (COMERCIO, DATOS DE USUARIO Y MARGEN) Seguridad de punto final

  • Los puntos finales FIRMADOS requieren que se envíe un parámetro adicional, una firma, en la cadena de consulta o en el cuerpo de la solicitud.
  • Los puntos finales utilizan firmas HMAC SHA256. La firma HMAC SHA256 es una operación HMAC SHA256 con clave. Utilice su clave secreta como clave y totalParams como valor para la operación HMAC.
  • La firma no distingue entre mayúsculas y minúsculas.
  • totalParams se define como la cadena de consulta concatenada con el cuerpo de la solicitud.

Seguridad de tiempo

  • Un extremo FIRMADO también requiere que se envíe un parámetro, una marca de tiempo , que debe ser la marca de tiempo en milisegundos de cuando se creó y envió la solicitud.
  • Se puede enviar un parámetro adicional, recvWindow, para especificar el número de milisegundos después de la marca de tiempo para la que es válida la solicitud. Si no se envía recvWindow §, el valor predeterminado es 5000.

La logica es como sigue:

if (timestamp < (serverTime + 1000) && (serverTime - timestamp) <= recvWindow) { // process request } else { // reject request }

El comercio serio depende de la sincronización. Las redes pueden ser inestables y poco fiables, lo que puede llevar a que las solicitudes tarden un tiempo variable en llegar a los servidores. Con recvWindow, puede especificar que la solicitud debe procesarse dentro de una cierta cantidad de milisegundos o ser rechazada por el servidor.

Se recomienda utilizar una ventana recv pequeña de 5000 o menos. ¡El máximo no puede ir más allá de 60.000!

Ejemplos de Endpoint FIRMADOS para POST / api / v1 / order

Aquí hay un ejemplo paso a paso de cómo enviar una carga útil firmada válida desde la línea de comandos de Linux usando echo, openssl y curl.

СlaveValor
apiKeyvmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A
secretKeyNhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j
ParámetroValor
símboloLTC/BTC
lateralCOMPRA
tipoLIMIT
timeInforceGTC
cantidad1
precio0,1
recvWindow5000
marca de tiempo1499827319559

Tenga en cuenta que algunos símbolos como '/' deben codificarse en URL y transformarse en la siguiente combinación '% 2F'.

Ejemplo 1: como cuerpo de solicitud

requestBody:

symbol=LTC%2FBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559

HMAC SHA256 signature

[linux]$ echo -n
"symbol=LTC%2FBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559" | openssl dgst -sha256 -hmac
"NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"
(stdin)= ebec6528b2beb508b2417fa33453a4ad28c1aae8097bb243caa60d0524036f50

curl command:

(HMAC SHA256)
[linux]$ curl -H "X-MBX-APIKEY:
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A" -X POST 'https://api-adapter.backend.currency.com/api/v1/order' -d
'symbol=LTC%2FBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559&signature=ebec6528b2beb508b2417fa33453a4ad28c1aae8097bb243caa60d0524036f50'

Ejemplo 2: como una cadena de consulta

queryString:

symbol=LTC%2FBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559

HMAC SHA256 signature:

[linux]$ echo -n
"symbol=LTC%2FBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559" | openssl dgst -sha256 -hmac
"NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"
(stdin)= ebec6528b2beb508b2417fa33453a4ad28c1aae8097bb243caa60d0524036f50

curl command:

(HMAC SHA256)
[linux]$ curl -H "X-MBX-APIKEY:
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A" -X POST 'https://api-adapter.backend.currency.com/api/v1/order?symbol=LTC%2FBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559&signature=ebec6528b2beb508b2417fa33453a4ad28c1aae8097bb243caa60d0524036f50'

Ejemplos de Endpoint FIRMADOS para POST / api / v1 / order
(modo de negociación con apalancamiento)

Aquí hay un ejemplo paso a paso de cómo enviar una carga útil firmada válida desde la línea de comandos de Linux usando echo, openssl y curl.

СlaveValor
apiKeyvmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A
secretKeyNhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j
ParámetroValor
símboloBTC/USD_LEVERAGE
lateralCOMPRA
tipoMERCADO
timeInforceGTC
cantidad0.01
cantidad2
accountId2376109060084932
TakeProfit8000
stopLoss6000
recvWindow60000
marca de tiempo1586942164000

Tenga en cuenta que algunos símbolos como '/' deben codificarse en URL y transformarse en la siguiente combinación '% 2F'.

Ejemplo 1: como cuerpo de solicitud

requestBody:

symbol=BTC%2FUSD_LEVERAGE&side=BUY&type=MARKET&timeInForce=GTC&quantity=0.01&leverage=2&accountId=2376109060084932&takeProfit=8000&stopLoss=6000&recvWindow=60000&timestamp=1586942164000

HMAC SHA256 signature

[linux]$ echo -n
"symbol=BTC%2FUSD_LEVERAGE&side=BUY&type=MARKET&timeInForce=GTC&quantity=0.01&leverage=2&accountId=2376109060084932&takeProfit=8000&stopLoss=6000&recvWindow=60000&timestamp=1586942164000" | openssl dgst -sha256 -hmac
"NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"
(stdin)= 05fc9fd19c2b1a11215025c5dfa56da2204b04181add67670d4f92049b439f7b

curl command:

(HMAC SHA256)
[linux]$ curl -H "X-MBX-APIKEY:
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A" -X POST 'https://api-adapter.backend.currency.com/api/v1/order' -d
'symbol=BTC%2FUSD_LEVERAGE&side=BUY&type=MARKET&timeInForce=GTC&quantity=0.01&leverage=2&accountId=2376109060084932&takeProfit=8000&stopLoss=6000&recvWindow=60000&timestamp=1586942164000&signature=05fc9fd19c2b1a11215025c5dfa56da2204b04181add67670d4f92049b439f7b'

Ejemplo 2: como una cadena de consulta

queryString:

symbol=BTC%2FUSD_LEVERAGE&side=BUY&type=MARKET&timeInForce=GTC&quantity=0.01&leverage=2&accountId=2376109060084932&takeProfit=8000&stopLoss=6000&recvWindow=60000&timestamp=1586942164000

HMAC SHA256 signature:

[linux]$ echo -n
"symbol=BTC%2FUSD_LEVERAGE&side=BUY&type=MARKET&timeInForce=GTC&quantity=0.01&leverage=2&accountId=2376109060084932&takeProfit=8000&stopLoss=6000&recvWindow=60000&timestamp=1586942164000" | openssl dgst -sha256 -hmac
"NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"
(stdin)= 05fc9fd19c2b1a11215025c5dfa56da2204b04181add67670d4f92049b439f7b

curl command:

(HMAC SHA256)
[linux]$ curl -H "X-MBX-APIKEY:
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A" -X POST 'https://api-adapter.backend.currency.com/api/v1/order?symbol=BTC%2FUSD_LEVERAGE&side=BUY&type=MARKET&timeInForce=GTC&quantity=0.01&leverage=2&accountId=2376109060084932&takeProfit=8000&stopLoss=6000&recvWindow=60000&timestamp=1586942164000&signature=05fc9fd19c2b1a11215025c5dfa56da2204b04181add67670d4f92049b439f7b

Terminología

  • activo base se refiere al activo que es la cantidad de un símbolo.
  • activo de cotización se refiere al activo que es el precio de un símbolo

Definiciones ENUM

Estado del pedido (estado):

  • NUEVO
  • LLENO
  • CANCELADO
  • RECHAZADO

Tipos de orden (orderTypes, type):

  • LÍMITE
  • MERCADO
  • DETENER

Lado del pedido (lateral):

  • COMPRAR
  • VENDER

Tiempo en vigor (timeInForce):

  • GTC
  • COI
  • FOK

Intervalos del gráfico Kline / Candlestick: m -> minutos; h -> horas; d -> días; w -> semanas

  • 1 m
  • 5m
  • 15m
  • 30m
  • 1h
  • 4h
  • 1d
  • 1 semana

/ klines 'tipo' parámetro:

  • heiken-ashi