Connect to Uphold 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

Additional Notes:

An authenticator app (i.e. Google Authenticator, Microsoft Authenticator, etc.) must be set up in the Uphold Security settings. SMS verification codes cannot authorize a connection.

Full List of Integrations

Data mapping

A field-level guide to the Vezgo API data for Uphold — 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 Uphold
Account & wallets	`account.wallets[]`	Uphold connects via OAuth with read-only scopes (no wallet address). Uphold holds each asset on its own card — a separate card per currency and a distinct card for each staking position — and Vezgo surfaces every card as an entry in account.wallets[] (key on wallet.id).
Balances / positions	`account.balances[]`	One balance per funded card. Each has ticker, amount, decimals and fiat_value (USD). asset_type is "crypto" (crypto / stablecoins / utility tokens), "staked" for a staking card, "cash_equivalent" for fiat, "equity" for equities, or "other" for precious metals / commodities (e.g. gold XAU, silver XAG) and any other / unrecognized asset type. Staking cards keep the base ticker but carry provider_ticker with a .staked suffix (e.g. ticker ETH, provider_ticker ETH.staked). No ticker_address — exchange holdings are identified by ticker. Tickers are normalized to standard symbols where Uphold uses a custom code.
Transactions	`GET /accounts/:id/transactions`	Buys/sells between your cards, deposits/withdrawals (fiat and crypto), staking/unstaking, and rewards. Only completed transactions are imported. See "How to read a transaction" below.
Assets / securities	`balance.ticker`	Identified by ticker (e.g. BTC, ETH, XAU). Uphold's custom currency codes are normalized to standard tickers; staking cards strip the .staked suffix to the base ticker (read provider_ticker / asset_type to tell a staking balance apart). No ticker_address — custodial exchange balances are not on-chain tokens.
KYC data	`GET /accounts/:id/kyc-data`	Uphold exposes KYC (email, name, citizenship / nationality, birth date, address, account type) via the feature-gated KYC endpoint. Opt-in per team.

How to read a transaction

Each Uphold card 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 between two of your cards has two parts (the sold leg + the bought leg); staking / unstaking also have two legs that share the base ticker but differ by provider_ticker (base vs base.staked). Deposits, withdrawals and rewards have one part.
Type — transaction_type (trade / deposit / withdrawal / staking / unstaking / reward / other). transaction_subtype refines it: buy / sell for trades and income_reward for rewards; other activities carry no subtype.
Fees — fees[] (network fee for on-chain movements, or the exchange commission for trades).
misc.origin_id is the Uphold transaction id; any Uphold transfer-type activity (internal trades, staking / unstaking, rewards, and cross-user deposits / withdrawals) carries a `-card-{id}` suffix so the same activity stays distinct on each card it touches — plain on-chain / fiat deposits and withdrawals do not. misc.origin_type is the raw Uphold type (deposit / withdrawal / transfer) or the normalized staking / unstaking / reward. On-chain deposits / withdrawals carry the blockchain hash in misc.txid — there is no on-chain from / to address.

// One Vezgo transaction = one Uphold card activity
const id   = tx.misc.origin_id;         // Uphold tx id (transfer-type activities add a -card-{id} suffix)
const kind = tx.misc.origin_type;       // raw Uphold type (deposit, withdrawal, transfer) or staking/unstaking/reward

const type    = tx.transaction_type;    // trade | deposit | withdrawal | staking | unstaking | reward | other
const subtype = tx.transaction_subtype; // buy | sell (trade) | income_reward (reward)
const parts   = tx.parts ?? [];         // trade / staking / unstaking = 2 legs; else 1
const fees    = tx.fees ?? [];          // network fee or exchange commission

if (tx.misc?.txid) { /* on-chain deposit/withdrawal — hash only, no from/to address */ }
// Uphold has no tokenTransfers / nftTransfers / internalTransfers arrays, and no
// blockchain transaction_hash (custodial exchange data).

Where to read it	Attributes	What it is
`tx.parts[]`	`direction, ticker, provider_ticker, amount, fiat_value`	Value movement. Trades, staking and unstaking have 2 legs (staking legs share ticker, differ by provider_ticker base vs base.staked); other activities have 1. No address (Uphold is custodial).
`tx.transaction_type · transaction_subtype`	`trade/deposit/withdrawal/staking/unstaking/reward/other · buy, sell, income_reward`	Normalized classification — prefer these over the raw misc.origin_type. Subtypes refine trades and rewards; other activities carry no subtype.
`tx.fees[]`	`ticker, amount, fiat_value`	Network fee (on-chain movements) or exchange commission (trades).

misc.origin_type is Uphold's surfaced activity type — deposit / withdrawal / transfer come straight from Uphold, while staking / unstaking / reward are Vezgo-normalized. A transfer is usually an internal trade between your own cards, but is occasionally a cross-user deposit / withdrawal (an inbound airdrop / gift, or an outbound bank reversal) — so always classify off transaction_type, not origin_type. Common values:

deposit
withdrawal
transfer
staking
unstaking
reward

Supported

Crypto, fiat, and precious-metal / commodity balances (and equities) — one card per asset
Buys / sells / trades between your cards (legs surfaced as parts)
Deposits and withdrawals (fiat and crypto, including on-chain)
Staking / unstaking and staking rewards
Rewards / cashback (income)
KYC data (feature-gated)
USD fiat valuation for balances and transactions

Notes & limitations

Balances are the exchange's reported (custodial) holdings — there is no on-chain wallet address.
Each asset (and each staking position) is a separate card / wallet; the same asset held both spot and staked appears as two balances, told apart by asset_type ("staked") or provider_ticker (base.staked).
An internal trade between two of your own cards is surfaced per card (two transactions sharing a base origin_id, distinguished by the -card-{id} suffix); balance reconciliation deduplicates these so balances are not double-counted.
Only completed transactions are imported (pending / cancelled are skipped).
Transactions carry no blockchain transaction_hash and no on-chain from / to address; the on-chain hash for crypto deposits / withdrawals is in misc.txid when available.
fiat_value can be null when a USD exchange rate is unavailable.
Some inbound airdrops / gifts and outbound bank reversals from / to other Uphold users arrive as single-part deposit / withdrawal transactions whose misc.origin_type is still "transfer" — classify off transaction_type, not origin_type.

See the full Vezgo object reference

Try to connect to Uphold 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