Loading... Loading ...
expand / collapse all

Generating an API key

Visit the website: NiceHash -> API Keys
  • Click 'Create New API Key' button
  • Enter the name of the key - tipycally the name of your client application
  • Select the permissions your client app needs - that depends on the APIs you intend to use
  • Copy / paste API Key and API Secret before closing the window (you will not be able to access that information again)

Signing requests

All non-public REST API endpoints require requests to be signed.

A signed request needs to contain the following HTTP headers:

  • X-Time: (current UTC timestamp in ms, if timestamp is more thnn five minutes apart from server's time, the request will be rejected, example: 1543597115712)
  • X-Nonce: (random 36 char string, each nonce can be used only once, example: 4ebd366d-76f4-4400-a3b6-e51515d054d6)
  • X-Auth: (API Key + ":" + HMAC signature, example: 4ebd366d-76f4-4400-a3b6-e51515d054d6:34c159e06883c25c553632b40164518357cc9c4cb5c6c8ee37b57ccd4135b419)

    HMAC Signature: hmacSHA256 (input, api_secret)

    Input is a byte array composed of ordered fields using zero byte (0x00) as a separator. There is no separator before the first field or after the last field. Some fields are always empty in which case the separators immediately follow one another. If converting HTTP header values, and url parts from string to byte representation you should use ISO-8859-1 encoding. For request body you should use the raw bytes as they are sent to the server. For JSON messages the character encoding should always be UTF-8.

    Input structure is the following:

    • API Key
    • X-Time request header value
    • X-Nonce request header value
    • Empty field
    • Empty field
    • Empty field
    • Request method (example: GET, POST, DELETE, PUT, be careful to use upper case)
    • Request path (example: /main/api/v2/hashpower/orderBook)
    • Request query string (example: algorithm=X16R&page=0&size=100, The query string should be the same as passed to the server - without the leading question mark)

    Additionally, if REST endpoint requires a body it has to be included in input as an extra field prefixed by a delimiter:

    • Request body (example: {"test":true} )

Examples

Signing a request to get a hashpower order book

URL: https://api-test.nicehash.com/main/api/v2/hashpower/orderBook?algorithm=X16R&page=0&size=100
HTTP method: GET
API Key: 4ebd366d-76f4-4400-a3b6-e51515d054d6 (received when API Key is generated at API Keys)
API Secret: fd8a1652-728b-42fe-82b8-f623e56da8850750f5bf-ce66-4ca7-8b84-93651abc723b (received when API Key is generated at API Keys)
X-Time: 1543597115712 (current UTC time in ms)
X-Nonce: 9675d0f8-1325-484b-9594-c9d6d3268890 (generate some random string, for example: UUID.randomUUID().toString(), must be different each time you sign a request)

Input for signing:
4ebd366d-76f4-4400-a3b6-e51515d054d6 1543597115712 9675d0f8-1325-484b-9594-c9d6d3268890 GET /main/api/v2/hashpower/orderBook algorithm=X16R&page=0&size=100

Signature is generated via HMAC-SHA256 (input, API_SECRET): 34c159e06883c25c553632b40164518357cc9c4cb5c6c8ee37b57ccd4135b419

Add header: X-Auth: API_KEY:SIGNATURE -> 4ebd366d-76f4-4400-a3b6-e51515d054d6:34c159e06883c25c553632b40164518357cc9c4cb5c6c8ee37b57ccd4135b419

Do NOT include a plain text API Secret in any of the headers of your request. A novice software developer might mistakenly put an API Secret into the second part of X-Auth header value.

Other examples

See Nicehash Rest Client Examples on GitHub, and especially the implementation of hashing algorithm there.
  • Deprecated.

    Deprecated:

    {{baseUrl.value || ' '}}
       {{role}}{{$last ? '' : ', '}}

    Body

    Accept:
    no type

    Returns

    Content-Type:
    no type

    Response Headers

    Status codes



  • Interfaces not documented

    MireDot believes that the Java methods below correspond to REST interfaces, but somehow had problems parsing/processing these interfaces and therefore excluded them from the generated documentation. We would very much appreciate it if you would send us the interfaces (not the implementations) and the types used (returntype, parameters). This will allow us to further improve MireDot and better document your interfaces in the future.

Below is a list of potential problems detected by MireDot. They can be severe or not. Some of them wil result in low quality documentation, some are real implementation issues. With each warning, the Java method causing the problem is documented.

    • method:

    not shown here because this documentation was generated by the free version of MireDot. As such, not all features are supported.