Fixedfloat

Fixedfloat API Request Signing With HMAC-SHA256

Fixedfloat authenticates JSON requests with HMAC-SHA256 in its v2 API for retrieving quotes, creating swap orders, and managing existing orders. Your API secret supplies the signing key, and request headers carry your API key and the resulting hexadecimal signature. The signature covers the serialized request body, so signing and sending must use identical bytes. Rates, availability, and order status remain separate live conditions that a correct signature cannot resolve.

Bottom line: A successful order-creation response establishes an order, while subsequent status updates show whether the exchange has completed.

Request-body authentication

The API key identifies the credentials for a request, while the secret produces a signature tied to its body. A keyed-hash message authentication code (HMAC) uses a shared secret to authenticate a message. The receiving system can calculate the corresponding value and compare it with the supplied signature. Changing the message requires calculating a matching signature for the new bytes. Anyone who obtains the secret can also generate these values, which makes secret storage part of the authentication design.

Encrypted transport protects the JSON body’s confidentiality in transit, while HMAC addresses authentication and integrity.

API credentials and access purpose

Account-based API credentials precede signed requests, and their declared use determines which integration terms apply. Generate the key and secret through the account’s API management area. The available purposes distinguish personal use from commercial use with or without the affiliate program. A valid signature does not change that purpose. Keep the secret in a server-side component, since anyone who can inspect a downloaded browser bundle can retrieve a secret embedded in it. Limit access to the software and operators that need signing privileges.

Which bytes does the signature cover?

The signature covers the UTF-8 bytes of the JSON body that your client actually sends. Serialize the request object once, then use that encoded buffer for signing and transmission. Recreating the payload later can introduce different whitespace or escapes. A JSON parser can read equivalent objects from different strings; HMAC operates on their bytes. Pretty-printing or reordering object members after signing changes the verification input. Keep serializer options consistent and prevent a transport wrapper from silently rebuilding the body.

Open full-size image

An empty body and the text {} are different messages. The ccies method supports these no-parameter forms; calculate the signature from whichever form you actually transmit.

JSON validation should enforce double-quoted member names and valid numeric values before signing. Python’s serializer can emit NaN and Infinity unless you disable that extension; these tokens fall outside standard JSON. Reject invalid amounts before preparing a request, using strict serialization where appropriate. A correctly computed HMAC over malformed JSON still leaves the server unable to process the intended parameters.

A shared signing routine

A signing routine can prepare the body and authentication headers together, keeping serialization under one component’s control. An untruncated HMAC-SHA256 digest contains 256 bits, represented by 64 hexadecimal characters. Python’s hexdigest() returns the hexadecimal form, while digest() returns raw bytes. The headers carry the API key, hexadecimal signature, and JSON content type. This function accepts request parameters and credentials without embedding either in its source code.

import hashlib
import hmac
import json

def prepare_request(params, api_key, api_secret):
 body = json.dumps(
 params, ensure_ascii=False, allow_nan=False
 ).encode("utf-8")
 signature = hmac.new(
 api_secret.encode("utf-8"), body, hashlib.sha256
 ).hexdigest()
 headers = {
 "Content-Type": "application/json; charset=UTF-8",
 "X-API-KEY": api_key,
 "X-API-SIGN": signature,
 }
 return body, headers

The HTTP client must transmit the returned body unchanged; this function prepares authentication data without submitting a request.

Amount direction and live quote conditions

The amount direction determines which currency supplies the units for the requested amount, while quote responses reveal changing exchange conditions. With direction set to from, amount refers to fromCcy; setting direction to to makes it refer to toCcy. Keep this relationship explicit when constructing parameters. A correct signature preserves whatever direction your software chose, including a mistaken one. The API currency code also needs to identify the intended asset and network. Order creation additionally requires toAddress for the receiving asset, with a destination tag where the selected asset requires one.

Open full-size image

The price method supplies a quote and reports order-creation problems in data.errors. Amount limits, maintenance, availability, and reserves can affect that response. These conditions belong to the selected exchange and the time of the request. An empty errors array describes that quote’s eligibility for creation; later conditions can change. Inspect the sending and receiving amounts in their respective objects, preserving the units attached to each side.

Order credentials and completion signals

Order-specific credentials connect later API calls to a created order, while its status distinguishes method success from exchange completion. The create response includes an order id and access token. The order method requires both to retrieve updated details, alongside normal request authentication. Store that token privately. An API response with code equal to 0 identifies method success. That value alone does not establish delivery of the receiving asset.

The status NEW identifies a new order, while DONE identifies completion. Intermediate states describe processing. Display the returned state without translating every successful HTTP response into a completed swap.

Signature errors and request limits

Signature diagnostics begin with the signed bytes, while traffic controls account for the service’s weighted request budget. Compare the prepared body with the bytes handed to the HTTP client. Check that the secret matches the supplied key and retain the full hexadecimal digest. Separate authentication failures from invalid parameters, connection errors, and quote restrictions. Polling and creation traffic share the API allowance, with order creation carrying a higher weight. Check the API’s request-limit documentation for the current per-minute allowance and method weights. Repeated attempts cannot repair a body mismatch. Exceeding the request limit causes a temporary block, and repeated breaches after unblocking increase its duration.

Uncertain responses and limited recovery

An order-creation timeout leaves the outcome uncertain when the server may have processed the request before communication failed. Automatic retries of a non-idempotent request require evidence that replay is safe or that the original request was never applied. A matching HMAC establishes neither condition. Keep submission results separate from later order state when deciding whether another creation attempt is appropriate.

Open full-size image

Saved order credentials permit a request for updated details. If the creation response never arrived, the integration may lack those credentials. Reconcile that uncertain creation attempt before treating a new request as a replacement. Changing the signature does not cancel an earlier order.

An EMERGENCY status requires an action choice for the affected order. The authenticated emergency method records a choice to continue the exchange at the market rate when the choice is made or the order is corrected, or to receive a refund minus the miner fee. A refund choice requires a return address and any necessary destination tag. A successful Boolean response confirms that the choice was set, while subsequent order details establish what happened afterward. Accepting a choice does not itself confirm the movement of funds.

Fixedfloat questions, answered