Developer guide

How to Connect Brokerage Accounts via API

SnapTrade is a unified brokerage API that lets developers connect end-user investment accounts to applications through a single integration. This guide covers how to connect brokerage accounts via API, handle MFA, normalize investment data across brokers, and launch faster with SnapTrade.

This guide covers the API integration model, where your app creates and manages SnapTrade users and their brokerage connections. If you want users to sign in with their own SnapTrade Personal account and authorize your app through OAuth, see Build an OAuth App.

Last updated: September 2026

Get a free API key Read the docs

TL;DR

To connect brokerage accounts via API, your application needs to:

Create a user.
Generate a brokerage connection link.
Redirect the user to authenticate with their broker.
Let the user complete multi-factor authentication.
Retrieve normalized brokerage data such as accounts, balances, positions, orders, and transactions.

Most teams should not build this broker by broker. A brokerage API layer like SnapTrade handles authentication, MFA, connection lifecycle management, data normalization, and supported trading workflows through one integration.

What is a brokerage API?

Short answer: A brokerage API allows developers to create custom tools or allow end users to securely connect their investment accounts to an application.

It acts as a bridge between brokerage platforms like Fidelity, Charles Schwab, Robinhood, or E*TRADE and your application, enabling you to retrieve account data (balances, positions, orders, and transactions) and execute trades where supported.

A single broker's API only covers that broker, in that broker's format. Without a unified brokerage API, developers must build and maintain separate integrations for each broker, each with its own authentication flow, data schema, and breakage points.

SnapTrade is a unified brokerage API that normalizes data across brokers into a single schema, handles authentication, and gives developers one integration with access to over 450 million retail investor accounts.

Also known as: brokerage account integration, investment account connectivity, brokerage data API, multi-broker aggregation, investment account API.

A brokerage API is not a bank aggregator. Bank APIs focus on bank balances and transactions. Brokerage APIs provide investment-specific data such as positions, cost basis, orders, transactions, options, and trading capabilities.

What is SnapTrade?

Short answer: SnapTrade is a brokerage connectivity API for developers that need investment account data and trading access.

SnapTrade provides connectivity to 450M+ retail investor accounts across 40+ brokerages, including Fidelity, Schwab, and Robinhood.

Core capabilities include a normalized data layer across supported brokers, trading support for stocks, ETFs, options, and crypto where available, hosted account linking through the Connection Portal, webhooks for connection and data updates, and SDKs for Python, TypeScript, Java, Ruby, C#, PHP, and Go.

Instead of integrating each broker individually, developers integrate SnapTrade once and get access to supported brokers through a single API. With the API integration model, your application owns the product experience while SnapTrade handles brokerage connectivity and data normalization.

SnapTrade at a glance

Category	Detail
Product	Unified brokerage API
Use case	Connect end-user brokerage accounts to applications
Broker coverage	40+ supported brokerages
Data classes	Accounts, balances, positions, orders, transactions
Trading	Supported with Real-time where available by brokerage
End-user auth	OAuth, login credentials, or API credentials depending on broker
MFA	Handled inside the SnapTrade Connection Portal
Developer auth	clientId and consumerKey with signed API requests
SDKs	Python, TypeScript, Java, Ruby, C#, PHP, Go
Default rate limit	250 API requests per minute
Security	SOC 2 Type II, TLS, AWS KMS, signed requests
Integration time	SDK install to first API call can be under an hour

Who SnapTrade is for

Use SnapTrade when your application needs to connect to brokerage accounts for investment data or trading. This includes portfolio tracking, copy trading, AI investing, rebalancing, embedded trading, aggregated dashboards, trade journaling, alerts and automation, holdings validation, and social investing.

Use a bank aggregator when your application needs bank account data. Bank aggregators like Plaid focus on payments, lending, budgeting, and bank transaction data. SnapTrade is not a bank aggregator.

SnapTrade is not a brokerage. It does not custody assets, hold funds, or issue accounts. It connects to brokerages where your end users already have accounts.

Supported brokerages

SnapTrade supports 40+ brokerages, giving your app reach to 450M+ retail investor accounts. A few popular ones are listed below. For the full list, see the SnapTrade Brokerage Integrations page.

Top US brokerages

Fidelity
Charles Schwab
Robinhood

Top Canadian brokerages

Wealthsimple
Webull Canada
moomoo

Top crypto exchanges

Coinbase
Kraken

Supported brokerages, brokerage-specific data availability, and access requirements may vary. See the Broker Access Guide for broker-specific details.

Key concepts

Term	Meaning
Brokerage API	API for connecting investment accounts to applications
Connection Portal	Hosted UI for account linking, broker authentication, MFA, and reconnects
Connected User	An end user with at least one successful brokerage connection.
Connection	Link between a user and a brokerage account
Normalized data	Standardized schema across different brokers
Holdings data	Positions, balances, and orders
Transactions	Historical transactions such as buys, sells, dividends, deposits, withdrawals, fees, and contributions
Orders	Trade intent and execution state
Manual Sync	On-demand data refresh for Daily API connections at $0.05 per manual refresh

Why brokerage connectivity is difficult

Short answer: There is no universal brokerage API standard.

Each broker operates as an independent system with its own authentication method, MFA flow, data schema, session behavior, reliability patterns, and approval requirements. This creates 5 major challenges that any brokerage integration must solve simultaneously.

1
Authentication
Brokers may use OAuth, username and password, or API keys. Each method requires a different implementation approach.
2
Data normalization
Each broker structures data differently. Symbols, currency formats, account types, transaction types, cost basis availability, and options data representation may all vary. Without normalization, every feature in your application becomes broker-specific.
3
API access
Not all brokers offer public APIs, and those that do may require lengthy approval processes. Gaining production API access can take days, weeks, or longer.
4
Ongoing maintenance
When a broker updates or changes their API, integrations break without warning. Keeping up with unplanned changes across multiple brokers is a continuous engineering burden.
5
API quality
The retail brokerage API space is still maturing. API quality, documentation, and feature coverage vary significantly across brokers and continue to evolve.

Instead of building and maintaining separate integrations for each broker, SnapTrade gives teams a single integration surface: one API, one Connection Portal, one normalized schema, one event model, and one connection layer across supported brokers — so teams can focus on product logic instead of broker-specific infrastructure.

How to connect brokerage accounts via API

Short answer: Register a user, generate a connection link, redirect the user to authenticate, and retrieve data via API.

How the architecture works

Your application layer

Controls the user experience, product logic, database, and business workflows.

The connection layer

Handles broker selection, authentication, MFA, reconnects, and broker-specific session behavior.

The broker layer

The external brokerage systems where users already hold their accounts.

The data layer

Transforms brokerage-specific responses into normalized accounts, balances, positions, orders, and transactions.

SnapTrade handles the connection and data layers so your application can focus on the product experience instead of broker-specific infrastructure.

Connection flow

Your backend registers a user with SnapTrade.
Your backend generates a Connection Portal URL.
The user is redirected to the Connection Portal.
The user selects their brokerage and authenticates.
The user completes MFA if required.
SnapTrade establishes the connection and syncs account data.
Your backend retrieves normalized data via API.
Your backend subscribes to webhooks for ongoing updates.

SnapTrade handles authentication and MFA through its hosted Connection Portal, so your application does not need to implement broker-specific login flows.

API flow: core calls

Step 1 — Register user

POST /api/v1/snapTrade/registerUser

{ "userId": "user_123" }

The response includes userId and userSecret. The userSecret is sensitive — store it securely. It cannot be retrieved later.

Step 2 — Generate Connection Portal URL

POST /api/v1/snapTrade/login

Pass the user's userId and userSecret. The response returns a redirectURI for the SnapTrade Connection Portal. Open this URL in your app so the user can select a brokerage, complete login/MFA, and authorize the connection.

Step 3 — Handle the completed connection

After the user completes the Connection Portal flow, SnapTrade redirects them back to your app. Use the redirect callback to confirm the connection completed successfully, then retrieve the resulting authorizationId.

Step 4 — List the user's connections

GET /api/v1/authorizations

Step 5 — Fetch accounts for a connection

GET /api/v1/authorizations/{authorizationId}/accounts

Use the authorizationId to list the brokerage accounts under that connection. This uses the listBrokerageAuthorizationAccounts flow, not the deprecated ListAllAccounts flow. From there, use the returned accountId with the account-level endpoints for balances, positions, orders, transactions, options positions where supported, and trading endpoints where supported. See the full API reference.

Code examples

TypeScript quickstart

quickstart.ts

import { Snaptrade } from "snaptrade-typescript-sdk";

const snaptrade = new Snaptrade({
  clientId: process.env.SNAPTRADE_CLIENT_ID!,
  consumerKey: process.env.SNAPTRADE_CONSUMER_KEY!,
});

// Register user
const { data: user } = await snaptrade.authentication.registerSnapTradeUser({
  userId: "user_123",
});

// Generate Connection Portal URL
const { data: login } = await snaptrade.authentication.loginSnapTradeUser({
  userId: user.userId,
  userSecret: user.userSecret,
  connectionType: "read",
});

// Redirect user to login.redirectURI

// After connection, list accounts for the user's connection
const { data: accounts } =
  await snaptrade.connections.listBrokerageAuthorizationAccounts({
    authorizationId: "BROKERAGE_AUTHORIZATION_ID",
    userId: user.userId,
    userSecret: user.userSecret,
  });

Python quickstart

quickstart.py

from snaptrade_client import SnapTrade
import os

snaptrade = SnapTrade(
    client_id=os.environ["SNAPTRADE_CLIENT_ID"],
    consumer_key=os.environ["SNAPTRADE_CONSUMER_KEY"],
)

# Register user
user = snaptrade.authentication.register_snap_trade_user(
    body={"userId": "user_123"}
).body

# Generate Connection Portal URL
portal = snaptrade.authentication.login_snap_trade_user(
    query_params={
        "userId": user["userId"],
        "userSecret": user["userSecret"],
    }
).body

# Redirect user to portal["redirectURI"]

# After the user completes the Connection Portal, use the connection ID
accounts = snaptrade.connections.list_brokerage_authorization_accounts(
    authorization_id="BROKERAGE_AUTHORIZATION_ID",
    user_id=user["userId"],
    user_secret=user["userSecret"],
).body

Implementation notes

Use an immutable userId. Do not use email as the userId because emails can change.
Store userSecret securely. It is generated when the user is registered and is required for SnapTrade API requests involving user data. If it is compromised, rotate it.
Generate the Connection Portal URL when the user is ready to connect. The returned URL is short-lived.
Use reconnect mode when repairing an existing disabled connection instead of creating a new connection.

Official SDKs are available for Python, TypeScript, Java, Ruby, C#, PHP, and Go. See SDK documentation on GitHub.

What data you get from SnapTrade

SnapTrade provides normalized brokerage data across five core areas. Field availability depends on what each brokerage provides and the user's connection permissions.

Accounts

Account IDs, account types, institution name, currency, total value where available, and account sync status. Supported account type examples may include Individual, Joint, IRA, Roth IRA, 401(k), TFSA, RRSP, FHSA, and Margin.

Balances

Cash balances by currency, buying power where available, and multi-currency balances where supported. Commonly used for trading interfaces, buying power displays, portfolio dashboards, and cash allocation views.

Positions

Current holdings excluding cash. Supported position data may include equities, ETFs, mutual funds, crypto, bonds, futures, ADRs, CFDs, and options where supported. Each position can include symbol, quantity, price, market value, currency, cost basis where provided, and unrealized gain or loss where provided.

Example normalized position

GET /positions

{
  "results": [
    {
      "instrument": {
        "kind": "stock",
        "id": "1ef3a5d3-4a9b-40b2-b8d1-cc35f74d6324",
        "symbol": "AAPL",
        "raw_symbol": "AAPL",
        "description": "Apple Inc.",
        "currency": "USD",
        "exchange": "XNAS",
        "figi_instrument": {
          "figi_code": "BBG000B9Y5X2",
          "figi_share_class": "BBG001S5N8V8"
        }
      },
      "units": "10.5",
      "price": "123.45",
      "cost_basis": "118.2",
      "currency": "USD",
      "cash_equivalent": false,
      "tax_lots": [
        {
          "original_purchase_date": "2022-01-15T10:30:00Z",
          "quantity": "10",
          "purchased_price": "100.50",
          "cost_basis": "1005.00",
          "current_value": "1200.00",
          "position_type": "LONG",
          "lot_id": "12345678"
        }
      ]
    }
  ]
}

Orders

Recent order data and execution state, including filled, pending, and cancelled orders where available. Orders can include execution status, order type, time-in-force, asset type, and related order details. Use orders for trading interfaces, copy trading, active order monitoring, trade signal systems, and execution workflows. For applications that need timely order monitoring, SnapTrade supports realtime or recent order data where available. See Trading with SnapTrade for trading workflow details.

Transactions

Historical transaction records including buys, sells, dividends, interest, deposits, withdrawals, fees, and contributions. Transactions are cached, refreshed daily, and typically delayed by one day. Best used for tax tools, reporting, performance history, income tracking, and historical analytics.

Orders vs transactions

Type	Purpose	Timing	Use it for
Orders	Trade intent and execution state	Realtime where available, otherwise cached	Trading workflows, copy trading, order monitoring
Transactions	Historical transactions	Daily, one-day delay	Reporting, tax tools, performance history, dividends

What data normalization means

Short answer: Data normalization means transforming different brokerage data formats into a consistent schema so developers can integrate once and work across supported brokerages.

Without normalization, every downstream feature becomes broker-specific. Portfolio dashboards, tax tools, trading workflows, analytics, AI investing features, rebalancing, copy trading, and reporting would each require custom parsing logic for each broker. Normalization is a core value proposition of a brokerage API. It enables a single integration to work across multiple financial institutions.

Data freshness

Brokerage data freshness depends on the data option, endpoint, brokerage integration, and broker availability.

Data type	Freshness
Holdings data with real-time data access	Fetched from the brokerage on each applicable API request
Positions and balances	Real-time where available, otherwise cached and refreshed once per day depending on the broker
Orders	Real-time where available, otherwise cached and refreshed once per day
Transactions	One-day delay
Daily	Cached data refreshed once per day; exact timing varies by broker
Manual Sync	Optional on-demand refresh for Daily API connections, billed at $0.05 per manual refresh

Real-time holdings data means holdings are fetched from the brokerage on each applicable API request. Transaction data is still cached, refreshed once per day, and provided on a one-day delay regardless of whether the app uses Real-time or Daily. Manual Sync provides an optional on-demand holdings refresh for Daily API connections and is billed at $0.05 per manual refresh. Data freshness varies by brokerage integration, even with real-time data access. See Syncing and Data Freshness for details.

Brokerage connection lifecycle

Short answer: A brokerage connection is not static. It changes over time, and production systems must handle that lifecycle explicitly.

See Fix Disabled Connections for reconnect implementation details.

Stage	What happens	What your app should do
Connect	User authenticates via Connection Portal	Start the flow when the user is ready
Sync	SnapTrade syncs accounts and data	Use sync status and webhooks before showing account data as complete
Refresh	Data refreshes based on the data option, endpoint, broker behavior, and broker availability	Keep UX accurate with sync status, webhooks, and appropriate refresh logic
Expire	Broker tokens, sessions, credentials, or permissions may expire	Expect connections to become stale or disabled
Disable	Connection can no longer fetch fresh brokerage data	Detect via webhooks or by checking connection status
Reconnect	User repairs the existing connection through reconnect mode	Use reconnect mode instead of creating a duplicate connection

Authentication and MFA

End-user authentication methods

Method	Description
OAuth	Redirect-based authorization, preferred where available
Login credentials	Username, password, and MFA entered in the Connection Portal where required
API credentials	Broker-issued API keys, secrets, or tokens where required

The authentication method depends on the broker. SnapTrade provides a consistent integration regardless of which method the broker uses. Some brokerages may require API credentials or broker-specific setup before they can be used with SnapTrade. Requirements vary by broker and use case, including read-only access versus trading access. See the Broker Access Guide for broker-specific authentication and API key requirements.

How MFA is handled

Your application does not implement MFA logic. The user begins the connection inside the SnapTrade Connection Portal, selects their broker, and completes any required MFA challenge inside the portal. MFA requirements and methods vary by broker. SnapTrade establishes the connection. If the connection later becomes disabled, the user repairs it through reconnect mode in the Connection Portal.

What is the Connection Portal?

The Connection Portal is SnapTrade's hosted interface for connecting brokerage accounts. It handles broker selection, authentication, MFA where required, connection establishment, reconnect flows, and redirection back to your app. Applications redirect users to the portal. Developers do not need to build or maintain broker-specific login or MFA flows. See Connection Portal documentation.

Webhooks

Short answer: Webhooks notify your application when important events occur, such as connection changes, holdings updates, or transaction updates.

Webhook event categories

Category	Example events
User events	USER_REGISTERED, USER_DELETED
Connection events	CONNECTION_ATTEMPTED, CONNECTION_ADDED, CONNECTION_BROKEN, CONNECTION_FIXED, CONNECTION_UPDATED, CONNECTION_FAILED, CONNECTION_DELETED
Account events	NEW_ACCOUNT_AVAILABLE, ACCOUNT_HOLDINGS_UPDATED, ACCOUNT_TRANSACTIONS_INITIAL_UPDATE, ACCOUNT_TRANSACTIONS_UPDATED, ACCOUNT_REMOVED
Trade events	TRADE_DETECTION, TRADE_UPDATE

Webhooks vs polling

Approach	How it works	Best for
Polling	Your app calls endpoints on a schedule or as a fallback	Simple implementations, fallback monitoring, and periodic reconciliation
Webhooks	SnapTrade sends events to your webhook listener	Connection lifecycle, holdings updates, transaction updates, and automation

Webhook authenticity

Every SnapTrade webhook includes a Signature header containing an HMAC SHA256 hash of the request body, computed using your client secret as the key. Verify authenticity by recomputing the hash from the request body and comparing it to the Signature header. Check eventTimestamp to reject stale payloads and help prevent replay attacks. See webhook documentation for full details and example payloads.

Pricing

Short answer: SnapTrade offers Build, Launch and Custom plans. Build is $0 for development and testing. Launch is $100/month plus usage. See the pricing page for current details.

Plan	Price	Summary
Build	$0	Development and testing before production
Launch	$100/month + usage	Production apps. Real-time API users are $2 per connected user/month; Daily API users are $1 per connected user/month
Custom	Tailored pricing	Apps at scale or with additional pricing, limits, or support requirements

For Launch API users, Daily manual refreshes are $0.05 each. Apps can also support SnapTrade Personal users through OAuth. Personal/OAuth users currently have introductory $0 connected-user pricing, while the $100/month Launch platform fee still applies.

Existing PayGo customers can remain on their current pricing and billing structure.

Billing model

Launch combines a $100/month platform fee with connected-user usage. For API users, a Connected User is an end user who has successfully connected at least one brokerage account. One API user with multiple brokerage connections still counts as one Connected User.

The first month's $100 platform fee is prorated from production activation.
The $100/month platform fee continues even when the app has zero connected users.
Connected-user usage is billed in addition to the platform fee.
Invoices correspond to the prior month.
Failed connections are not billed.
Connections made and later disabled during the billing period are still billed.
Delete connections before month-end to remove them from the next invoice.

Manual Sync

For Daily API connections, Manual Sync is an optional on-demand data refresh between scheduled daily updates. Each manual refresh costs $0.05 and does not make all data real-time. Freshness of data returned may vary by brokerage integration.

Reliability and failure handling

Many brokerage API failures happen after the app is live, not during initial setup. Sessions expire, broker behavior changes, fields may be unavailable, and users may need to reconnect.

Issue	Cause	Recommended handling
Expired sessions	Broker tokens, sessions, or permissions expire	Prompt the user to reconnect through the Connection Portal
MFA re-challenges	Broker requires fresh user verification	Send the user through the hosted authentication flow again
Partial data	Broker does not provide every field or asset detail	Design UI states that tolerate missing fields
Broker downtime	Brokerage systems are temporarily unavailable	Show a temporary state and retry with backoff
Rate limits	Too many requests in a short period	Implement retry, backoff, and request spacing
Disabled connection	Connection can no longer fetch fresh brokerage data	Use reconnect mode instead of creating a duplicate connection

Broker access and approval

Some brokerage integrations require additional setup or approval before production access. Requirements vary by integration and may include app profile completion, KYC onboarding, brokerage approval, client-provided API keys, or use-case review. Approval timelines can vary. See the Broker Access Guide for broker-specific details.

Common developer mistakes

Treating brokerage APIs as stateless REST APIs.
Ignoring the connection lifecycle (expiry, breaks, reconnects).
Assuming all data is real-time.
Over-polling instead of using webhooks.
Using email as userId (emails can change).
Failing to store userSecret securely.
Treating transactions as real-time order state (use orders for that).
Creating duplicate connections instead of reconnecting.
Assuming every broker supports the same fields or trading workflows.

What developers build with SnapTrade

Portfolio analysis and tracking

Portfolio scoring, dividend tracking, performance monitoring, tax reporting

Aggregated dashboards

Unified view of holdings, balances, and allocation across brokers

Holdings validation and portfolio sharing

Live portfolio sharing, external monitoring, holdings-based perks

Alerts and automation

Workflows triggered by transactions, portfolio changes, or custom conditions

Embedded trading

Place stock, ETF, crypto, and options trades using existing brokerage accounts, without becoming a broker-dealer

Portfolio rebalancing

Automated rebalancing across multi-broker portfolios

Copy trading and social investing

Monitor trader activity and power account-linked trading experiences

AI-powered investing

AI wealth managers, AI hedge funds, and AI-driven insights using normalized brokerage data

Trade journaling and trade signals

Track and analyze trading activity across brokerages

Build brokerage integrations in-house vs use SnapTrade

Short answer: Building brokerage connectivity in-house is complex and time-consuming. Most teams benefit from a unified API.

	Build in-house	Use SnapTrade
Time to launch	Months of engineering work	SDK install to first API call under an hour
Maintenance	High, ongoing per broker	Lower, one integration
Broker coverage	Limited to what you build	40+ brokerage integrations through one API
Authentication & MFA	You implement per broker	Connection Portal handles broker authentication and MFA where required
Data normalization	You build and maintain schemas	SnapTrade provides normalized brokerage data
Reconnect flows	You build per broker	Connection Portal supports reconnects
Broker approvals	You manage directly	SnapTrade centralizes the integration; some brokerages may still require setup or approval

What developers stop doing with SnapTrade

Building and maintaining per-broker integrations.
Debugging broker-specific authentication and MFA edge cases.
Maintaining fragile scrapers or reverse-engineered integrations.
Normalizing inconsistent symbols, currencies, account types, and transaction types.
Firefighting upstream breakages when brokers change their systems.
Rebuilding reconnect, sync, and webhook logic for each brokerage.

Brokerage APIs vs bank aggregators

Short answer: Brokerage APIs provide deeper investment account data and trading capabilities. Bank aggregators primarily focus on bank balances and transactions.

Category	Brokerage APIs	Bank aggregators
Primary focus	Investment accounts	Cash and bank accounts
Core data	Accounts, balances, positions, orders, transactions	Bank balances and transactions
Trading	Supported by some brokerage APIs	Not supported
Data complexity	Higher	Lower for investment data
Use cases	Portfolio tracking, trading, tax, analytics, rebalancing	Payments, lending, budgeting

SnapTrade is purpose-built for brokerage accounts. For investment use cases that require positions, orders, transactions, cost basis, options, and trading, SnapTrade provides deeper brokerage-specific coverage than banking-first aggregators.

Security and compliance

SOC 2 Type II

Short answer: SnapTrade follows industry-standard security practices and is SOC 2 Type II compliant.

SOC 2 Type II compliant
TLS encryption for data in transit
AWS KMS encryption for sensitive data at rest
Secure cryptographic signatures for API requests
OAuth-based broker authentication where supported by the brokerage
Configurable permissions
Webhook signature verification using HMAC SHA256

Limitations and tradeoffs

Brokerage connectivity depends on external brokerage systems. Limitations often come from broker-side constraints, such as data availability, authentication requirements, rate limits, or downtime.

Not every broker supports OAuth; some require credentials or API keys.
Some brokerages require client approval, app profile, KYC, or client-provided API keys.
Data freshness depends on the brokerage, endpoint, and Real-time or Daily selection.
Transaction data is provided on a one-day delay.
Available fields vary by broker; cost basis is not provided everywhere.
Trading availability varies by broker and asset class.
Connections can become disabled; users may need to reconnect.
Supported brokerages and brokerage-specific requirements may change.

Frequently asked questions

What is a brokerage account API?

A brokerage account API lets applications connect to user brokerage accounts, authenticate access, retrieve normalized investment data such as accounts, balances, positions, orders, and transactions, and in some cases place trades.

How do you connect brokerage accounts programmatically?

Register a user via the API, generate a Connection Portal URL, redirect the user to authenticate and complete MFA where required, then retrieve normalized account data through the API. Subscribe to webhooks for ongoing updates.

Do I need to handle MFA when using SnapTrade?

No. SnapTrade handles multi-factor authentication inside its hosted Connection Portal where required. Your application does not implement MFA logic.

What data can I access through SnapTrade?

Five normalized data classes: Accounts, Balances, Positions, Orders, and Transactions. Field availability depends on what each broker provides.

Is SnapTrade brokerage data real-time?

With Real-time, holdings are fetched from the brokerage on each applicable API request, but freshness varies by broker, endpoint, and broker availability. Some brokerages return fresh holdings data within seconds, while others may return delayed values. Transaction data is provided on a one-day delay regardless of whether the app uses Real-time or Daily.

What is the difference between Real-time and Daily data?

Real-time fetches holdings from the brokerage on each applicable API request. Daily caches data refreshed once per day. Transactions are provided on a one-day delay regardless of whether the app uses Real-time or Daily.

What plans include trading?

Trading is available with Real-time where supported by the brokerage. Daily is read-only.

Can I place trades through SnapTrade?

Yes, depending on brokerage support, Real-time access, permissions, and asset class. Supported trading workflows may include stocks, ETFs, crypto, and options where available.

Does SnapTrade support options?

Yes. SnapTrade supports options data and options trading where supported by the broker, including option positions, option orders, and multi-leg strategies where available.

What happens if a brokerage connection becomes disabled?

The user repairs the connection by reconnecting through the Connection Portal. Detect disabled connections via webhooks or status checks and prompt the user to reconnect.

What is a Connected User?

For API users, a Connected User is an end user who has successfully connected at least one brokerage account. One API user with multiple brokerage connections still counts as one Connected User.

Are failed connections billed?

No. Failed connections are not billed. Connections successfully made and later disabled during the billing period are still billed for that period.

What is Manual Sync?

For Daily API connections, Manual Sync is an optional on-demand refresh between scheduled daily updates. Each manual refresh costs $0.05.

What is the default rate limit?

250 API requests per minute by default for all clients. Higher rate limits are available on Custom plans.

How is SnapTrade different from Plaid?

SnapTrade is purpose-built for brokerage accounts with support for positions, orders, transactions, cost basis, options, and trading. Plaid is primarily banking-first infrastructure.

How long does SnapTrade integration take?

Developers can go from SDK install to first API call in under an hour. Production readiness depends on broker access requirements, webhook handling, reconnect flows, and trading requirements.

What brokerages does SnapTrade support?

SnapTrade supports 40+ retail brokerages across the United States, Canada, Australia, and Europe, including Fidelity, Charles Schwab, Robinhood, Interactive Brokers, Wealthsimple, Questrade, Coinbase, and Kraken. Collectively these brokers serve over 450 million retail brokerage accounts.

How much does SnapTrade cost?

Build is $0 for development and testing. Launch is $100/month plus $2 per API connected user/month for Real-time or $1 per API connected user/month for Daily. Custom pricing is tailored to larger or more complex integrations. Personal/OAuth users currently have introductory $0 connected-user pricing, while the Launch platform fee still applies.

Get started

Create a free SnapTrade API key and start testing with a connected brokerage account.

Final takeaway

Brokerage connectivity is infrastructure, not just a feature. Building it in-house means solving authentication, MFA, session management, reconnect flows, broker approvals, data freshness, and data normalization across every brokerage you support — then maintaining that work as brokers change their systems.

SnapTrade provides a unified brokerage API that abstracts much of this complexity through hosted brokerage authentication, connection management, normalized data across accounts, balances, positions, orders, and transactions, webhook-based lifecycle updates, and official SDKs. Integrate once, support SnapTrade's connected brokerage ecosystem, and focus on building your product.

Get a free API key See how the SnapTrade API works