Reviewed 13 August 2026
Retail API trading in India now sits inside a formal framework rather than being only a broker product feature. SEBI issued its safer-participation circular on 4 February 2025, exchanges published implementation standards, and brokers have been adapting their API onboarding and order tagging. The practical effect for a retail developer is that app activation, static IP, session handling, order tagging, risk controls, and broker-specific requirements must be checked before deployment.
This is an operational summary, not legal advice. Exchange and broker implementation can change, so verify the cited circulars and your broker’s current instructions for the account and segment you use.
What changed for retail API users
The framework separates responsibilities among investors, brokers, algo providers, and exchanges. It aims to make API-originated orders identifiable and controlled without preventing technically capable retail clients from using their own systems.
Important implementation themes include:
- client API access linked to an approved setup;
- whitelisted static IP addresses for client-generated API algos;
- daily API-session logout before the next trading day;
- appropriate identification or tagging of API-originated algo orders;
- broker risk controls and surveillance;
- different treatment for client-developed systems and empanelled providers;
- registration requirements where an algo crosses the defined order-rate threshold or otherwise falls into a registered category.
Do not reduce the framework to a single slogan such as “all retail algos need registration.” The applicable path depends on who developed and operates the algo, how it connects, order rate, broker implementation, exchange rules, and the product or segment.
Static IP: the first deployment decision
NSE’s implementation standards state that a client using API access for a client-generated algo must provide a static IP to the broker. A primary address and an optional secondary address can be used for redundancy, subject to the current standards and broker process.
That affects architecture:
- a laptop on frequently changing consumer internet is not a stable production endpoint;
- a cloud server should use a reserved public IP;
- failover must use an address already permitted by the broker;
- changing infrastructure may require an IP update before orders are accepted;
- credentials should not be moved casually between machines.
The static IP identifies a permitted origin. It does not replace authentication, encryption, risk checks, or account controls.
Check your broker’s compliant app process
Each broker exposes the framework through its own app dashboard, API credentials, permissions, and support process. Before writing order code, confirm:
- whether a new compliant app must be created or activated;
- the primary and secondary static-IP fields;
- the exact redirect URL rules;
- permitted exchanges, segments, products, and order types;
- whether old credentials still support order placement;
- session expiry and daily login behavior;
- how API orders are tagged;
- current rate limits and order-per-second treatment;
- whether provider or client-developed logic changes the onboarding path.
Save dated screenshots or notes of the broker’s settings, but treat the live broker documentation as authoritative when details change.
Order-rate thresholds and registration
The framework and exchange standards use order-per-second thresholds to distinguish certain unregistered client algos from algos that require registration. The widely referenced threshold is 10 orders per second, but implementation details and counting rules must be read in the current exchange standards.
Do not design a system to hover just below a threshold. A retail application should normally impose much lower internal limits based on its legitimate strategy needs, account risk, and the broker’s current API limits.
Controls should count submitted, modified, and cancelled order activity as required by the applicable rules and broker implementation. A retry storm can create compliance and risk problems even when the trading logic intended only one position.
Daily session handling
The NSE standards require API sessions to be logged out before the next trading day. Brokers also use time-limited access tokens. Build a daily state machine:
- start with trading disabled;
- complete the supported user authentication flow;
- verify profile, account, segments, and permissions;
- enable the approved strategies only after checks pass;
- stop new orders before the configured cutoff;
- reconcile orders and positions;
- invalidate or close the session according to broker requirements;
- start the next day from a disabled state again.
Never automate passwords, PINs, or TOTP values merely to avoid the broker’s supported login process.
API order controls the broker will not design for you
Regulatory compliance does not make a strategy safe. Your application still needs:
- one durable ID for each signal event;
- duplicate-order prevention;
- allowlisted accounts, strategies, instruments, products, and sides;
- maximum quantity and notional per order;
- maximum open position and daily order count;
- daily loss and kill-switch rules;
- stale-signal rejection;
- market-session checks;
- reconciliation after a timeout or restart;
- alerts for rejection, partial fill, unknown state, and connectivity loss;
- immutable audit logs without stored secrets.
A successful API response is not proof of exchange execution. Follow the broker’s order state until it reaches a known outcome.
Client-developed system or algo provider?
Clarify where the logic runs and who controls it.
A technically capable client running personal logic through a broker’s direct API is different from a vendor distributing the same black-box strategy to many users. Providers may need empanelment, registered strategies, hosted controls, and additional obligations. Marketing a shared service as “personal software” does not change how it operates.
If you sell, distribute, or operate trading logic for others, obtain professional compliance advice and written broker guidance before onboarding users.
Claims to avoid
Do not market an algo with guaranteed returns, guaranteed accuracy, risk-free automation, or an implication that regulatory registration proves profitability. SEBI’s master circular restricts references by brokers and associated platforms to past or expected algorithm performance except within the specified verified framework.
Backtests should disclose data, costs, assumptions, and limitations. They are research evidence, not a promise.
Retail API readiness checklist
- Read the current SEBI circular and relevant exchange standards.
- Identify whether the logic is client-developed, broker-provided, or provider-supplied.
- Confirm the applicable registration and order-rate treatment with the broker.
- Activate the current compliant API app.
- Whitelist the correct static IP and tested secondary address if supported.
- Use the broker’s supported login and daily session process.
- Verify segments, products, order types, and permissions.
- Implement risk, idempotency, state, audit, and kill-switch controls.
- Test rejection, timeout, reconnect, restart, and partial-fill behavior.
- Keep dated records of broker instructions and system changes.
- Recheck rules before changing broker, server, IP, app credentials, or operating model.
What to ask your broker in writing
- Which API app or credential type should this account use in August 2026?
- Which static IPs are currently mapped?
- Which segments and order types are allowed through API algo orders?
- How are orders tagged and order-rate thresholds counted?
- Does this client-developed use case require registration?
- What is the daily authentication and logout requirement?
- What must change before a vendor or third party operates the system?
Keep the response with the deployment record. Verbal assumptions are hard to audit later.
This article is educational and is not legal, regulatory, investment, or trading advice.
Primary sources
- SEBI circular dated 4 February 2025: https://www.sebi.gov.in/legal/circulars/feb-2025/safer-participation-of-retail-investors-in-algorithmic-trading_91614.html
- NSE implementation standards: https://nsearchives.nseindia.com/content/circulars/INVG67858.pdf
- NSE retail-algo information: https://www.nseindia.com/static/trade/platform-services-non-neat-decision-support-tools-algorithm-trading
- NSE retail-algo FAQ: https://nsearchives.nseindia.com/web/sites/default/files/inline-files/FAQ_Retail%20Algo_03112025_NSE.pdf
- SEBI master circular for stock brokers: https://www.sebi.gov.in/sebi_data/attachdocs/jun-2025/1750158789381.pdf
Leave a Reply