Trading API
Your code, on the same rails our own order pad runs on
Flat ₹20 per executed order
Bring your trading ideas to life with technology-enabled market access. Yukti Trading APIs help eligible clients integrate their own applications, algorithms and trading systems with supported trading services.
- Orders and account
- HTTPS, JSONRequest and response. Everything that changes state goes through here.
- Live prices
- WebSocket streamOne connection, many instruments, pushed as they change.
- Historical data
- HTTPS, on requestCandles by instrument, interval and date range, for research.
- Fill notices
- Postback to your serverWe call a URL you register when an order changes state.
- Credentials
- API key and secretIssued per application. The secret never leaves your server.
- Session
- One trading dayThe access token expires daily and a fresh login is needed.
- Brokerage
- ₹20 per executed orderThe same flat fee whether a human or a program sent it.
Endpoint paths, field names, response shapes, rate limits, subscription fees and the list of supported segments are set out in the developer documentation and are versioned there. This page describes the architecture and the obligations, both of which outlast any particular release. The documentation and your contract note are the authoritative record.
Three risks that belong to programmatic trading alone. First, speed: a defect that a human would catch on the second click is sent a thousand times by a loop, and every one of those orders is a real order in your name for which you are responsible. Second, silence: a socket that dies, a token that expires or a postback that never arrives leaves a program trading confidently on stale information, and the position it believes it holds stops matching the position it actually holds. Third, obligation: an order generated without a person approving that specific order is an algorithmic order, and running one without exchange approval is a regulatory breach and not merely a technical shortcut. Trading in securities and derivatives carries the risk of loss, which leverage magnifies. Nothing on this page is a recommendation to trade or to build any particular strategy.
Four things to settle before the first request
None of these are about code. All four are the reasons well-written programs still lose money in their first month.
An API is a second door, not a second account
It opens onto the same client code, the same ledger, the same margin and the same segment permissions you already have. An instruction sent by your program is indistinguishable, once it leaves us, from one you typed into the app, and it is settled, charged and reported exactly the same way.
Consequence: nothing the API can do is outside the rules that already govern your account.
Your code is the order pad
There is no confirmation screen between a mistake and the exchange. An off-by-one in a quantity, a sign flipped on a side, a retry that fires on a request that actually succeeded: each of them becomes a real position at a real price, and the market does not accept a bug report as a reason to unwind it.
Consequence: the ceilings, throttles and kill switch are part of the strategy, not an optional layer on top of it.
Automated is not the same as approved
If a person reviews and approves every individual order before it is sent, you are using a tool. If logic decides on its own that an order should exist, that is an algorithm, and it must be registered and approved by the exchange through us before it runs, with a unique identifier carried on every order it sends.
Consequence: the approval is a step in the build, not paperwork to catch up on afterwards.
Market data is licensed, not simply supplied
Prices, depth and historical candles originate with the exchanges and reach you under conditions: they are for your own use, within your own application, and passing them on to anyone else, displaying them publicly or building a product on top of them needs permission that is granted separately.
Consequence: read the licence before you put a quote on a public page or into a group chat.
Five interfaces, and each is good at one thing
They share one set of credentials and one account. They share almost nothing else: the protocol, the direction of travel, the failure mode and the right use for each are different, and most beginner problems come from asking one of them to do another one's job.
Orders and account
Request and response, over HTTPSThe workhorse. Your program sends an HTTPS request and receives JSON back. Everything that changes state lives here: placing, modifying and cancelling orders, and reading the order book, positions, holdings and funds.
- Stateless. Every request carries the access token, and nothing is remembered between calls.
- Synchronous in shape but not in meaning: the response tells you the instruction was accepted, not that it was executed.
- Rate limited separately by kind of call, because placing an order and reading a portfolio do not cost the same to serve.
Typical uses
- Place, modify and cancel orders
- Read the order book, trade book and positions
- Read holdings, funds and margin requirements
- Fetch the daily instrument master
A success response means the order reached us and passed validation. It does not mean it reached the exchange and it certainly does not mean it filled. The order book is what tells you the outcome, and a program that assumes otherwise builds positions it does not know it has.
A person signs in once a day, and your program works for the rest of it
The flow exists to keep two things apart: the credential that identifies your application, and the credential that proves a human agreed to let it act on their account today.
Browser and personYour server onlyNo credential in this diagram is ever put in front-end code.
The secret never reaches a browser
The API key identifies your application and is not confidential. The secret proves that a request genuinely came from it, which is why the token exchange happens on your server and why a checksum is required. A secret compiled into a mobile app, a single-page front end or a public repository is a secret that belongs to everyone who looks.
If it leaks: regenerate it immediately. Anything issued against the old one stops working, which is the point.
One login a day, by design
The access token is deliberately short lived. A person has to sign in and clear two-factor authentication each trading day, which keeps an account from being traded indefinitely by a program nobody is watching any more. Build the login into your morning routine rather than trying to engineer around it.
Practical effect: a strategy that starts before someone has signed in will fail on its first request, so fail loudly rather than retrying in silence.
One key for one application
Keys are issued per application so that activity can be attributed to the thing that produced it. Two strategies sharing a key share a rate budget, share a blast radius and become indistinguishable in a log at exactly the moment you need to tell them apart.
Practical effect: separate the intraday strategy from the reporting script, and both from whatever you are experimenting with this week.
Eighteen things the interface can do for you
Filtered by what you are trying to achieve rather than by the shape of the URL. Open the ones that match your intention and ignore the rest.
Showing all 18 capabilities.
Place an order
POSTclick to know when to use it
Modify an open order
PUTclick to know when to use it
Cancel an order
DELETEclick to know when to use it
The order book for today
GETclick to know when to use it
The trade book
GETclick to know when to use it
The history of one order
GETclick to know when to use it
Positions
GETclick to know when to use it
Holdings
GETclick to know when to use it
Funds and margin
GETclick to know when to use it
Margin required for a basket
POSTclick to know when to use it
Profile and permissions
GETclick to know when to use it
The instrument master
GETclick to know when to use it
A quote snapshot
GETclick to know when to use it
Subscribe to a live feed
WSclick to know when to use it
Order updates on the same socket
WSclick to know when to use it
Historical candles
GETclick to know when to use it
Register a postback URL
HOOKclick to know when to use it
Handle a delivery safely
HOOKclick to know when to use it
Four tasks, in three languages, with the awkward parts left in
Every sample below is text on a page. Nothing here connects to anything, nothing is executed, and no key of yours is involved.
Authenticate. Three of the five steps happen in a browser with a person present. Only the exchange of the request token for an access token happens on your server, because only that step needs the secret.
# The login itself happens in a browser, not here. Send the person
# to the login URL with your API key attached; after they sign in
# we redirect to your registered URL carrying a request token.
#
# $LOGIN_URL?api_key=$API_KEY -> ...?request_token=XXXXXX
#
# Only the exchange below happens on your server, because only it
# needs the secret. The checksum is what proves the request is
# yours and not from whoever else saw that redirect.
CHECKSUM=$(printf "%s" "$API_KEY$REQUEST_TOKEN$API_SECRET" \
| sha256sum | cut -d" " -f1)
curl -sS -X POST "$API_BASE/session/token" \
-H "X-Api-Key: $API_KEY" \
--data-urlencode "request_token=$REQUEST_TOKEN" \
--data-urlencode "checksum=$CHECKSUM"
# The response carries the access token. Hold it in memory, send
# it on every later request, and expect it to stop working tonight.Placeholders in capitals are yours to supply from your own environment. Error handling here is deliberately explicit rather than tidy, because the failures it catches are the ones that cost money.
The limit is not the problem. Asking the wrong way is.
Every interface is rate limited, separately by kind, because placing an order and reading a portfolio do not cost the same to serve. Put the published figures from the documentation into the planners below and see whether the design you have in mind actually fits inside them.
Limits are per kind, not per account
Order placement, order reads, quote snapshots and historical requests each carry their own budget. Spending the whole quote budget on a polling loop does not slow down your orders, but it does mean the one snapshot you genuinely needed arrives as a rejection.
Design for it: know which budget each call in your program spends before you write the loop.
Throttle yourself below the ceiling
A program that runs at the published limit is one network hiccup and one retry away from exceeding it. Set your own ceiling comfortably underneath, queue rather than burst, and treat a rate rejection as a defect in your scheduling rather than as something to retry immediately.
Design for it: a token bucket in your client costs an afternoon and removes the whole class of problem.
Push beats pull, every time
Almost every rate-limit problem is a polling loop that should have been a subscription. One socket carries hundreds of instruments and costs nothing per update, while asking the same question every second costs a request every second and still tells you late.
Design for it: if you are asking the same question on a timer, you are using the wrong interface.
Where these numbers come from. The batch size and the published rate are stated in the developer documentation for the quote endpoints and are the only two figures here that are not yours to choose. The other two are your design. Nothing is fetched to fill them in, which is why this planner keeps working whatever the current limits happen to be.
Arithmetic on figures you supplied, and nothing else. It cannot see your key, your usage or the live limits. A design that only just fits is a design that stops fitting the first time you add an instrument.
An API does not change what you are charged. It changes how often you are charged it. Brokerage is a flat ₹20 per executed order whoever sent it, so a strategy that works an entry as ten small orders pays ten times what the same entry costs as one. That is not an argument against working an order, which is often exactly the right thing to do in a share that is not deep enough to absorb it. It is an argument for knowing the number before the strategy runs rather than reading it off a contract note at the end of the month.
Six steps, and the fourth one is not optional
The technical work is the easy half. The order below is the order that keeps a project from being stopped a week before it was meant to start.
API access is a facility on an ordinary account, not a separate product. The segments you intend to trade must already be activated on it, with the usual income proof where derivatives are involved, because the interface cannot reach a segment your account cannot.
You describe what you are building and are issued an API key and a secret for it, along with a registered redirect URL that the login flow will return to. One application, one key. If you are building two things, register two.
Complete the login flow, fetch the instrument master, read your funds, and place one small order from your own code and cancel it. Doing that manually, once, teaches more about the failure modes than a week of reading, and it proves the whole chain before any logic sits on top of it.
Any strategy that generates orders without a person approving each one is an algorithmic order flow, and it has to be approved by the exchange through us before it runs. You submit the strategy for approval, it is issued a unique identifier, and that identifier is carried on every order the strategy sends. Static IP and access controls are applied where they are required.
One instrument, the smallest size the contract allows, one strategy at a time. At the end of each day, compare what your program believes it did against the order book, the trade book and the contract note. The gaps that appear in that comparison are the defects worth fixing, and they never appear in a backtest.
Scale the quantity, not the number of moving parts, and keep a way to stop everything that does not depend on the strategy's own code being healthy. A daily loss cap that squares off and halts, a hard ceiling on quantity, and a person who is awake are all part of the system rather than additions to it.
What the rules ask of a program that trades
The framework for algorithmic access by retail clients is set by SEBI and implemented by the exchanges through brokers. The requirements below are the structural ones.
What counts as an algorithm
The test is whether a human decides on each individual order. A program that shows you a signal and waits for you to press send is a tool. A program that sends the order itself, on any logic at all, however simple, is an algorithm, and that includes a loop that merely repeats an order you designed earlier.
The grey area: if you are unsure which side of the line you are on, you are on the algorithm side. Ask us before it runs.
Registration and approval
An algorithmic strategy is submitted through the broker for exchange approval before it goes live, with a description of what it does. Approval attaches a unique identifier to that strategy, and the identifier travels on every order it sends, which is what makes order flow attributable after the fact.
It applies to changes too: altering what an approved strategy does is a change to the approved thing, not a deployment.
Identifiable origin
Order flow from an approved algorithm has to be traceable to a known source, which is why a static address and controlled access to the credentials are required where the rules call for them. An anonymous or shifting origin is not an inconvenience to work around; it is the condition that makes approval possible.
Practical effect: decide where the strategy will run before you build it, not after approval.
Throughput and behaviour limits
Orders per second, the ratio of orders placed to trades actually done, and turnover limits are applied at broker and exchange level. They exist to keep one participant from loading the order book with instructions that were never meant to trade, and exceeding them is a compliance event rather than a technical error to retry past.
Practical effect: a strategy that places and cancels constantly needs to be designed against these from the first line.
An audit trail you can actually produce
Records of what the strategy did and why are expected to exist and to be retained. In practice that means a log line for every order with its strategy identifier, its parameters and the state it reached, kept somewhere that survives the machine it was written on.
Write it for a stranger: the person asking will not have your code in front of them.
What is never permitted
Sharing or selling access to your credentials, running an unapproved strategy, redistributing the market data feed, and any order pattern whose purpose is to create a false impression of price or volume rather than to trade. Trading against yourself deliberately is in that last category.
Consequence: these are grounds for the facility to be withdrawn and for the matter to be reported.
This is a description of the structure of the framework and is not legal or compliance advice. SEBI circulars and exchange requirements on algorithmic access are amended from time to time, and the requirements that apply to you are the ones in force on the day your strategy runs. Confirm them with our compliance desk before you go live.
Six habits that separate a hobby project from a trading system
None of these are exotic. Every one of them is on this list because leaving it out has cost somebody an account.
The secret is a credential, not configuration
It belongs in an environment variable or a secret store, read at start up, and nowhere else. Not in the repository, not in a notebook you will share, not in a screenshot, not in a support message. Version control remembers a deleted line perfectly well.
If it has ever been committed: treat it as public and regenerate it, even if the commit was removed.
The access token spends money
For the rest of the trading day it is enough, on its own, to place orders on your account. Hold it in memory, pass it only over HTTPS, keep it out of logs and out of URLs, and do not let a debugging print put it somewhere it can be read tomorrow.
Useful habit: redact anything token-shaped in your logging layer rather than at each call site.
Your postback URL is a public door
Anyone can send a request to it, so the signature on a delivery is what makes it believable and an unverified body is just something a stranger typed. Answer immediately, do the real work afterwards, and make the handler safe to run twice on the same message.
Then reconcile: a missed delivery should be caught by a timer, not discovered at settlement.
Log the decision, not just the request
Recording that an order was sent tells you nothing useful at four in the afternoon. Recording the inputs the strategy saw, the rule that fired, the identifier it tagged and the state the order reached lets you answer the only question that matters, which is why it did that.
Minimum: timestamp, strategy identifier, instrument, side, quantity, price, order identifier, final state.
Treat silence as a failure
A socket with no heartbeat, a request that times out, a postback endpoint that has heard nothing all morning: each of those is information, and the safe interpretation is that the program no longer knows the state of the world. Stop trading and reconcile, rather than carrying on with the last price you were told.
Rule of thumb: if you cannot prove the data is current, you cannot act on it.
Keep a switch you can reach from anywhere
Something that squares off open positions and stops the strategy, that works from a phone, and that does not depend on the strategy's own process being healthy to be obeyed. You will need it on the day the code is behaving in a way you do not yet understand, which is the day it is hardest to think clearly.
Backstop: our dealing desk can square off and disable the facility if you call, which is worth knowing before you need it.
Every line, what it is charged on, and who charges it
The rates move with circulars and with the Finance Act, so the table below gives you the structure and tells you where the current number is published.
| Line item | Calculated on | Levied by | Where the current rate is published |
|---|---|---|---|
| Brokerage | Nothing. It is a flat amount per executed order, whether the order came from a person or a program. | Yukti | ₹20 per executed order |
| API subscription | Each application key, charged for the period it is active. | Yukti | The published tariff sheet |
| Historical data subscription | Access to the historical candle interface, charged separately from order access. | Yukti | The published tariff sheet |
| Exchange transaction charge | Turnover, at rates that differ by exchange and by segment. | Exchange | Exchange circular, revised periodically |
| Securities transaction tax | The sell side in equity and equity derivatives, and on delivery purchases, at rates that differ by segment. | Government | Notified rate, in the Finance Act |
| Commodities transaction tax | The sell side of non-agricultural commodity derivatives. Notified agricultural commodities are exempt. | Government | Notified rate, in the Finance Act |
| SEBI turnover fee | Turnover. | SEBI | SEBI circular |
| Stamp duty | The buy side, at rates that differ by instrument. | State | Uniform rates notified under the Stamp Act |
| Goods and services tax | Brokerage plus the transaction and regulatory charges, not the traded value. | Government | Prevailing GST rate |
| Depository charge | Each scrip sold from demat on a given day, regardless of quantity. | Depository | The published tariff sheet |
Your contract note sets out every one of these separately, by name, for each trade day, and it is the authoritative record of what you were charged. A strategy that models brokerage and forgets the statutory lines will report a profit the ledger does not agree with.
Check the design against the limits before you write the loop
The two planners above take the published figures and your own intentions and tell you, in a second, whether what you are imagining fits.
The trading API glossary
Every term you will meet in the documentation, in a rejection message or in a compliance conversation, defined in one or two sentences.
All 57 terms.
The credential your program sends on every later request. It authorises orders on your account, which is why it stays out of logs and URLs, and it expires at the end of the trading day.
Any order generated by logic rather than approved individually by a person. It requires exchange approval through the broker before it runs, however simple the logic is.
The public identifier issued to a registered application. It says which program is calling and does not by itself authorise anything.
The confidential half of the credential pair, used on your server to prove a token exchange came from you. It never belongs in a browser, a mobile app or a repository.
The retained record of what a strategy did, with its identifier on every order, detailed enough for someone who has never seen your code to reconstruct the day.
The volume-weighted price at which an order has filled so far. It differs from the price you asked for whenever the order filled in pieces.
Waiting progressively longer between reconnection or retry attempts, so that a failing dependency is not hammered while it recovers.
Running a strategy over historical data. It has no spread to cross, no queue to wait in and no rejections, so it flatters almost every strategy it touches.
Several orders assembled and sent as one instruction, so that a multi-leg position is established together rather than leg by leg.
Anything that grants access simply by being presented, with no further proof of identity. An access token is one, which is why it is treated like a password.
The open, high, low and close of an instrument over a fixed interval, with the volume traded in it. The unit of historical data.
A hash of the API key, the request token and the secret, sent with the token exchange to prove the request came from the holder of the secret.
The identifier of the trading account itself. It is the same whether an order came from the app or from your program.
A package that wraps the same HTTPS and socket calls in the idioms of a language. A convenience over the interface, not a different interface.
The bids and offers resting at successive price levels rather than only the best one. Delivered in the fuller streaming modes.
A single addressable operation in the HTTPS interface, identified by a path and a method.
A periodic message that proves a connection is still alive. Its absence is the earliest signal that a feed has gone stale.
Past prices supplied on request rather than streamed, for research and charting, usually under a subscription of its own and with licence conditions attached.
Shares held in demat from delivery purchases settled on earlier days. A different thing from positions, and a different read.
Safe to do more than once with the same result. A postback handler has to be, because deliveries can repeat.
The daily list of tradable instruments with tokens, symbols, lot sizes, tick sizes and expiries. Fetch it once a day and cache it locally.
The numeric identifier the quote and streaming interfaces use for an instrument, rather than its human-readable symbol.
A means of stopping a strategy and squaring off that does not depend on the strategy's own process being healthy enough to obey it.
The price of the most recent trade in an instrument. The lightest streaming mode delivers this and little else.
The time between something happening and your program acting on it, including the network, your own code and the exchange.
The terms under which exchange prices reach you. Use inside your own application is permitted; passing them to anyone else is not, without separate permission.
How much detail the socket sends for a given instrument, from the price alone to the full order book. It is set per instrument.
Every order placed in the current session with its present state. The authoritative answer to what your program has actually done today.
The reference returned when an order is accepted, used for every later modification, cancellation or read of that order.
The number of orders placed against the number that actually traded. Limits exist to discourage loading the book with instructions never meant to trade.
An order that has traded for some of its quantity and remains open for the rest. One order can produce many trades.
Asking the same question repeatedly on a timer. Almost always the wrong tool where a subscription exists, and the usual cause of a rate-limit problem.
Today's exposure and what is carried forward, with quantity, average price and running profit or loss. The number a risk check should be written against.
An HTTPS request we send to a URL you registered whenever one of your orders changes state, so your server is told rather than having to ask.
Whether a position is intraday, taken for delivery or carried in a margin product. It decides the margin and whether it is squared off automatically.
The number of requests per second an interface will accept, published separately for each kind of call.
Comparing what your program believes it did against the order book, the trade book and the contract note. The gaps that appear are the defects worth fixing.
The address we return the browser to after a successful login, carrying the one-time request token.
An order refused at validation, by us or by the exchange, with a reason attached. It is information, not something to retry blindly.
The one-time value delivered to your redirect URL after login, exchanged on your server for an access token.
The request and response style used for orders and account state: your program asks, we answer, and nothing is remembered between calls.
Many failed requests retried at once, turning a brief outage into a rate-limit breach. Backoff and a little randomness prevent it.
The day-long authorisation created by the token exchange and ended when the access token expires.
The difference between the price a strategy assumed and the price it actually received. The largest single gap between a backtest and a live run.
Closing an open position by trading the opposite side of it.
A fixed network address from which approved algorithmic order flow originates, required where the rules call for it, so that the flow is attributable.
The unique tag attached to an approved algorithm and carried on every order that algorithm sends.
Telling the socket which instruments to push to you. One connection carries many, which is why it replaces every polling loop.
A short label of your own attached to an order and returned on every later read of it, used to tell one strategy's orders from another's.
A ceiling you impose on your own request rate, set below the published limit so that one retry does not breach it.
One update from the feed for one instrument. The same word also means the smallest permitted price increment, and context decides which is meant.
A common way to throttle: requests spend tokens that refill at a fixed rate, so bursts are smoothed out rather than rejected.
The executions of the day, each with its own fill price, quantity and time, as distinct from the instructions that produced them.
The second proof of identity required at login, and the reason a person has to be present each morning before a program can trade.
How long an order lives if it does not fill: for the day, or until it is cancelled within the session, depending on what the exchange supports.
The general name for a server-to-server callback. A postback is one.
A single long-lived connection over which the server pushes messages without being asked. The right tool for anything live.
Commonly asked about the API
Do I need a separate account to use the API?
click to see the answer
Is a strategy I wrote myself still an algorithm?
click to see the answer
Why does the access token expire every day?
click to see the answer
I got a success response. Did my order go through?
click to see the answer
Can I poll for prices instead of using the socket?
click to see the answer
What happens when my socket disconnects?
click to see the answer
Does the API cost extra, and is the brokerage different?
click to see the answer
Can I let a friend or a vendor use my key?
click to see the answer
Can I put live prices from the feed on my own website?
click to see the answer
My backtest is excellent. What should I expect live?
click to see the answer

