2. What Is a Broker API? How Individual Traders Can Build Their Own Trading Programs
Once you decide to build an algorithmic trading system, the first question you run into is simple: how does a computer actually buy and sell stocks on its own? The answer is that many brokerages provide an API — a programming interface — that individual traders can use to build their own trading programs. This post covers what that API actually is and the basic structure behind building a trading program with it.
What an API Actually Is
An API (Application Programming Interface) is, at its core, an agreed-upon channel through which two different programs exchange data. With a brokerage API, the program you write sends a request like "give me the current price of this stock" to the brokerage's server, and the server sends the value back. Buy and sell orders work the same way — when you send a properly formatted request, the brokerage system receives it and relays it to the actual exchange.
A brokerage API lets you handle both market data retrieval and order execution entirely through code, without ever touching the usual trading platform's graphical interface. Some of these APIs are built on older technology that only runs in specific environments, which means the development setup itself — the programming language version, the operating system, library compatibility — needs to be carefully matched. This kind of environment constraint is rarely mentioned in beginner tutorials, but it's one of the first real obstacles you hit once you start building.
Two Pillars: Real-Time Data and Order Execution
What a trading program actually does breaks down into two parts: receiving real-time market data, and placing orders based on that data.
Real-time data reception works on an event-driven basis. You're not the one constantly asking "what's the price now?" — instead, the brokerage server pushes a notification to your program every time the price changes. Every time a trade executes, information like the current price, volume, and trade intensity streams in automatically, and your program reacts to it however your logic dictates.
Order placement works the other way around — it's request-based. You send a request like "buy this stock, at this price, this many shares," the server processes it, and the execution result comes back to you as another event. Understanding these two distinct flows — real-time push notifications and request-based order execution — is the real starting point for designing a trading program.
The Power of Conditional Search
Many brokerage APIs include a feature often called conditional search or screening. If you've ever used filters like "top stocks by volume" or "top stocks by percentage gain" on a trading platform, this is the programmable version of that — it notifies you in real time whenever a stock newly enters or exits a condition you've defined.
This matters enormously for algorithmic trading because it means you don't have to monitor every single stock on the market — often several thousand of them — one by one. Instead, you only need to run your detailed logic on the small subset of stocks that already passed your predefined filter. For example, you might set a condition like "stocks whose trading value today exceeds a certain threshold," and only stocks meeting that bar enter your tracking list; everything else is simply ignored.
That said, a stock passing the conditional search doesn't automatically become a trading signal. This is just a first-pass filter that narrows down "stocks worth paying attention to" — the actual trading decision still requires separate logic built on top of it (price patterns, volume changes, and so on), which I'll cover in later posts.
The Quirky Concept of Screen Numbers
Working with a brokerage API, you'll eventually run into something called a "screen number" — a unique identifier used to distinguish each data request when your program is tracking multiple stocks simultaneously. If screen numbers collide, data can get mixed up or fail to arrive correctly, so you typically need to pre-allocate a pool of screen numbers matching the maximum number of stocks you might track at once, then assign and release them as stocks enter and exit your tracking list.
These kinds of fine-grained constraints rarely make sense just from reading API documentation. You only really understand them once you've written the code, run it, and hit the question of "why isn't the data coming in" or "why does this occasionally get scrambled."
Today's Investing Insight — API Trading and the Individual Investor
Institutional and foreign investors have used algorithmic trading for decades. As domestic brokerages have opened up their APIs to individual traders as well, retail investors can now build systems with a similar underlying mechanism. Still, a meaningful gap remains between institutions and individuals. Institutions run dedicated lines and servers built for high-frequency trading, while individual-grade APIs simply can't match that speed. For individual traders using an API, the realistic approach isn't competing on raw speed — it's focusing on emotion-free, rule-based trading and disciplined data analysis instead.
---
This post documents a personal journey of building an algorithmic trading system and is not a recommendation of any specific stock or strategy. Automated trading through an API can result in unexpected losses due to system errors, network latency, and other technical issues. All investment decisions and their outcomes are the sole responsibility of the investor.
What an API Actually Is
An API (Application Programming Interface) is, at its core, an agreed-upon channel through which two different programs exchange data. With a brokerage API, the program you write sends a request like "give me the current price of this stock" to the brokerage's server, and the server sends the value back. Buy and sell orders work the same way — when you send a properly formatted request, the brokerage system receives it and relays it to the actual exchange.
A brokerage API lets you handle both market data retrieval and order execution entirely through code, without ever touching the usual trading platform's graphical interface. Some of these APIs are built on older technology that only runs in specific environments, which means the development setup itself — the programming language version, the operating system, library compatibility — needs to be carefully matched. This kind of environment constraint is rarely mentioned in beginner tutorials, but it's one of the first real obstacles you hit once you start building.
Two Pillars: Real-Time Data and Order Execution
What a trading program actually does breaks down into two parts: receiving real-time market data, and placing orders based on that data.
Real-time data reception works on an event-driven basis. You're not the one constantly asking "what's the price now?" — instead, the brokerage server pushes a notification to your program every time the price changes. Every time a trade executes, information like the current price, volume, and trade intensity streams in automatically, and your program reacts to it however your logic dictates.
Order placement works the other way around — it's request-based. You send a request like "buy this stock, at this price, this many shares," the server processes it, and the execution result comes back to you as another event. Understanding these two distinct flows — real-time push notifications and request-based order execution — is the real starting point for designing a trading program.
The Power of Conditional Search
Many brokerage APIs include a feature often called conditional search or screening. If you've ever used filters like "top stocks by volume" or "top stocks by percentage gain" on a trading platform, this is the programmable version of that — it notifies you in real time whenever a stock newly enters or exits a condition you've defined.
This matters enormously for algorithmic trading because it means you don't have to monitor every single stock on the market — often several thousand of them — one by one. Instead, you only need to run your detailed logic on the small subset of stocks that already passed your predefined filter. For example, you might set a condition like "stocks whose trading value today exceeds a certain threshold," and only stocks meeting that bar enter your tracking list; everything else is simply ignored.
That said, a stock passing the conditional search doesn't automatically become a trading signal. This is just a first-pass filter that narrows down "stocks worth paying attention to" — the actual trading decision still requires separate logic built on top of it (price patterns, volume changes, and so on), which I'll cover in later posts.
The Quirky Concept of Screen Numbers
Working with a brokerage API, you'll eventually run into something called a "screen number" — a unique identifier used to distinguish each data request when your program is tracking multiple stocks simultaneously. If screen numbers collide, data can get mixed up or fail to arrive correctly, so you typically need to pre-allocate a pool of screen numbers matching the maximum number of stocks you might track at once, then assign and release them as stocks enter and exit your tracking list.
These kinds of fine-grained constraints rarely make sense just from reading API documentation. You only really understand them once you've written the code, run it, and hit the question of "why isn't the data coming in" or "why does this occasionally get scrambled."
Today's Investing Insight — API Trading and the Individual Investor
Institutional and foreign investors have used algorithmic trading for decades. As domestic brokerages have opened up their APIs to individual traders as well, retail investors can now build systems with a similar underlying mechanism. Still, a meaningful gap remains between institutions and individuals. Institutions run dedicated lines and servers built for high-frequency trading, while individual-grade APIs simply can't match that speed. For individual traders using an API, the realistic approach isn't competing on raw speed — it's focusing on emotion-free, rule-based trading and disciplined data analysis instead.
---
This post documents a personal journey of building an algorithmic trading system and is not a recommendation of any specific stock or strategy. Automated trading through an API can result in unexpected losses due to system errors, network latency, and other technical issues. All investment decisions and their outcomes are the sole responsibility of the investor.
Comments
Post a Comment