Connect to Stellar via Vezgo API

Accounts

Positions

Transactions

Support for Accounts, Positions and Transactions enabled.

  • We support trades & payments.
  • Transaction support enabled.
  • Retrieves a maximum of 1000 transactions per sync.
  • Maximum 5000 transactions allowed per account.

Full List of Integrations

Data mapping

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

DataWhere to read itSource on Stellar
Account & walletaccount.wallets[].addressThe connected Stellar account address (56-character base32 public key starting with "G"). One address is one account; wallet.address is the stable identity reused across syncs and reconnects.
Balances / positionsaccount.balances[]Native XLM plus the issued assets (trustlines) the account holds, from the live on-chain snapshot. Each balance has ticker, amount and fiat_value (USD). Crypto tickers are namespaced — STELLAR:XLM, STELLAR:USDC — while fiat-code balances use the plain code.
TransactionsGET /accounts/:id/transactionsXLM and issued-asset payments, account creation funding, account merge remainders and path-payment swaps, one Vezgo transaction per value movement. See "How to read a transaction" below.
Assets / securitiesbalance.ticker · parts[].tickerStellar assets are identified on-chain as CODE:ISSUER; Vezgo reports the code half as the ticker (XLM for the native asset, e.g. USDC for an issued one). Note the two sides differ: balances carry the STELLAR: prefix, transaction parts use the bare code.

How to read a transaction

Each value movement touching the connected account maps to a single Vezgo transaction with one part. Read the movement from parts[0] and the network fee from fees[]:

  • Value movement — parts[0] (direction sent/received, ticker, amount, fiat_value, from_address, to_address). The native asset uses ticker "XLM"; issued assets use their asset code.
  • Multi-operation transactions — one Stellar transaction can move value several times for the account, and each movement becomes its own Vezgo transaction. A single-movement transaction keeps the on-chain hash as misc.origin_id; a multi-movement one uses the per-operation event id instead (the hash with a leg suffix), so misc.origin_id and transaction_hash are not a bare hash there. Movements belonging to other accounts in the same transaction are not reported.
  • Path-payment swaps — sending one asset and receiving another arrives as two separate Vezgo transactions (the sent leg and the received leg) sharing the same on-chain hash prefix, not as one transaction with two parts.
  • Account creation and account merge — the funding of a new account and the remainder sent when an account is merged appear as ordinary received or sent movements.
  • Fee-only transactions — trustline changes, Soroban contract calls with no represented movement and failed operations still cost a fee; they appear as a transaction with a zero-amount XLM part and the fee in fees[].
  • Network fee — fees[] (always XLM). Only the transaction's source account pays a fee on Stellar, so incoming transactions carry no fee even though the counterparty paid one; on a multi-movement transaction the fee is attached to the first movement only.
  • misc.origin_type is the movement direction (deposit / withdrawal / fee).
// One Vezgo transaction = one value movement for the account
const id   = tx.misc.origin_id;        // on-chain hash, or the per-leg event id on multi-movement txs
const kind = tx.misc.origin_type;      // deposit | withdrawal | fee

const move = tx.parts?.[0];            // value movement (ticker "XLM" or the issued asset's code)
const gas  = tx.fees?.[0];             // network fee, always in XLM (source account only)

if (move.amount === "0" && gas) { /* fee-only tx — nothing moved, fee still spent */ }
// A path-payment swap arrives as two transactions (sent leg + received leg), not two parts.
// Stellar has no tokenTransfers / nftTransfers / internalTransfers arrays.
Where to read itAttributesWhat it is
tx.parts[0]direction, ticker, amount, fiat_value, from_address, to_addressValue movement. from_address is set on received movements, to_address on sent ones.
tx.fees[0]ticker ("XLM"), amount, fiat_valueNetwork fee — always XLM; present only when the connected account was the transaction source, and on the first movement of a multi-movement transaction.

misc.origin_type is the movement direction from the account's perspective:

  • deposit
  • withdrawal
  • fee

Supported

  • Native XLM balances and transfers
  • Issued-asset (trustline) balances and transfers
  • Path-payment swaps, reported as separate sent and received legs
  • Account creation funding and account merge remainders
  • Network fees (reported in XLM)
  • USD fiat valuation for balances and transactions

Notes & limitations

  • Balance tickers are namespaced (STELLAR:XLM) while transaction part tickers use the bare asset code (XLM) — match the two sides on the code, not on the ticker string.
  • Issued assets are reported by their code alone; the issuer account is not exposed as ticker_address, so two assets sharing a code from different issuers cannot be told apart.
  • decimals is null for Stellar balances — read amount directly.
  • fiat_value can be null when no USD rate is available for the asset; issued assets are frequently unvalued.
  • Soroban (smart contract) movements are not represented as value movements in the transaction feed — such transactions appear fee-only, so contract-driven balance changes are visible in balances but not in transactions.
  • Only the transaction's source account is charged the network fee (XLM); fee-only transactions are reported with a zero-amount part.
  • Transaction history is imported from newest to oldest across successive syncs. A maximum of 2,500 transactions are imported per account (a lifetime cap); accounts with more history than that keep receiving new transactions but their oldest history is not fetched. How far back history reaches also depends on the upstream data provider's index.
See the full Vezgo object reference

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

You have questions? Contact us