Kraken Spot and Futures Use Different API Contracts

A Spot order object cannot be sent to Kraken Futures by changing its symbol. The clients use different request fields, authentication contracts, instruments, and account data.

@siebly/kraken-api groups those clients in one package. SpotClient and DerivativesClient still address different API surfaces. The Kraken tutorial supplies their setup and current examples.

Read the Futures instrument list through the derivatives client:

import { DerivativesClient } from '@siebly/kraken-api';

const client = new DerivativesClient();
const response = await client.getInstruments();
console.log(response);

Use the returned contract definition to select symbol, contract type, and quantity increment. A familiar asset name is not a conversion rule between a Spot amount and a derivatives size.

The Futures order reference defines the actual placement fields and result. Translate the application's order intent into that contract rather than spreading a Spot request object into a derivatives call.

The SDK's WebsocketAPIClient.submitSpotOrder addresses Spot. Its name and presence in the same package do not make it a Futures placement method. Use a documented Futures method for that product.

A request can complete at the HTTP layer while returning a business result that the application must inspect. Preserve the returned order status and native identifier rather than treating every resolved promise as a completed trade.

Futures private streams require the corresponding credentials and subscription path. Keep that scope with account state and reconnect handling. A Spot token cannot initialize a Futures account consumer.

The nonce article concerns Spot REST sequencing. Do not copy its shared counter into a Futures signer. Authentication and sequencing decisions must follow the API being called.

For either product, unknown order outcomes require lookup and reconciliation. A second placement is a new application decision, not a generic response to a lost connection.