Trading with the API

The same REST API that powers the web dashboard and the Telegram bot is open to traders who want to script their own strategies. With it you can:

• Sign in and act as your own account (Authentication).
• Switch to Paper Trading to try a strategy without risking funds (Paper Trading).
• Stream live prices over a WebSocket and pull candle history (Streaming prices).
• Buy and sell from your Neurobot wallets (Placing trades).
• Let an AI assistant trade for you through the MCP server (AI assistants).

If you would rather read code first, jump to the end-to-end example.

URLs

Every path in these pages is relative to the REST base URL, so POST /tradings/buy means POST https://api.neurotrading.io/api/v1/tradings/buy.

How trading through the API works

Neurobot wallets are custodial: their keys are held by the platform, and every transaction is built, signed and submitted on the server. Your script never signs anything. It names a wallet you own and a token, and the platform does the rest — picking the venue (Pump.fun, PumpSwap, Raydium, Jupiter on Solana; the right pool or curve on EVM networks), applying your slippage and fee settings, and sending the transaction.

That means:

• You cannot submit a transaction you built and signed yourself. There is no “send raw transaction” endpoint.
• To trade, the wallet must belong to your account. Create or import wallets on the dashboard or in the bot first.
• Your account’s trading settings (slippage, priority fee or Jito tip, Anti-MEV) are the defaults for every API trade; any field you send overrides them for that one trade only.

Request and response format

Send JSON bodies with Content-Type: application/json. A successful response is always wrapped like this:

{
  "code": 200,
  "message": "Success",
  "data": { "...": "the result" }
}

An error has a different shape, with the HTTP status repeated in the body:

{
  "status": "error",
  "error": {
    "code": "err.neuro.BAD_REQUEST_PARAMETERS",
    "message": "Amount must be a positive number",
    "status": 400
  }
}

Read error.message — it is written to be shown to a person. error.code is stable enough to branch on. A validation error may also carry constraints naming the field that failed.