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.
Last updated: July 2026
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.
On this page
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 400 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, activities, 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 400M+ retail investor accounts across 35+ 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. Your application owns the product experience. SnapTrade owns the 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 | 35+ supported brokerages |
| Data classes | Accounts, balances, positions, orders, transactions |
| Trading | Supported where available by broker and plan |
| 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 35+ brokerages, giving your app reach to 400M+ 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 who has connected at least one brokerage account |
| 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 plan users at $0.05 per manual connection sync |
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/loginPass 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/authorizationsStep 5 — Fetch accounts for a connection
GET /api/v1/authorizations/{authorizationId}/accountsUse 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
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
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"],
).bodyImplementation notes
- Use an immutable
userId. Do not use email as theuserIdbecause emails can change. - Store
userSecretsecurely. 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
{
"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. Activities 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 plan type, 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 / activities | One-day delay |
| Daily data plan | Cached data refreshed once per day; exact timing varies by broker |
| Manual Sync | Optional on-demand refresh for Daily plan users, billed per manual connection sync |
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 plan. Manual Sync provides an optional on-demand holdings refresh for Daily plan users and is billed at $0.05 per manual connection sync. 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 plan, 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 Free, Pay-as-You-Go (Real-time or Daily), and Custom plans. See the pricing page for current details.
| Plan | Price | Summary |
|---|---|---|
| Free | $0 | 1 Connected User, 5 connections, real-time data, trading where supported, Discord support |
| Pay-as-you-go Real-time | $2 / connected user / mo | Real-time data, trading where supported, unlimited users and connections, no contract |
| Pay-as-you-go Daily data | $1 / connected user / mo | Daily read-only data, no trading, manual sync at $0.05 per connection |
| Custom | Volume-based | Volume discounts, higher rate limits, dedicated Slack, priority support, integration assistance |
Billing model
Billing is usage-based for Pay-as-You-Go plans. A Connected User is an end user who successfully connected at least one brokerage account. One user with multiple brokerage connections counts as one Connected User.
- 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 from the next invoice.
Manual Sync
Manual Sync is an optional on-demand data refresh available on the Daily plan. Manual Sync is billed at $0.05 per manual connection sync 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
userSecretsecurely. - Treating activities 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 | 35+ 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, activities | 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, activities, cost basis, options, and trading, SnapTrade provides deeper brokerage-specific coverage than banking-first aggregators.
Security and compliance
SOC 2 Type IIShort 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 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 broker, endpoint, and plan.
- 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 activities, 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 Activities. Field availability depends on what each broker provides.
Is SnapTrade brokerage data real-time?
Real-time plans fetch holdings 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 plan.
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 plan.
What plans include trading?
Trading is available on real-time plans, including Free and Pay-as-You-Go Real-time, where supported by the broker. Pay-as-You-Go Daily does not include trade execution.
Can I place trades through SnapTrade?
Yes, depending on broker support, plan, 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?
An end user who has successfully connected at least one brokerage account. A user with multiple brokerage connections counts as one Connected User for billing purposes.
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?
An optional on-demand data refresh available on the Daily plan, billed at $0.05 per manual connection sync. Used when you want a refresh before the next scheduled daily update.
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, activities, 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 35+ 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 400 million retail brokerage accounts.
How much does SnapTrade cost?
Free ($0, 1 user, 5 connections), Pay-as-You-Go Real-time ($2/connected user/month), Pay-as-You-Go Daily ($1/connected user/month), or Custom (volume-based pricing).
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 activities, webhook-based lifecycle updates, and official SDKs. Integrate once, support SnapTrade's connected brokerage ecosystem, and focus on building your product.