How a program reaches the market

When you tap "buy" in a trading app, a lot happens that you never see. The app packages your request, sends it over the internet to the broker's computers, the broker checks it and forwards it to the exchange, and a confirmation travels back. A broker API is simply a way to do all of that from your own program instead of your thumb. API stands for application programming interface, and for our purposes it means the set of defined requests a broker accepts from software: log in, tell me the price, tell me my positions, place this order, cancel that one. Learn the shape of it here, because the chapters after this one use it constantly.

Two shapes: asking, and being told

Most of what an API offers takes the shape of a request and a response. Your program asks a question, such as "what is the price of Reliance," or gives an instruction, such as "buy 10 shares," and the broker sends back one answer. This is often called a REST interface, and you can picture it as a conversation of single questions and single answers. You met exactly this shape in Python for Trading when you fetched historical data: one request, one table back.

The simulated broker you built works this way. You call get_quote and get one quote back; you call place_order and get one order back. Here is that request-response rhythm, asking a quote for each stock on a small watchlist.

# A broker API answers one request at a time. This is the request-response (or
# REST) pattern: you ask a question, you get one answer back. Here we ask the
# simulated broker the same kind of question you would ask a real one, a quote
# for each symbol on a watchlist, and count the round trips.
from paper_broker import PaperBroker

broker = PaperBroker(prices={"RELIANCE": 1400, "INFY": 1500, "TCS": 3200})

watchlist = ["RELIANCE", "INFY", "TCS"]

requests = 0
for symbol in watchlist:
    quote = broker.get_quote(symbol)        # one request-response call
    requests += 1
    print(f"request {requests}: {symbol:<9} last {quote['last_price']}")

print(f"\n{requests} requests for {len(watchlist)} symbols.")
print("Polling every symbol like this, over and over, is wasteful.")
print("For live prices you want a stream instead (chapter 8).")

request 1: RELIANCE  last 1400
request 2: INFY      last 1500
request 3: TCS       last 3200

3 requests for 3 symbols.
Polling every symbol like this, over and over, is wasteful.
For live prices you want a stream instead (chapter 8).

Three symbols, three separate requests. That is fine for three. But imagine wanting live prices for fifty symbols, updating every second. Asking fifty questions a second, over and over, is wasteful and slow, and brokers limit how often you may ask. For a stream of live prices there is a better shape: the streaming connection, often a WebSocket, where you subscribe once and the broker pushes new prices to you as they happen, without your asking again. You will use that in a couple of chapters. For now, hold the distinction: request-response for actions and one-off reads, streaming for a live flow.

The broker's own SDK is the front door

You could talk to a broker's API by hand, building each web request yourself, but you rarely should. Most brokers publish an official software development kit, an SDK, which is a small library in Python that wraps their API in ready-made functions. Instead of assembling a raw request, you call a function like the ones below. Prefer the broker's own official SDK, because the people who run the API maintain it and it handles the fiddly parts correctly.

# A broker's official Python SDK, shown generically (no broker named) and NOT
# run here: it needs your credentials and a live connection.
from broker_sdk import BrokerClient          # the exact name varies by broker

client = BrokerClient(api_key="...", access_token="...")
funds = client.get_funds()                   # a request-response call
positions = client.get_positions()
quote = client.get_quote("NSE:RELIANCE")

Notice that the method names are the same shape as the simulated broker's. That is deliberate. Everything you practise against the simulator maps directly onto a real SDK, so the ideas carry over even though the exact library does not.

Tokens and rate limits

Two practical things shape every real API session. The first is authentication by token. You do not send your password with every request. You log in once to receive an access token, a temporary pass that proves who you are, and your program presents that token on each call. Tokens usually expire, often at the end of the trading day, so a live system logs in fresh each morning. The next chapter is entirely about doing this safely.

The second is rate limits. A broker caps how many requests you may send in a second or a minute, to protect its own systems and the exchange. Go over the cap and your requests are refused for a while. This is one more reason to prefer a subscription stream over rapid polling, and to design a program that asks only for what it needs. Respecting the rate limit is not just courtesy: a program that trips it can miss the very moment it meant to act.

Start read-only

Here is the habit that makes learning an API safe. Start with the calls that only read, never the ones that write. Reading your funds, your positions, and a quote changes nothing, so you can run those against a real account all day without risk while you learn the library and confirm your setup works. Only once the reads are solid, and only much later in this course, do you touch the calls that place orders. In a real account, a read is a question and an order is a consequence. Learn to ask before you learn to act.

What to carry forward

A broker API is the set of requests a broker accepts from software, and it comes in two shapes: request-response for actions and single reads, and a streaming connection for a live flow of prices. You reach it best through the broker's own official SDK, whose functions mirror the simulated broker you already use. Every session authenticates with a temporary access token and lives within the broker's rate limits. The safe way in is read-only: reads change nothing, so they are where you start, long before you place an order. The next chapter takes the login itself seriously, because handling your credentials badly is one of the fastest ways to lose money.