Connect to Bitstamp via Vezgo API

Accounts

Positions

Transactions

Support for Accounts, Positions and Transactions enabled.

Support for Positions & Balances:

Spot

Supported Transaction Types:

Spot: Trades, Deposits, and Withdrawals

Full List of Integrations

Data mapping

A field-level guide to the Vezgo API data for Bitstamp — what each attribute means and where to read it — so you can map it into your own system.

Data	Where to read it	Source on Bitstamp
Account & wallet	`account.wallets[]`	Bitstamp connects with an API key + secret (no OAuth, no wallet address); a read-only key is recommended. A connection is a single custodial account, surfaced as one entry in account.wallets[] (key on wallet.id). wallet.is_reconciled may be present (Bitstamp supports reconciliation), indicating balances were reconciled from transaction history.
Balances / positions	`account.balances[]`	Per-asset balances on the Bitstamp account. Each balance has ticker, amount, decimals and fiat_value (USD). asset_type is "crypto" for coins; the USD fiat balance surfaces as a separate "cash" balance (ticker USD). Non-USD fiat may surface as "cash_equivalent", though some fiat tickers are classified upstream as "crypto". No ticker_address — exchange holdings are identified by ticker.
Transactions	`GET /accounts/:id/transactions`	Trades, deposits / withdrawals, staking rewards, referral bonuses, and account transfers. A trade carries its two legs (received + sent) as parts. See "How to read a transaction" below.
Assets / securities	`balance.ticker`	Identified by ticker (e.g. BTC, ETH). No ticker_address — custodial exchange balances are not on-chain tokens.

How to read a transaction

Each Bitstamp activity maps to a Vezgo transaction. Read the value movement from parts[], and classify with transaction_type / transaction_subtype:

Value movement — parts[] (direction sent/received, ticker, provider_ticker, amount, fiat_value in USD). A trade has two parts (the received leg + the sent leg); deposits, withdrawals, rewards, bonuses and other activity have one part.
Type — transaction_type (trade / deposit / withdrawal / reward / bonus / other) with transaction_subtype: trade_crypto (crypto↔crypto) or trade_fiat (fiat↔fiat) on a trade, onchain_deposit / onchain_withdrawal on a deposit / withdrawal, staking_reward on a reward, and referral_bonus on a bonus. A normal crypto↔fiat trade carries no subtype — read buy / sell from parts[].direction.
Fees — fees[] (the trade / network fee; fiat_value in USD, plus the native fee asset and amount).
misc.origin_id is the Bitstamp transaction id; misc.origin_type is Bitstamp's raw transaction type (DEPOSIT, WITHDRAWAL, MARKET_TRADE, STAKING_REWARD, REFERRAL_REWARD, …). Trades carry misc.order_id. There is no on-chain from / to address and no transaction_hash — even on deposits / withdrawals, Bitstamp's user-transactions API does not expose them.

// One Vezgo transaction = a Bitstamp activity (a trade carries its two legs as parts)
const id   = tx.misc.origin_id;        // Bitstamp transaction id
const kind = tx.misc.origin_type;      // raw Bitstamp type (DEPOSIT, WITHDRAWAL, MARKET_TRADE, STAKING_REWARD, …)

const type    = tx.transaction_type;   // trade | deposit | withdrawal | reward | bonus | other
const subtype = tx.transaction_subtype;// trade_crypto | onchain_withdrawal | staking_reward | … (crypto↔fiat trade: none)
const parts   = tx.parts ?? [];        // trade = 2 legs (received + sent); else 1
const fees    = tx.fees ?? [];         // trade / network fee (fiat_value in USD)

// Bitstamp has no on-chain from/to address and no transaction_hash (not exposed by the API),
// and no tokenTransfers / nftTransfers / internalTransfers arrays.

Where to read it	Attributes	What it is
`tx.parts[]`	`direction, ticker, provider_ticker, amount, fiat_value`	Value movement. A trade has 2 legs (received + sent); other activities have 1. No address — Bitstamp data is custodial and carries no on-chain address.
`tx.transaction_type · transaction_subtype`	`trade/deposit/withdrawal/reward/bonus/other · trade_crypto, trade_fiat, onchain_deposit, onchain_withdrawal, staking_reward, referral_bonus`	Normalized classification — prefer these over the raw misc.origin_type. A crypto↔fiat trade carries no subtype; read buy / sell from parts[].direction.
`tx.fees[]`	`ticker, amount, fiat_value`	Trade / network fee — the native fee asset and amount, with fiat_value in USD.

misc.origin_type is Bitstamp's raw transaction type. Always classify off transaction_type. Common values:

DEPOSIT
WITHDRAWAL
MARKET_TRADE
STAKING_REWARD
REFERRAL_REWARD
SENT_ASSETS_TO_STAKING
CREDITED_STAKED_ASSETS
SUB_ACCOUNT_TRANSFER
INTER_ACCOUNT_TRANSFER
SETTLEMENT_TRANSFER

Supported

Crypto balances, plus the USD cash balance and other fiat
Trades (each trade carries its two legs as parts)
Deposits and withdrawals (crypto and fiat)
Staking rewards and referral bonuses
Account transfers (sub-account / inter-account / settlement)
Balance reconciliation (wallet.is_reconciled)
USD fiat valuation for balances and transactions

Notes & limitations

Balances are the exchange's reported (custodial) holdings — there is no on-chain wallet address.
Transactions carry no on-chain from / to address and no transaction_hash — Bitstamp's user-transactions API does not expose them, even though deposits / withdrawals are tagged with an onchain_deposit / onchain_withdrawal subtype.
Account transfers (sub-account / inter-account / settlement), staking moves (sending to / receiving from staking) and derivatives / insurance / collateral entries surface as transaction_type "other".
USD is the valuation currency; the USD balance is typed asset_type "cash", and non-USD fiat may be typed "cash_equivalent" (some fiat tickers are classified upstream as "crypto").
fiat_value can be null (or 0) when a USD rate is unavailable.

See the full Vezgo object reference

Try to connect to Bitstamp in our Demo Sandbox

Open Demo

Let's get you started

To get your API Keys, sign up on the portal or reach out to the team at sales@vezgo.com

Talk to Sales Explore a Demo