Overview & Setup
Detailed technical reference, validation parameters, schemas and client code orchestrations.
Introduction
Welcome to Bigul Connect
Bigul Connect provides secure APIs and WebSocket services to help developers, traders, fintech platforms, and algo providers build trading applications, automate strategies, access real-time market data, and manage investment products.
Whether you’re building a trading platform, an algorithmic trading system, a portfolio analytics dashboard, or a fintech application, Bigul Connect offers access to trading, portfolio, market data, recommendations, and mutual fund services through a unified API ecosystem.
What Can You Build?
Available APIs
Authenticate users and securely access Bigul Connect services.
Place orders, validate margins, and manage trading activity.
Access holdings, positions, trades, and account information.
Retrieve instrument information and market reference data.
Stream real-time market data, order updates, and trade activity.
Execute basket orders, cover orders, bracket orders, and advanced trading strategies.
Create, publish, and manage recommendations.
Access mutual fund data and investment workflows.
REST APIs vs WebSockets
URL & Source Mapping
Bigul Connect provides separate API environments for client and partner integrations. Before making API requests, ensure you're using the correct base URL and source value for your application.
API Environments
| Integration Type | Base URL | Source |
|---|---|---|
| Client APIs | capi.bigul.co | B2C |
| Partner APIs | papi.bigul.co | B2B |
| Partner UAT Environment | servicestest.bigul.co | B2B |
Understanding Source Values
The source parameter identifies the type of integration making the API request.
| Source | Description |
|---|---|
| B2C | Used for client-level integrations and individual trading accounts |
| B2B | Used for partner, vendor, and fintech platform integrations |
Use the source value associated with your API environment when making requests.
What Can You Build?
With Bigul Connect APIs, you can:
Typical Integration Flow
Onboarding Flows
Self-Trading & Custom Algo setup
Register / Login to Bigul Connect using Bigul credentials with TOTP authentication.
Create an App inside dashboard to obtain App Key & Secret.
Whitelist static server/VPS IPs under Security settings.
Register and configure Algo rules under 'My Algos' sector.
Initiate credentials authorization and authenticate programmatically.
* Ideal for self-implemented Python scripts, webhooks, or execution environments.
Fintech Platforms & Strategy Vendors
Partner Signup
Submission of details on the portal
Capability Walkthrough
Platform demo & fit analysis
Compliance Check
Sign compliance agreement & SLA
Sandbox Integration
Testing inside UAT Sandbox
Go-Live Authorisation
Live production credentials issued
* Interactive OAuth redirection enables secure SSO client logins.
Security Setup & TOTP Activation
Bigul Connect enforces strong, SEBI-aligned multi-factor authentication. Clients require mandatory Time-Based One-Time Password (TOTP) activation. You can activate TOTP by scanning the unique QR code inside Safety settings via Google Authenticator, Microsoft Authenticator, or Authy. Every API key login validation requires sending the active 6-digit TOTP (valid for 30s) securely.
Time-Based One-Time Password (TOTP)
Time-Based One-Time Password (TOTP)
TOTP (Time-Based One-Time Password) is an additional security layer used by Bigul Connect to protect accounts, API access, and trading activity.
Unlike a regular password, a TOTP is a temporary 6-digit code generated by an authenticator application. The code changes automatically after a short period and can only be used once, making unauthorized access significantly more difficult.
Once enabled, TOTP becomes a mandatory part of the authentication process.
Why is TOTP Required?
TOTP helps secure your account and API access by adding an additional verification step during authentication.
Key benefits include:
TOTP is mandatory for sensitive operations such as API authentication and algo trading access.
Supported Authenticator Applications
You can use any standard TOTP-compatible authenticator application, including:
How TOTP Works
Each TOTP code is valid for 30 seconds and expires automatically.
TOTP Activation Process
Follow the steps below to enable TOTP for your account:
Step 1: Login to Bigul Connect
Access your Bigul Connect account and open the dashboard.
Step 2: Navigate to Security Settings
Go to: Security Settings or API Access
Step 3: Enable TOTP Authentication
Turn on TOTP authentication for your account.
Step 4: Scan the QR Code
Open your authenticator application and scan the QR code displayed on the screen.
Step 5: Verify the Code
Enter the generated 6-digit code to confirm activation.
Once activated, TOTP becomes mandatory for login and authentication.
TOTP During Login
When logging in to Bigul Connect, you may be required to provide:
Each TOTP is valid for 30 seconds and expires automatically.
API Login with TOTP
TOTP validation is required when authenticating through Bigul Connect APIs, including:
Login attempts with expired or incorrect TOTP values will be rejected.
Security Guidelines
To keep your account secure:
TOTP Reset & Re-Linking
TOTP can be reset through the Bigul Connect Dashboard. If you're unable to access your authenticator application, contact Bigul Support for verification-based assistance.
Important Notes
Compliance & Audit
Bigul Connect implements TOTP using industry-standard authentication practices.
TOTP follows RFC 6238 standards
Authentication events are logged and auditable
TOTP is mandatory for API access and algo trading enablement
Live trading and API access require successful TOTP validation
Key Notes
SEBI Compliance & OTR
Detailed technical reference, validation parameters, schemas and client code orchestrations.
SEBI Circulars & Guidelines
Bigul Connect APIs are designed and operated in accordance with applicable regulations issued by SEBI, NSE, and BSE for API-based and algorithmic trading.
These regulations help ensure secure market access, investor protection, risk management, and compliance with exchange requirements.
Why Are These Guidelines Important?
If you're building trading applications, algo trading systems, or API-based execution platforms, certain regulatory requirements may apply to your integration. These guidelines help define:
What Does This Mean for Developers?
Depending on your use case, you may be required to:
Most individual traders and developers can start with the standard onboarding process and follow the applicable requirements based on their algo classification.
Regulatory References
The following circulars and implementation standards form the foundation of Bigul Connect's compliance framework.
| Regulator / Exchange | Circular Number | Circular Title | Date | Relevance |
|---|---|---|---|---|
| SEBI | SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/0000013 | Safer Participation of Retail Investors in Algorithmic Trading | 04-Feb-2025 | Retail algo framework, API controls, client safeguards, and approvals |
| SEBI | SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/108 | Extension of Timeline for Retail Algo Framework | 29-Jul-2025 | Implementation timelines and phased rollout |
| SEBI | CIR/MRD/DP/09/2012 | Broad Guidelines on Algorithmic Trading | 30-Mar-2012 | Foundational algo governance and control principles |
| SEBI | CIR/MRD/DP/16/2013 | System Audit of Algorithmic Trading Systems | 21-May-2013 | Audit, logging, and compliance requirements |
| NSE | NSE/INVG/67858 | Implementation Standards for Retail Algorithmic Trading | 05-May-2025 | API tagging, throttling, validations, and risk checks |
| NSE | NSE/INVG/69255 | Empanelment of Retail Algo Providers | 22-Jul-2025 | Third-party algo provider onboarding |
| NSE | NSE/INVG/70309 | Update on Empanelment & Compliance | 19-Sep-2025 | Compliance updates and disclosure requirements |
| NSE | NSE/INSP/70900 | System Audit & Compliance Reference | 17-Oct-2025 | Audit scope and compliance reporting |
| NSE | NSE/INVG/70541 | Extension of Retail Algo Implementation Timeline | 30-Sep-2025 | Revised implementation timelines |
| BSE | — | Algo Trading & API Guidelines | — | Algo trading and API compliance requirements |
⚠ Important Notes
Algo Classification & Regulatory Onboarding
Bigul Connect requires every algo to be classified during app creation and algo registration. The selected classification determines the applicable compliance requirements, order placement limits, and whether exchange approval is required before enabling live trading.
Understanding Algo Types
When registering an algo, you must choose one of the following categories:
| Algo Type | SEBI Classification | OPS Limit | Exchange Approval |
|---|---|---|---|
| Non-Registered Algo | Retail / Low-Frequency | Less than 10 OPS | Not Required |
| Registered Algo | High-Frequency / Institutional | 10 or More OPS | Mandatory |
Algo Registration
During algo registration, you must specify whether your algo is Registered or Non-Registered. All algo submissions are reviewed and verified by the Bigul Connect API Support & Compliance Team before approval.
A Registered Algo is applicable for strategies that place 10 or more orders per second (OPS). Since these algos operate at higher frequencies, additional exchange-level approvals and compliance requirements apply.
Required Details
Exchange empanelment and compliance approval are mandatory before live trading can be enabled for a Registered Algo.
A Non-Registered Algo is applicable for strategies that place fewer than 10 orders per second (OPS). These algos are typically used for retail and low-frequency trading and do not require exchange empanelment.
Default Configuration
| Field | Value |
|---|---|
| Algo ID | 99999 |
| Algo Category ID | 1 (Non-Registered) |
| OPS Limit | Less than 10 OPS |
| NNF ID (OMS Handling) | 444444444444 |
Exchange empanelment is not required for Non-Registered Algos.
Understanding OPS (Orders Per Second)
OPS stands for Orders Per Second and represents the maximum number of orders your algo places in one second. This value determines whether your algo is classified as Registered or Non-Registered.
| OPS | Classification |
|---|---|
| Less than 10 OPS | Non-Registered Algo |
| 10 OPS or More | Registered Algo |
Trading Environment Access Rules
Allowed without an Algo ID. Developers can test and validate strategies before moving to production.
Enabled only after successful Bigul Connect and SEBI compliance validation. Additional approvals may be required based on algo classification.
⚠ Important Notes
Static IP Configuration & Change Management
Bigul Connect uses static IP-based access controls to secure API activity and ensure compliance with exchange and regulatory requirements.
Before accessing production APIs, applications must be configured with approved static IP addresses. This helps prevent unauthorized access and ensures that API requests originate only from trusted environments.
IP Configuration Requirements
The following IP configuration rules apply based on the selected algo type:
| Algo Type | Primary IP | Secondary IP (Failover) | Remarks |
|---|---|---|---|
| Registered Algo | Mandatory | Allowed | Secondary IP can be configured for failover and redundancy |
| Non-Registered Algo | Mandatory | Allowed | Primary IP is required for order placement |
Understanding Primary & Secondary IPs
The primary IP address is the main server IP used for API communication and order placement.
A secondary IP can be configured as a backup in case the primary infrastructure becomes unavailable. This helps improve system reliability and business continuity.
IP Change Policy
To maintain platform security and compliance controls:
Family IP Sharing (Optional)
Bigul Connect provides an optional family-level declaration mechanism for eligible family members.
Exchange Empanelment
Exchange empanelment is currently supported through an offline/manual submission process.
Current Process
Digital empanelment workflows will be introduced in future versions of Bigul Connect.
OTR Compliance & Penalties
Bigul Connect continuously monitors API activity to ensure fair usage, platform stability, and regulatory compliance.
API usage is governed by limits related to:
Breaching these limits may result in temporary restrictions, escalating penalties, compliance reviews, or permanent suspension for repeated violations.
API Usage Limits
| Parameter | Limit | Action on Breach |
|---|---|---|
| Number of API Orders Allowed Per Day | 2,000 | Application is temporarily blocked for a defined period. Notification email is sent. Repeated violations may result in permanent blocking. |
| Total API Requests Allowed Per Day | 2,16,000 | API access may be restricted for the day. Excessive violations may trigger a compliance review. |
| Order-Trade Ratio (OTR) | 49:1 | Progressive penalties based on repeated breaches. |
| Allowed Orders Placed Per Second | 10 | API requests are automatically throttled and blocked temporarily. |
| Continuous API Requests (Per IP) | 3,000 requests per 5 minutes per IP | API requests are blocked for 1 minute and additional requests are rejected during the block period. |
Understanding OTR (Order-Trade Ratio)
Order-Trade Ratio (OTR) measures the relationship between order activity and executed trades.
OTR Formula
A = API hits for Order Place, Modify, and Cancel requests
B = Total Executed Trades
OTR = A ÷ B
Maximum Allowed OTR: 49 : 1
This means the number of order-related API actions should remain within the permitted ratio compared to completed trades.
OTR Violation Penalties
If the allowed OTR limit is breached, the following actions are applied:
| Breach Count | Penalty |
|---|---|
| 1st Breach | 15-minute block |
| 2nd Breach | 30-minute block |
| 3rd Breach | 1-hour block |
| 4th Breach | 2-hour block |
| 5th Breach | Full trading-day block |
Repeated violations may result in additional compliance actions.
Orders Per Second (OPS) Limit
The maximum allowed order placement speed is:
10 Orders Per Second (OPS)
If this limit is exceeded:
Continuous Request Limits
To ensure platform stability and prevent excessive API traffic:
Maximum: 3,000 Requests per 5 Minutes per IP Address
If the limit is exceeded:
📌 Important Notes
Authentication APIs
Detailed technical reference, validation parameters, schemas and client code orchestrations.
Client Authentication
Overview
Client Authentication allows individual Bigul clients to securely access Bigul Connect APIs using their trading account credentials.
The Login API validates the client's TOTP (Time-Based One-Time Password) and generates an authentication token that can be used to access trading, market data, portfolio, and other Bigul Connect services.
Once authenticated, the client can use APIs for trading, portfolio management, market data access, and automated strategy execution.
When Should I Use Client Authentication?
Use this authentication flow when you want to:
How It Works
Generate API Credentials
Create an application on Bigul Connect and generate:
x-api-key
x-api-secret
These credentials uniquely identify your application and are required for authentication.
Generate Access Token
Use your API credentials along with your Client Code and TOTP to authenticate.
Once the request is successfully validated, Bigul Connect generates an access token.
This token authorizes access to:
Example Header
| Key | Value |
|---|---|
| x-api-key: | {{YOUR APP KEY}} |
| x-api-secret: | {{YOUR APP SECRET}} |
Login
Parameters
| Field | Type | Description |
|---|---|---|
| source | String | Source of the request (e.g., CLIENT) |
| clientCode | String | Unique client identifier code |
| totp | String | Time-based One-Time Password for authentication |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
Request Body
{
"source": "{{APP SOURCE}}",
"clientCode" : "{{CLIENT USER ID}}",
"totp": "{{6 Digit Verification code}}" // On your Authenticator App
}Sample Responses
SUCCESS [200]
{
"status": true,
"message": "TOTP verified successfully",
"data": {
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
},
"error": null
}ERROR [200]
{
"status": false,
"message": "Invalid TOTP.",
"data": null,
"error": ""
}Understanding the Access Token
After successful authentication, Bigul Connect returns an encrypted access token.
This token is used to authenticate all subsequent API requests made on behalf of the client.
📌 Important Notes
What Happens Next?
After receiving the access token, include it in your API requests as specified in the API documentation.
You can now access:
Partner Authentication
Overview
Partner Authentication is designed for approved API Partners, Algo Vendors, and Fintech Platforms integrating with Bigul Connect.
This authentication flow allows partner applications to securely connect with Bigul systems, validate their credentials, and access authorized APIs on behalf of their clients.
Once authenticated, a Partner Session is created, which is required before accessing trading, order, portfolio, market data, and other partner-enabled services.
When Should I Use Partner Authentication?
Use this authentication flow when your platform needs to:
How It Works
Sign Up & Generate Keys
Register on Bigul Connect and obtain your unique:
x-api-key
x-api-secret
These credentials identify your application and are required for all partner-level API requests.
Generate Partner Session
Use your API credentials to authenticate and generate a Partner Session.
The generated session authorizes access to:
Partner Login
This API is used by authorized vendors to authenticate with the Bigul Connect platform and generate a Partner Session.
The session created through this API is required to access all subsequent Bigul Connect APIs on behalf of clients.
Upon successful authentication, a Session ID is issued. The session remains active until expiry or until it is explicitly logged out.
All API requests initiated by the partner must include an active session.
Key Points
Header Fields
| x-api-key: | {{VENDOR APP KEY}} |
| x-api-secret | {{VENDOR APP SECRET}} |
Body Fields
| Source | Source Code Assigned |
| Code | Partner ID assigned |
| password | Partner Password |
Request Headers
| Content-Type | application/json |
Request Body
{
"source": "{{SOURCE}}",
"code": "{{Partner's User ID}}",
"password": "{{Partner's Password}}"
}Sample Responses
Success [200]
{
"status": true,
"message": "Session created successfully.",
"data": {
"sessionId": "69a8287cff26d6923309cb....",
"expiryTime": "2025-12-30T19:00:00.000Z"
},
"error": null
}Understanding the Partner Session
After successful authentication, Bigul Connect generates a Partner Session ID.
This Session ID acts as your authenticated connection to Bigul Connect and must be included in subsequent partner API requests.
📌 Important Notes
Partner Logout
Overview
Partner Logout is used to terminate an active Partner Session created through the Partner Login API.
Once logged out, the associated Session ID becomes invalid and can no longer be used for API access.
This API should be called when your application has completed its operations or when you want to explicitly end an active session for security purposes.
Endpoint
Key Points
Request Headers
| Content-Type | application/json |
| x-access-token | 69a8287cff26d6923309cb1d4217674f |
Request Body
{
"source": "{{SOURCE}}",
"code": "{{Partner's User ID}}"
}Sample Responses
Success [200]
{
"status": true,
"message": "Session logged out successfully.",
"data": {},
"error": null
}What Happens After Logout?
Once a session is terminated:
SSO Authentication (Client Login via Partner)
Overview
SSO (Single Sign-On) Authentication allows partner applications to securely authenticate Bigul clients without directly handling client credentials.
This authentication flow is designed for third-party applications such as algo platforms, trading platforms, mobile applications, web applications, and fintech solutions that need to access Bigul APIs on behalf of authenticated clients.
Once the client successfully logs in through Bigul SSO, the partner application receives an encrypted authentication token that can be used to access trading, portfolio, and other client-level APIs.
When Should I Use SSO Authentication?
Use this flow when:
Why Use SSO?
This authentication model ensures:
Complete Flow Overview
The authentication process consists of five major stages:
Partner Initiates Login
Constructs redirect URL with app_key, sessionid & state
Client Redirected to Bigul SSO
Browser navigates to connect.bigul.co login page
Client Authenticates & Authorizes
User enters credentials, OTP & grants consent
Bigul Redirects Back with Token
Auth token returned to partner callback URL
Partner Uses Token in API Calls
Bearer token attached to all subsequent requests
Let's understand each step in detail.
Partner Creates Login URL
The partner application must redirect the client to the Bigul SSO login URL.
https://connect.bigul.co/login?app_key=bigul&sessionid={sessionId}&state={stateValue}Parameters Explained
| Parameter | Purpose |
|---|---|
| app_key | Partner's registered application key |
| sessionid | Unique session created by the partner system |
| state | Random string used for CSRF protection and request tracking |
What Happens Internally?
Before redirecting the user: Your application generates a unique sessionId, generates a secure state value, then redirects the user to the Bigul login page. These values help track the authentication request and improve security.
Client Authenticates on Bigul SSO
The client is presented with the Bigul authentication page. The user can authenticate using:
Authentication is handled entirely by Bigul. Partner applications never receive, store, or process client credentials.
Bigul Redirects Back to Your Application
After successful authentication, Bigul redirects the user back to the partner's registered redirect URL.
Example
https://yourapp.com/?login_success=true&userid=80126245&state=test123&token=s+4xF+iIYJU9emMt+8DY/GUResponse Parameters Explained
| Parameter | Meaning |
|---|---|
| login_success | Boolean confirmation indicating login status |
| userid | Bigul Client Code |
| state | Same state value sent in the original request |
| token | Encrypted authentication token |
Validate the State Parameter (Important)
After receiving the redirect response, your application must validate the returned state value.
Validation Process
This validation is an important security requirement and helps protect against CSRF (Cross-Site Request Forgery) attacks.
Understanding the Token
After successful authentication, Bigul returns an encrypted client token. This token:
Since tokens expire daily, clients must re-authenticate after token expiry.
How to Use the Token in API Calls
For all client-level API requests, including Orders, Positions, Holdings, Portfolio, and Trading APIs, include the following headers:
| Key | Value |
|---|---|
| x-api-key: | {{VENDOR APP KEY}} |
| x-api-secret | {{VENDOR APP SECRET}} |
| x-vendor-auth: | {{VENDOR SESSION ID}} |
| Authorization | Bearer {{CLIENT TOKEN}} |
What Happens Next?
Once the client token is obtained and included in the request headers, your application can securely access:
Risk & Margin APIs
Detailed technical reference, validation parameters, schemas and client code orchestrations.
Check Margin API
Overview
The Check Margin API is used to calculate the margin required for a specific order before it is placed.
Based on the order details provided, such as exchange segment, product type, quantity, price, transaction type, and instrument, the API evaluates whether the client has sufficient available funds and margin to execute the order.
This API is commonly used as a pre-trade validation tool to help prevent order rejections caused by insufficient margin and to ensure compliance with RMS (Risk Management System) checks before order placement.
Common Use Cases
Use this API when you want to:
Request Parameters
| Field Name | Type | Description | Example |
|---|---|---|---|
| source | String | Source of request | {{SOURCE}} |
| clientCode | String | Client code | {{CLIENTCODE}} |
| brnchId | String | Branch identifier | NA |
| exSeg | String | Exchange segment (e.g. nse_cm – NSE Cash, bse_cm – BSE Cash, nse_fo – NSE F&O, bse_fo – BSE F&O) | nse_cm |
| prc | String / Number | Order price | 12500 |
| prcTp | String | Price type | L (Limit) |
| prod | String | Product type | CNC |
| qty | String / Number | Quantity | 1 |
| tok | String | Instrument token | 11536 |
| trnsTp | String | Transaction type | B (Buy), S (Sell) |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"brnchId": "KALYANNAGAR",
"exSeg": "nse_cm",
"prc": "12500",
"prcTp": "L",
"prod": "CNC",
"qty": "1",
"tok": "11536",
"trnsTp": "B"
}Sample Responses
SUCCESS [200]
{
"status": true,
"message": "Request successful.",
"data": {
"avlCash": "12474366.00",
"insufFund": "0.00",
"stat": "Ok",
"totMrgnUsd": "0.00",
"mrgnUsd": "0.00",
"reqdMrgn": "12500.00",
"avlMrgn": "12474366.00",
"stCode": 200,
"tid": "server1_6204",
"ordMrgn": "12500.00",
"rmsVldtd": 0
},
"error": null
}Understanding the Response
The response contains margin and fund-related information that can be used to determine whether the order can be placed successfully.
Some commonly used fields include:
| Field | Description |
|---|---|
| reqdMrgn | Margin required for the order |
| avlMrgn | Available margin |
| avlCash | Available cash balance |
| ordMrgn | Margin calculated for the order |
| insufFund | Indicates insufficient funds, if applicable |
| stat | Margin validation status |
A successful response indicates that the margin calculation has been completed successfully and returns the required margin details for the specified order.
Required Margin API
Overview
The Required Margin API provides a comprehensive view of a client's margin availability, utilized funds, and RMS (Risk Management System) limits across different exchanges, market segments, and product types.
Unlike the Check Margin API, which calculates margin requirements for a specific order, this API helps you understand the client's overall trading capacity and risk position.
It returns detailed information related to available margin, utilized funds, premium margins, additional margin requirements, collateral values, and various trading limits maintained by the RMS system.
Common Use Cases
Use this API when you want to:
Request Parameters
| Field | Type | Description | Allowed Values / Example |
|---|---|---|---|
| source | String | Source of the request | CLIENT |
| clientCode | String | Unique client identifier | {{CLIENTCODE}} |
| seg | String | Market segment | CASH, CUR, FO, ALL |
| exch | String | Exchange | NSE, BSE, ALL |
| prod | String | Product type | CNC, MIS, NRML, ALL |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode" : "{{CLIENTCODE}}",
"seg": "ALL",
"exch": "ALL",
"prod": "ALL"
}Sample Responses
SUCCESS [200]
{
"status": true,
"message": "Request successful.",
"data": {
"AddPreExpMrgnMisPrsnt": "0.00",
"CurExpMrgnNrmlPrsnt": "0.00",
"CurPremiumNrmlPrsnt": "0.00",
"RmsPayOutAmt": "0.00",
"AdhocMargin": "0.00",
"MrgnScrpBsktCncPrsnt": "0.00",
"FoPremiumMisPrsnt": "0.00",
"tid": "server1_6228",
"MrgnVarNrmlPrsnt": "0.00",
"AmountUtilizedPrsnt": "0.00",
"SplMrgnMisPrsnt": "0.00",
"CurSpanMrgnNrmlPrsnt": "0.00",
"SlbmVarElm": "0.00",
"AuxRmsCollateral": "0.00",
"FoUnRlsMtomPrsnt": "0.00",
"AuxNotionalCash": "0.00",
"AuxAdhocMargin": "0.00",
"DaneLimit": "0.00",
"RmsMutualFundAmt": "0.00",
"RmsPayInAmt": "0.00",
"CurPremiumMisPrsnt": "0.00",
"SlbmLimit": "0.00",
"MarginWarningPrcntPrsnt": "0.00",
"MrgnVarMisPrsnt": "0.00",
"CurRlsMtomPrsnt": "0.00",
"RMSRequiredMargin": "0.00",
"ExposureMarginPrsnt": "0.00",
"NfospreadBenefit": "0.00",
"stCode": 200,
"CollateralValue": "0.00",
"AddMrgnNrmlPrsnt": "0.00",
"RmsCollateralMult": "0.00",
"CncMrgnVarPrsnt": "0.00",
"MfCashCollateral": "0.00",
"BoardLotLimit": "0",
"ComRlsMtomPrsnt": "0.00"
},
"error": null
}Understanding the Response
The response contains detailed RMS and margin-related information maintained by the risk management system. Depending on the client's account and trading activity, the response may include:
This information is commonly used for margin monitoring, risk analysis, trading dashboards, and portfolio-level fund visibility.
Difference Between Check Margin and Required Margin
| API | Purpose |
|---|---|
| Check Margin API | Calculates margin required for a specific order before placement |
| Required Margin API | Provides overall margin availability, RMS limits, utilized funds, and trading capacity |
Master & reference Data
Master & Reference Data (Pre-Trade Setup) Master & Reference Data APIs provide the essential market and instrument information required before placing or validating orders. These APIs help applications retrieve instrument details, exchange-specific identifiers, index information, lot sizes, and other reference data that are commonly used for symbol validation, instrument mapping, strategy setup, and order preparation. The data returned by these APIs is read-only, exchange-aligned, and intended to be used as a prerequisite for trading, order validation, and strategy execution. Using these APIs, you can: • Retrieve instrument and scrip information • Fetch exchange-wise index lists • Validate symbols and instrument identifiers • Access lot sizes and contract-related information • Configure trading applications before order placement • Build and maintain instrument master data These APIs provide the foundational market and instrument information required before placing orders, building trading strategies, or integrating trading workflows.
Scrip Info
Overview
The Scrip Info API retrieves detailed information for one or more trading instruments (scrips) based on the provided scrip identifiers.
It returns instrument-level metadata such as trading status, asset details, lot size, contract information, margin parameters, company details, and other exchange-provided attributes.
This API is commonly used to validate instruments before order placement, build instrument master databases, and retrieve contract specifications required for trading and strategy execution. The API supports multiple exchange segments including Equity, Derivatives, Currency, and Commodity markets.
Common Use Cases
Use this API when you want to:
Request Parameters
| Field | Type | Description |
|---|---|---|
| source | String | Source of the request (e.g., CLIENT) |
| clientCode | String | Unique client identifier of the client |
| scripArr | Array of String | List of scrip identifiers in the format should be pipe separated with script token |
Supported Exchange Segments
| Segment Code | Exchange |
|---|---|
| nse_cm | NSE (Cash Market) |
| bse_cm | BSE (Cash Market) |
| nse_fo | NFO (NSE Derivatives) |
| bse_fo | BFO (BSE Derivatives) |
| cde_fo | CDS (Currency Derivatives) |
| bcs_fo | BCD (Commodity Derivatives) |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode" : "{{CLIENTCODE}}",
"scripArr": ["nse_cm|21", "bse_cm|500325"]
}Sample Responses
SUCCESS [200]
{
"status": true,
"message": "Request successful.",
"data": [
{
"issDt": "--",
"refKey": "664UP30",
"brdLtQty": "100",
"trdSym": "664UP30-SG",
"cmpName": "SDL UP 6.64% 2030",
"strkPrc": "0.00",
"warn": "0"
}
]
}Understanding the Response
The response contains detailed instrument metadata returned by the exchange and trading system. Depending on the instrument type, the response may include trading symbol information, company name, lot size details, contract and expiry information, margin-related parameters, trading status and restrictions, instrument identifiers and reference keys, and exchange-specific instrument metadata.
This information is commonly used for instrument validation, contract discovery, strategy setup, and maintaining instrument master data within trading applications.
Index List
Base URLs & Environments
Replace {{baseUrl}} with the environment-specific base URL below. The full
endpoint is the base URL followed by /order/index-list.
| Environment | Base URL | source |
|---|---|---|
| Client (Production) | https://capi.bigul.co/api/v1 | CLIENT |
| Partner (Production) | https://papi.bigul.co/api/v1 | B2B |
| Partner (UAT) | https://servicestest.bigul.co/api/v1 | B2B |
Tip: For the full endpoint on the Client environment, call
https://capi.bigul.co/api/v1/order/index-list with source set to
CLIENT. See URL & Source Mapping for details.
Before You Begin
Every request to /order/index-list is authenticated. Before you call this
endpoint, you need an App Key and App Secret, plus a valid access
token. Complete the onboarding flow first:
Register or log in to Bigul Connect.
Create a New App from Dashboard → My Apps → Create New App.
Whitelist your static IP address for the app.
Generate your App Key and App Secret — these become the x-api-key and x-api-secret request headers.
Authenticate to obtain a Bearer access token and use all three credentials in your API calls.
TOTP-based authentication is mandatory for live trading and API access. It is not required for backtesting or paper trading.
In Plain Language
A market index is a single number that tracks how a group of stocks is doing overall. Popular Indian examples are Nifty 50 (the 50 largest companies) and Bank Nifty (major banking stocks). An index list is simply the menu of all such indices that an exchange offers.
A trader needs this list so a trading app can show which indices are available to watch, chart, or trade — for example, filling the dropdown where you pick "Nifty 50" or "Bank Nifty" before tracking its movement or placing an index-based trade.
Overview
The Index List API returns the list of market indices available for a specified exchange.
Based on the exchange code provided in the request, the API returns a structured list of benchmark, sectoral, thematic, and strategy-based indices supported by the exchange.
This API is commonly used to populate index selections in trading applications, support index-based strategies, and provide market reference data for analytics and dashboards.
Common Use Cases
Use this API when you want to:
Authentication
Every request to the Index List endpoint must be authenticated. Three headers are required
on each call: your App credentials (x-api-key and x-api-secret) identify your
application, while the Authorization bearer token authenticates the trading session. Requests
missing any of these are rejected before the endpoint runs.
| Header | What It Is | Where To Get It |
|---|---|---|
| x-api-key | Public App Key that identifies your integration. | Generated when you create an App in the Dashboard (My Apps → Create New App). |
| x-api-secret | Private App Secret paired with the App Key. Keep it confidential and never expose it client-side. | Issued alongside the App Key at App creation (My Apps → Create New App). |
| Authorization | Bearer {{JWT_TOKEN}} — the JWT access token for the authenticated session. |
Returned by POST {{baseUrl}}/auth/connect/login, which validates your TOTP and
issues the access token. Partner integrations use
POST {{baseUrl}}/partner/auth/session-login.
|
POST {{baseUrl}}/auth/connect/login to obtain a fresh token. A 401 response
indicates an expired or invalid token — treat it as a signal to refresh and retry.Common Authentication Errors
| Error | Cause | Resolution |
|---|---|---|
| Expired token (401) | The JWT access token has passed its day-valid window. | Re-authenticate via POST {{baseUrl}}/auth/connect/login and send the new token in
the Authorization header. |
| Invalid API key/secret | The x-api-key or x-api-secret value is incorrect, mismatched, or
belongs to a different App. |
Verify both values against the App in the Dashboard (My Apps). Regenerate the credentials if they were rotated or lost. |
| Missing Authorization header | The request was sent without the Authorization bearer token. |
Include Authorization: Bearer {{JWT_TOKEN}} on every request alongside the App key
and secret. |
Request Parameters
| Field | Type | Required | Description |
|---|---|---|---|
| source | String | Required | Integration source. Use CLIENT for client integrations, B2B for partner integrations. |
| clientCode | String | Required | Unique client identifier. |
| exch | String | Required | Exchange code. Allowed values: NSE, BSE. An unsupported value returns a 400 Invalid exchange code error. |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode" : "{{CLIENTCODE}}",
"exch": "NSE"
}Code Samples
Ready-to-use snippets for calling the Index List endpoint. Replace the placeholder credentials with the App Key, App Secret, and JWT access token from your Bigul Connect app.
cURL
curl --location 'https://capi.bigul.co/api/v1/order/index-list' \
--header 'x-api-key: {{x-api-key}}' \
--header 'x-api-secret: {{x-api-secret}}' \
--header 'Authorization: Bearer {{JWT_TOKEN}}' \
--header 'Content-Type: application/json' \
--data '{
"source": "CLIENT",
"clientCode": "{{CLIENTCODE}}",
"exch": "NSE"
}'Python (requests)
import requests
url = "https://capi.bigul.co/api/v1/order/index-list"
headers = {
"x-api-key": "{{x-api-key}}",
"x-api-secret": "{{x-api-secret}}",
"Authorization": "Bearer {{JWT_TOKEN}}",
"Content-Type": "application/json"
}
payload = {
"source": "CLIENT",
"clientCode": "{{CLIENTCODE}}",
"exch": "NSE"
}
response = requests.post(url, headers=headers, json=payload)
print(response.json())JavaScript (fetch)
const response = await fetch("https://capi.bigul.co/api/v1/order/index-list", {
method: "POST",
headers: {
"x-api-key": "{{x-api-key}}",
"x-api-secret": "{{x-api-secret}}",
"Authorization": "Bearer {{JWT_TOKEN}}",
"Content-Type": "application/json"
},
body: JSON.stringify({
source: "CLIENT",
clientCode: "{{CLIENTCODE}}",
exch: "NSE"
})
});
const data = await response.json();
console.log(data);Tip: the same request can be imported directly into Postman — paste any of the snippets above using Postman's Import → Raw text option to generate a ready-to-run request.
Try It
Ready to see it in action? Open the interactive console with this endpoint pre-loaded, plug in your own credentials and exchange code, and send a live request without leaving the docs.
Launch the interactive playground with the Index List request ready to run.
Sample Responses
SUCCESS [200]
{
"status": true
"message": "Request successful.",
"data": {
"idxList": [
"Nifty 50", "Nifty Next 50", "Nifty 100", "Nifty 200", "Nifty 500"
"Nifty Midcap 50", "NIFTY MIDCAP 100", "NIFTY SMLCAP 100"
"Nifty Auto", "Nifty Bank", "Nifty IT", "Nifty Pharma", "Nifty FMCG"
]
}
}Error Responses
If the request fails validation, authentication, or exceeds the platform rate limits, the
API returns a non-200 status with the standard { "status": false "message": "..." } shape.
Inspect the HTTP status code and the message field to determine the cause.
400 — BAD REQUEST
{
"status": false
"message": "Invalid exchange code. Allowed values are NSE, BSE."
}401 — UNAUTHORIZED
{
"status": false
"message": "Invalid or expired token. Please re-authenticate."
}429 — TOO MANY REQUESTS
{
"status": false
"message": "Rate limit exceeded. Please retry after some time."
}| Status | Meaning | How to resolve |
|---|---|---|
| 400 | Bad Request — an unsupported or invalid exch value was supplied, or a mandatory field (source, clientCode, exch) is missing. | Send exch as one of the allowed values (NSE, BSE) and confirm all mandatory fields are present in the request body. |
| 401 | Unauthorized — the Bearer JWT token, x-api-key, or x-api-secret is invalid or the access token has expired. | Re-authenticate via POST {{baseUrl}}/auth/connect/login to obtain a fresh access token, and verify your App key/secret headers. |
| 429 | Too Many Requests — you exceeded the platform request limits (2,16,000 requests/day or 3,000 requests per 5 minutes per IP). | Throttle your request rate, add retry-with-backoff, and cache reference data such as the index list instead of re-fetching it repeatedly. |
Rate Limits & Compliance
| Limit | Value |
|---|---|
| API orders per day | 2,000 |
| Total API requests per day | 2,16,000 |
| Order:Trade Ratio (OTR) | 49:1 |
| Orders per second | 10 |
| Requests per 5 minutes per IP | 3,000 |
Understanding the Response
The response contains a list of indices available for the selected exchange. These index names can be used throughout trading and analytics applications for market monitoring, strategy selection, index tracking, reporting, and user interface components.
Glossary
Key terms used throughout the Index List reference and related trading APIs.
| Term | Definition |
|---|---|
| OPS | Order Placement Speed — the number of orders allowed to be submitted per second (capped at 10 orders/second). |
| Scrip | A tradable instrument or security, such as an equity share, derivative contract, or index. |
| Instrument mapping | Linking a scrip to its exchange-specific token or identifier so it can be referenced in order and reference-data APIs. |
| Lot size | The minimum tradable quantity for an instrument, primarily applicable to derivatives. |
| JWT | JSON Web Token — the bearer access token returned by login and passed in the Authorization header. |
| clientCode | The unique identifier for a client account, sent as a mandatory field in most requests. |
| Exchange code (exch) | The market venue code identifying where an instrument trades, e.g. NSE or BSE. |
Regulatory & SEBI Context
Reference-data endpoints like Index List are read-only and are commonly used within algo setups — for example, to resolve exchange-wise index universes before a strategy places orders. Using this endpoint does not, on its own, change how your algo is classified, but the surrounding trading logic determines your regulatory obligations.
Learn how Registered vs Non-Registered algos are classified and what onboarding each requires before you go live.
Next Steps
Continue exploring the Master & Reference Data endpoints, then move on to bulk master downloads. Recommended reading order:
| Step | Reference | What you'll learn |
|---|---|---|
| 1 | Order Validity Options | Retrieve the retention/validity types (DAY, IOC, etc.) accepted when placing orders. |
| 2 | Lots and Weights | Fetch lot sizes and index constituent weights for derivatives and index-based strategies. |
| 3 | Master Download | Download the full instrument master files for bulk lookups and local caching. |
Last updated: July 2026 · API v1
Order Validity Options
Overview
The Order Validity Options API returns the list of order retention types supported by a specified exchange.
Order validity determines how long an order remains active in the exchange trading system before it is executed, cancelled, or expired. The available retention types may vary depending on the exchange selected in the request.
This API helps applications fetch exchange-supported validity options dynamically and use them during order placement.
Common Use Cases
Use this API when you want to:
Request Parameters
| Field | Type | Description |
|---|---|---|
| source | String | Source of the request (e.g., CLIENT) |
| clientCode | String | Unique client identifier |
| exch | String | Exchange. Allowed values: NSE, BSE |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"exch": "BSE"
}Sample Responses
SUCCESS [200]
{
"status": true
"message": "Request successful.",
"data": {
"ret": [
"DAY"
"IOC"
"EOS"
]
},
"error": null
}Understanding the Response
The response contains the list of order validity types supported by the selected exchange. Common retention types include DAY (Order remains active for current trading day), IOC (Immediate or Cancel - executed immediately with unfilled quantity cancelled), and EOS (Exchange-specific order retention type).
Only the retention types returned by this API should be used during order placement. Using unsupported retention types may result in order validation failures.
Lots and Weights
Overview
The Lots and Weights API provides lot size and weight-related information for supported market segments.
This information is commonly used when calculating order quantities, validating lot-based trades, and configuring trading applications that operate across different exchanges and derivative segments.
By using this API, applications can ensure that quantity calculations align with exchange-defined lot and weight requirements before placing orders.
Common Use Cases
Use this API when you want to:
Request Parameters
| Field | Type | Description |
|---|---|---|
| source | String | Source of the request (e.g., CLIENT) |
| clientCode | String | Unique client identifier |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode" : "{{CLIENTCODE}}"
}Sample Responses
SUCCESS [200]
{
"status": true
"message": "Request successful.",
"data": {
"lotWt": {
"BFO": "Weights",
"NFO": "Weights"
}
},
"error": null
}Understanding the Response
The response contains lot and weight-related information for supported trading segments. This data can be used to validate trading quantities, calculate order sizes, determine segment-specific lot requirements, and configure quantity validation rules in trading applications.
Applications should use the returned values when calculating or validating order quantities. The information returned by this API helps ensure compliance with exchange-defined lot requirements.
Master Download
Access and download comprehensive instrument master data files for all supported exchanges. Master files are updated daily at 7:00 AM IST and include complete trading instrument catalogs with technical specifications, contract details, and trading parameters.
Master Download & Master APIs
S3 Dynamic Daily Masters Sync
All master files are automatically updated daily at 7:00 AM IST to ensure the latest exchange-published instrument and reference data is available for trading and validation.
Download Masters Archive (.zip)
NSE Equity Master
NSE Equity Instrument Master
Complete list of NSE Equity tradable instruments with exchange code, scrip codes, instrument type, expiry, strike price, lot size, and trading symbol. This master includes all stocks, indices, and equity segment instruments listed on NSE.
Retrieve NSE Equity master data in CSV format with complete instrument specifications.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
Example CSV Response
Exch,ScripCode,Name,Desc,TradingSymbol,TickSize,SERIES,MinimumLotQty,ISIN,UpperCkt,LowerCkt,PrevOpen,PrevHigh,PrevLow,PrevClose,YearlyHigh,YearlyLow,CALevel,SECTOR,HCALEVEL,FREEZEQTY,FINCODE,YEAR_LOW,YEAR_HIGH,DECIMAL_PRECISION,STATUSEXCH,PRICEQUOTEUNIT,PRICEQUOTEQUANTITY,LOTNUMERATOR,LOTDENOMINATOR,DELIVERYUNIT,MAXSINGLETRANQTY,MTF,LVG,surveillance,3YearHigh,3YearLow,5YearHigh,5YearLow,IsFuture,IsOption,1WEEK_RETURN_VALUE,1MONTH_RETURN_VALUE,3MONTH_RETURN_VALUE,6MONTH_RETURN_VALUE,1YEAR_RETURN_VALUE,3YEAR_RETURN_VALUE,5YEAR_RETURN_VALUE
N,2885,RELIANCE,RELIANCE INDUSTRIES LTD,RELIANCE-EQ,10.0,EQ,1,INE002A01018,1434.4,1173.6,1304.0,1325.6,1299.4,1321.3,1611.8,1253.2,0,Refineries,0,67662.0,100325,1253.2,1611.8,2,,,,,,,,Y,2.0,,1611.8,1114.85,1611.8,1008.125,1,1,1.5603,2.347,1.2801,-12.1593,-13.4879,0.1459,24.3694
N,11536,TCS,TATA CONSULTANCY SERV LT,TCS-EQ,10.0,EQ,1,INE467B01029,2302.8,1884.2,2090.0,2093.0,2050.6001,2057.6001,3426.1001,1976.8,0,IT - Software,0,47035.0,132540,1976.8,3426.1001,2,,,,,,,,Y,2.0,,4592.25,1976.8,4592.25,1976.8,1,1,-1.921,-6.4259,-18.9857,-37.5652,-39.8327,-38.0782,-36.9279
N,1594,INFY,INFOSYS LIMITED,INFY-EQ,10.0,EQ,1,INE009A01021,1151.9,942.5,1050.1,1053.0,1033.0,1042.2,1728.0,982.4,0,IT - Software,0,93316.0,100209,982.4,1728.0,2,,,,,,,,Y,2.0,,2006.45,982.4,2006.45,982.4,1,1,0.5305,-12.9687,-22.189,-36.4124,-36.4783,-22.4496,-33.2864NSE Derivatives Master
NSE Derivatives F&O Master
Complete list of NSE Derivatives tradable instruments including futures and options contracts. This master contains metadata for order placement, symbol mapping, contract specifications, and instrument identification across all F&O segments.
Retrieve NSE Derivatives master data including futures and options contracts with complete specifications.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
Example CSV Response
Exch,ScripCode,ScripCodeDaily,ScripCodeIntraday,Name,ULToken,OFISType,CPType,ExpiryDate,StrikePrice,CALevel,MinimumLotQuantity,Desc,TradingSymbol,PrevOI,SERIES,OPTION_TYPE,EXPIRY_DATE,OI_PREV,OI,FREEZEQTY,DECIMAL_PRECISION,LOTSIZE,STATUSEXCH,PRICEQUOTEUNIT,PRICEQUOTEQUANTITY,LOTNUMERATOR,LOTDENOMINATOR,DELIVERYUNIT,MAXSINGLETRANQTY,IsFuture,IsOption
N,58067,58067,58067,BANKNIFTY,26009,1,0,1472135400,-0.01,0,30,BANKNIFTY 25AUG26 FUT,BANKNIFTY26AUGFUT,210060,FUTIDX,XX,1472135400,210060,210060,601.0,0,30.0,,,,,,,,0,0
N,101267,101267,101267,ICICIBANK,4963,4,3,1469716200,1440.0,0,700,ICICIBANK 28JUL26 1440.0 CE,ICICIBANK26JUL1440CE,1396500,OPTSTK,CE,1469716200,1396500,1396500,21001.0,0,700.0,,,,,,,,0,0
N,101234,101234,101234,DMART,19913,4,3,1475159400,3800.0,0,150,DMART 29SEP26 3800.0 CE,DMART26SEP3800CE,0,OPTSTK,CE,1475159400,0,0,6001.0,0,150.0,,,,,,,,0,0NSE Currency Derivatives Master
NSE Currency Derivatives Master
Instrument master for NSE Currency Derivatives (CDS segment) containing USDINR, EURINR, GBPINR, and JPYINR futures and options contracts. This master includes trading identifiers, contract specifications, and technical parameters for currency derivative trading.
Retrieve NSE Currency Derivatives master data for USDINR, EURINR, GBPINR, JPYINR and other currency pairs.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
Example CSV Response
Exch,ScripCode,ScripCodeDaily,ScripCodeIntraday,Name,ULToken,OFISType,CPType,ExpiryDate,StrikePrice,CALevel,MinimumLotQuantity,Desc,TradingSymbol,SERIES,OPTION_TYPE,EXPIRY_DATE,PRICENUMERATOR,PRICEDENOMINATOR,FREEZEQTY,OI_PREV,OI,DECIMAL_PRECISION,LOTSIZE,STATUSEXCH
C,1038,1038,1038,USDINR,1,6,0,1469370600,0.0,0,1,USDINR 24JUL26 FUT,USDINR26724FUT,futcur,XX,2026-07-24 14:30:00,1,1,10001.0,0.0,0.0,4,1.0
C,1043,1043,1043,EURINR,25,6,0,1485527400,0.0,0,1,EURINR 27JAN27 FUT,EURINR27JANFUT,futcur,XX,2027-01-27 14:30:00,1,1,10001.0,0.0,0.0,4,1.0
C,10398,10398,10398,USDINR,1,7,3,1472394600,93.5,0,1,USDINR 28AUG26 93.5 CE,USDINR2682893.5CE,optcur,CE,2026-08-28 14:30:00,1,1,10001.0,0.0,0.0,4,1.0,BSE Equity Master
BSE Equity Instrument Master
Instrument master for BSE Equity segment with scrip code, trading symbol, tick size, series, lot size, circuit limits, and previous day market data. This master includes all equity instruments listed on the Bombay Stock Exchange.
Retrieve BSE Equity master data with trading symbols, ISIN, series type, and market-related parameters.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
Example CSV Response
Exch,ScripCode,Name,Desc,TradingSymbol,TickSize,SERIES,MinimumLotQty,ISIN,UpperCkt,LowerCkt,PrevOpen,PrevHigh,PrevLow,PrevClose,YearlyHigh,YearlyLow,CALevel,SECTOR,HCALEVEL,FREEZEQTY,FINCODE,YEAR_LOW,YEAR_HIGH,DECIMAL_PRECISION,STATUSEXCH,PRICEQUOTEUNIT,PRICEQUOTEQUANTITY,LOTNUMERATOR,LOTDENOMINATOR,DELIVERYUNIT,MAXSINGLETRANQTY,MTF,LVG,surveillance,3YearHigh,3YearLow,5YearHigh,5YearLow,IsFuture,IsOption,3YEAR_RETURN_VALUE,5YEAR_RETURN_VALUE,1WEEK_RETURN_VALUE,1MONTH_RETURN_VALUE,3MONTH_RETURN_VALUE,6MONTH_RETURN_VALUE,1YEAR_RETURN_VALUE
B,500325,RELIANCE,RELIANCE INDUSTRIES LTD.-500325,RELIANCE,5.0,A,1,INE002A01018,1434.65,1173.85,1304.55,1325.85,1299.35,1304.25,1611.2,1290.0,0,Refineries,0,,100325,1290.0,1611.2,2,,,,,,,,Y,2.0,,3217.9,1115.55,3217.9,1115.55,1,1,-45.7672,-32.696,0.0,0.3296,9.6731,-4.87,-6.3212
B,532540,TCS,TATA CONSULTANCY SERVICES LTD.-532540,TCS,5.0,A,1,INE467B01029,2302.0,1883.5,2096.8,2096.8,2050.6,2092.75,3426.3501,2346.3501,0,IT - Software,0,,132540,2346.3501,3426.3501,2,,,,,,,,Y,2.0,,4585.9,2346.35,4585.9,2346.35,1,1,-25.5609,-24.1804,0.0,0.0121,-2.6124,-24.9192,-27.6955
B,500209,INFY,INFOSYS LTD.-500209,INFY,5.0,A,1,INE009A01021,1151.7,942.3,1057.85,1057.85,1033.0,1047.0,1727.85,1149.8,0,IT - Software,0,,100209,1149.8,1727.85,2,,,,,,,,Y,2.0,,2006.8,1149.8,2006.8,1149.8,1,1,-12.0842,-24.384,0.0,1.1991,-11.8382,-27.909,-27.9661BSE Derivatives Master
BSE Derivatives F&O Master
Instrument master for BSE Derivatives segment containing index futures and options contracts including BANKEX and SENSEX derivatives. This master provides complete specifications for derivative trading on BSE.
Retrieve BSE Derivatives master data for BANKEX, SENSEX, and other derivative contracts.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
Example CSV Response
Exch,ScripCode,ScripCodeDaily,ScripCodeIntraday,Name,ULToken,OFISType,CPType,ExpiryDate,StrikePrice,CALevel,MinimumLotQuantity,Desc,TradingSymbol,PrevOI,SERIES,OPTION_TYPE,EXPIRY_DATE,OI_PREV,OI,FREEZEQTY,DECIMAL_PRECISION,LOTSIZE,STATUSEXCH,PRICEQUOTEUNIT,PRICEQUOTEQUANTITY,LOTNUMERATOR,LOTDENOMINATOR,DELIVERYUNIT,MAXSINGLETRANQTY,IsFuture,IsOption
B,1146288,1146288,1146288,BANKEX,12,1,0,1469836800,0.0,0,30,BANKEX 30JUL26 FUT,BANKEX26JULFUT,30,IF,XX,1469836800,30,30,,2,30.0,,,,,,,,0,0
B,1137799,1137799,1137799,SENSEX,1,2,3,1469836800,72100.0,0,20,SENSEX 30JUL26 72100.0 CE,SENSEX26JUL72100CE,0,IO,CE,1469836800,0,0,,2,20.0,,,,,,,,0,0
B,1136169,1136169,1136169,HAVELLS,517354,4,3,1469836800,1190.0,0,500,HAVELLS 30JUL26 1190.0 CE,HAVELLS26JUL1190CE,0,SO,CE,1469836800,0,0,,2,500.0,,,,,,,,0,0MCX Commodity Derivatives Master
MCX Commodity Derivatives Master
Instrument master for MCX Commodity Derivatives segment containing futures contracts for precious metals, crude oil, natural gas, and agricultural commodities. This master includes complete contract specifications, symbol mapping, and trading parameters.
Retrieve MCX Commodity Derivatives master data for gold, silver, crude oil, natural gas, and agricultural commodities.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
Supported Commodities
Gold (GOLD), Silver (SILVER), Crude Oil (CRUDEOIL), Natural Gas (NATURALGAS), Copper (COPPER), Zinc (ZINC)
Example CSV Response
Exch,ScripCode,ScripCodeDaily,ScripCodeIntraday,Name,ULToken,OFISType,CPType,ExpiryDate,StrikePrice,CALevel,MinimumLotQuantity,Desc,TradingSymbol,Units,Start,EndDate,DelStart,DelEnd,TenderStart,TenderEnd,MaxSingleValue,MaxSingleQty,Factor,T2TIndicator,BuyMargin,SellMargin,UnitNo,GroupID,Units1,Units2,McxTickSize,EXPIRY_DATE,OPTION_TYPE,STOCK_TYPE,SERIES,PRICENUMERATOR,PRICEDENOMINATOR,FREEZEQTY,OI_PREV,OI,DECIMAL_PRECISION,LOTSIZE,STATUSEXCH,PRICEQUOTEUNIT,PRICEQUOTEQUANTITY,LOTNUMERATOR,LOTDENOMINATOR,DELIVERYUNIT,MAXSINGLETRANQTY,IsFuture,IsOption
M,556298,556298,556298,GOLD,466583,10,3,1469750400,171000.0,0,1,GOLD 29JUL26 171000.0 CE,GOLD29JUL26171000CE,KGS,1783490409,1785369599.0,1785369599.0,1785369599.0,1785110400.0,1785369599.0,-1.0,100.0,10.0,1,0,0,10.0,2,GRMS,KGS,50.0,2026-07-29,CE,option,optfut,1,1,100.0,0,0,2,1.0,N,GRMS,10.0,1.0,1.0,KGS,100.0,0,0
M,538686,538686,538686,NATGASMINI,596,9,0,1469664000,0.0,0,250,NATGASMINI 28JUL26 FUT,NATGASMINI28JUL26FUT,mmBtu,1783490409,1785283199.0,1785283199.0,1785283199.0,1784678400.0,1785283199.0,-1.0,240.0,1.0,1,0,0,1.0,2,mmBtu,mmBtu,10.0,2026-07-28,XX,future,futcom,1,1,240.0,26621,28104,2,250.0,N,mmBtu,1.0,1.0,1.0,mmBtu,240.0,0,1
M,471725,471725,471725,SILVER,115,9,0,1472947200,0.0,0,30,SILVER 04SEP26 FUT,SILVER04SEP26FUT,KGS,1783490409,1788566399.0,1788566399.0,1788566399.0,1788307200.0,1788566399.0,-1.0,20.0,1.0,1,0,0,1.0,2,KGS,KGS,100.0,2026-09-04,XX,future,futcom,1,1,20.0,11715,11667,2,30.0,N,KGS,1.0,1.0,1.0,KGS,20.0,0,1
M,520702,520702,520702,CRUDEOIL,294,9,0,1468972800,0.0,0,100,CRUDEOIL 20JUL26 FUT,CRUDEOIL20JUL26FUT,BBL,1783490409,1784591999.0,1784591999.0,1784591999.0,1783987200.0,1784591999.0,-1.0,100.0,1.0,1,0,0,1.0,2,BBL,BBL,100.0,2026-07-20,XX,future,futcom,1,1,100.0,20032,20020,2,100.0,N,BBL,1.0,1.0,1.0,BBL,100.0,0,1Order Management
Order Management APIs are used to manage the complete order lifecycle on Bigul Connect, from order creation to modification and cancellation. These APIs allow clients and partner applications to place new orders, modify existing open orders, and cancel pending or unexecuted orders across supported exchanges, market segments, and product types.
Place Order
Place Order API
The Place Order API allows clients to place buy or sell orders on Bigul Connect through APIs. Clients can submit orders across supported exchanges and market segments by providing the required order details such as instrument, quantity, price, product type, transaction type, and order type.
Once the request passes all validations, including authentication, RMS checks, margin verification, and exchange validations, the order is routed to the exchange for execution.
Request Body Parameters
| Field | Type | Required | Description | Example |
|---|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) | {{SOURCE}} |
| clientCode | String | Yes | Client trading code | {{CLIENTCODE}} |
| es | String | Yes | Exchange segment (e.g. nse_cm – NSE Cash Market (Equity), bse_cm – BSE Cash Market (Equity), nse_fo – NSE Futures & Options, bse_fo – BSE Futures & Options) | nse_cm |
| pc | String | Yes | Product Code – Allowed values: (CNC: Delivery-based equity trades where shares are held in the demat account. MIS: Intraday trades with margin benefit, squared off the same trading day. NRML: Carry-forward positions, mainly for futures and options trading.) | CNC |
| pr | String | Yes | Order price in Rupees | 2329.90 |
| mp | String | Yes | Market protection value (0 = disabled) | 0 |
| pt | String | Yes | Order type (M / MKT: Execute immediately at market price, L: Execute at specified price, SL: Trigger → limit order, SL-M: Trigger → market order) | L |
| qt | String | Yes | Order quantity | 1 |
| rt | String | Yes | Order validity / retention (DAY: Valid for the trading day, IOC: Immediate or cancel, GTC: Valid until cancelled, GTD: Valid till a specified date) | DAY |
| tk | String | Yes | Instrument token | 25 |
| tp | String | Yes | Trigger price (must be 0 for Market/Limit orders) | 0 |
| ts | String | Yes | Trading symbol (e.g. ADANIENT-EQ) | ADANIENT-EQ |
| tt | String | Yes | Transaction type (B = Buy, S = Sell) | B |
| am | String | Yes | After Market Order flag (YES, NO) | NO |
| os | String | Optional | Order source (MOB, WEB, API) | WEB |
| bc | String | Optional | Broker-Client relationship (default 1) | 1 |
| cf | String | Yes | Customer firm indicator | C |
| pf | String | Yes | Position square-off flag (Y, N) | N |
| ur | String | Yes | User remarks | HT |
| ut | String | Optional | User tag / additional information | |
| dq | String | Yes | Disclosed quantity (≤ order quantity) | 0 |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"es": "nse_cm",
"pc": "CNC",
"pr": "2329.90",
"mp": "0",
"pt": "L",
"qt": "1",
"rt": "DAY",
"tk": "25",
"tp": "0",
"ts": "ADANIENT-EQ",
"tt": "B",
"am": "NO",
"os": "WEB",
"bc": "1",
"cf": "C",
"pf": "N",
"ur": "HT",
"ut": "",
"dq": "0"
}Success Response [200]
{
"status": true,
"message": "Request successful.",
"data": {
"nOrdNo": "1310111898"
},
"error": null
}Modify Order
Modify Order API
The Modify Order API allows clients to update an existing open order placed through Bigul Connect. You can modify order details such as price, quantity, validity, order type, trigger price, and other supported parameters while the order is still pending or open.
Once the modification request is submitted, the updated order details are validated again and sent to the exchange for processing.
Request Body Parameters
| Field | Type | Required | Description | Example |
|---|---|---|---|---|
| source | String | Yes | Source of the request (e.g. CLIENT, WEB) | {{SOURCE}} |
| clientCode | String | Yes | Unique client identifier | {{CLIENTCODE}} |
| no | String / Numeric | Yes | Nest order number to be modified | 1310111898 |
| vd | String | Yes | Order validity (DAY, IOC, GTC, GTD) | DAY |
| es | String | Yes | Exchange segment (nse_cm, bse_cm, nse_fo, bse_fo, cde_fo, bcs_fo) | nse_cm |
| pc | String | Yes | Product code – Allowed values: CNC, MIS, NRML | CNC |
| pr | Float | Yes | Modified order price (≥ 0) | 2329.90 |
| mp | Float | Yes | Market protection price (≥ 0) | 0 |
| pt | String | Yes | Order type (M, MKT, L, SL, SL-M) | L |
| qt | Integer | Yes | Modified order quantity (≥ 1) | 1 |
| rt | String | Yes | Order retention / duration (e.g. DAY) | DAY |
| tk | String / Numeric | Yes | Exchange token of the instrument | 25 |
| tp | Float | Yes | Trigger price (≥ 0) | 0 |
| ts | String | Yes | Trading symbol (e.g. ADANIENT-EQ) | ADANIENT-EQ |
| tt | String | Yes | Transaction type (B = Buy, S = Sell) | B |
| am | String | Optional | After Market Order flag (YES, NO) | NO |
| os | String | Optional | Order source (MOB, WEB, API) | |
| bc | String | Optional | Bracket count (1, 2, 3) | |
| cf | String | Optional | Confirmation flag (C, U) | |
| pf | String | Optional | Position flag (Y, N) | |
| ur | String | Optional | User remarks | |
| ut | String | Optional | User tag / custom reference | |
| dq | Integer | Yes | Disclosed quantity (≥ 0) | |
| sr | String | Yes | Scrip name | Adani Enterprises Limited |
| au | String | Yes | Order status / action indicator | PENDING |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"no": "1310111898",
"vd": "DAY",
"es": "nse_cm",
"pc": "CNC",
"pr": "2329.90",
"mp": "0",
"pt": "L",
"qt": "1",
"rt": "DAY",
"tk": "25",
"tp": "0",
"ts": "ADANIENT-EQ",
"tt": "B",
"am": "NO",
"sr": "Adani Enterprises Limited",
"au": "PENDING"
}Success Response [200]
{
"status": true,
"message": "Request successful.",
"data": {
"nOrdNo": "1310111898"
},
"error": null
}Cancel Order
Cancel Order API
The Cancel Order API allows clients to cancel an existing open order placed through Bigul Connect. When a cancellation request is submitted, it is forwarded to the exchange for processing.
If the order has not been fully executed, the remaining quantity is withdrawn from the market and becomes unavailable for further execution. This API can be used to cancel regular orders as well as eligible After Market Orders (AMO).
Request Body Parameters
| Field | Type | Required | Description | Example |
|---|---|---|---|---|
| source | String | Yes | Source of the request (e.g. CLIENT) | {{SOURCE}} |
| clientCode | String | Yes | Unique client identifier | {{CLIENTCODE}} |
| am | String | Optional | After Market Order (AMO) flag. Allowed values: YES, NO | YES |
| on | String / Numeric | Yes | Nest Order Number to be cancelled | 1310111902 |
| ts | String | Conditional | Trading symbol (e.g. TCS-EQ). Mandatory only when am = YES | ADANIENT-EQ |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"am": "YES",
"on": "1310111902",
"ts": "ADANIENT-EQ"
}Success Response [200]
{
"status": true,
"message": "Request successful.",
"data": {
"result": "1310111902"
},
"error": null
}Advanced Order APIs
Detailed technical reference, validation parameters, schemas and client code orchestrations.
GTT (Good Till Triggered) Orders
What is a GTT Order?
A GTT (Good Till Triggered) order is an advance order type that remains inactive until a predefined trigger condition is met. Once the specified trigger price condition is satisfied, the order is automatically sent to the exchange for execution.
GTT orders help traders automate order placement based on price movements without continuously monitoring the market. They are commonly used for planned entries, exits, target-based trading, and long-term trading strategies.
Key Characteristics
Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| type | String | Yes | Trigger type — GTT_SINGLE for single-leg, GTT_OCO for one-cancels-other (e.g. GTT_SINGLE) |
| expires_at | String | Yes | Trigger expiry timestamp in YYYY-MM-DD HH:mm:ss format (e.g. 2025-12-30 23:59:59) |
| trigger_id | String | Optional | Identifier of the trigger — used when editing (e.g. 582) |
| trigger | Object | Yes | Trigger details object — see trigger.* fields below |
| executions | Array of Objects | Yes | List of execution legs — see executions[].* fields below |
| trigger.exchange | String | Yes | Exchange segment (nse_cm – NSE Cash, bse_cm – BSE Cash, nse_fo – NSE F&O, bse_fo – BSE F&O) (e.g. nse_cm) |
| trigger.tradingsymbol | String | Yes | Trading symbol of the instrument (e.g. TCS-EQ) |
| trigger.usymbol | String | Optional | Underlying symbol (e.g. TCS) |
| trigger.scrip_tkn | String | Yes | Instrument token (e.g. 11536) |
| trigger.ltp | Number | Yes | Last traded price at creation (e.g. 3124.2) |
| executions[].id | Number | Optional | Execution leg identifier — used when editing (e.g. 636) |
| executions[].transaction_type | String | Yes | Transaction type (B buy, S sell) (e.g. S) |
| executions[].quantity | Number | Yes | Order quantity (e.g. 1) |
| executions[].price | Number | Yes | Order price in Rupees (e.g. 3280.5) |
| executions[].order_type | String | Yes | Order type (M/MKT market, L limit, SL, SL-M) (e.g. L) |
| executions[].product | String | Yes | Product code (CNC delivery, MIS intraday, NRML carry-forward) (e.g. CNC) |
| executions[].trigger_value | Number | Yes | Price at which the trigger fires (e.g. 3289) |
| executions[].trigger_value_type | String | Yes | Trigger reference (e.g. ltp) |
| executions[].trigger_condition | String | Yes | Comparison operator (gte / lte) (e.g. gte) |
| executions[].strategy_id | String | Optional | Strategy identifier |
| executions[].strategy_seq_no | Number | Optional | Strategy sequence number |
| executions[].strategy_category | String | Optional | Strategy category |
| executions[].order_source | String | Optional | Source of the order |
Create Advance Orders (GTT)
Creates a Good Till Triggered (GTT) order that remains inactive until the specified trigger condition is satisfied. When the trigger condition becomes true, the configured order is automatically submitted to the exchange for execution.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"expires_at": "2025-12-30 23:59:59",
"type": "GTT_SINGLE",
"trigger": {
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"usymbol": "TCS",
"scrip_tkn": "11536",
"ltp": 3124.2000000000003
},
"executions": [{
"transaction_type": "S",
"quantity": 1,
"price": 3280.5,
"order_type": "L",
"product": "CNC",
"trigger_value": 3289,
"trigger_value_type": "ltp",
"trigger_condition": "gte"
}]
}GTT Single Success [200]
{
"status": true,
"message": "Request successful.",
"data": {
"tid": 582,
"oids": [636]
},
"error": null
}tid — Unique Trigger ID. Store this for tracking, editing, or deleting
the GTT order later.
oids — Order execution IDs associated with the trigger.
Edit Advance Order (GTT)
Allows clients to modify an existing GTT order using the Trigger ID generated during creation. Clients can update trigger values, expiry dates, quantities, prices, and other supported parameters before the trigger is executed, expired, cancelled, or deleted.
Edit Validation Rules
• Only active or pending GTT orders can be
edited
• Executed, cancelled, expired, or deleted GTT orders cannot be modified
•
trigger_id identifies the GTT order being updated
• executions[].id
identifies the specific execution leg being modified
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"type": "GTT_SINGLE",
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"expires_at": "2026-12-30 23:24:45",
"trigger_id": "582",
"trigger": {
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"usymbol": "TCS",
"scrip_tkn": "11536",
"ltp": 3124.2000000000003
},
"executions": [{
"id": 636,
"transaction_type": "S",
"quantity": 1,
"price": 3280.5,
"order_type": "L",
"product": "CNC",
"trigger_value": 3289,
"trigger_value_type": "ltp",
"trigger_condition": "gte"
}]
}GTT Single Success [200]
{
"status": true,
"message": "Request successful.",
"data": {
"tid": "582"
},
"error": null
}View & Track Advance Orders
The View & Track Advance Orders APIs help clients monitor and manage the complete lifecycle of advance orders created through Bigul Connect. These APIs provide visibility into orders across different states, allowing clients to track active orders, review executed orders, access historical records, and manage existing advance orders.
All Advance Orders
Retrieves advance orders created by a client based on the selected trigger type and date range. Supports filtering across GTT_SINGLE, GTT_OCO, GTT, VTC, WDO, TSO, ALERT, and ICEBERG.
Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| trigger_type | String | Yes | Type of advance order trigger. Allowed values: GTT_SINGLE, GTT_OCO, GTT, VTC, WDO, TSO |
| startdate | String (YYYY-MM-DD) | Yes | Start date for fetching advance orders |
| enddate | String (YYYY-MM-DD) | Yes | End date for fetching advance orders |
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"trigger_type": "GTT_SINGLE",
"startdate": "2025-09-05",
"enddate": "2025-12-31"
}GTT_SINGLE Success [200]
{
"status": true,
"message": "Request successful.",
"data": [{
"tid": 54, "uid": "Y09043516", "typ": "GTT_SINGLE",
"stat": 5, "usymbol": "MAHABANK",
"cond": { "ex": "nse_cm", "sym": "MAHABANK-EQ", "tkn": "11377", "ltp": 56.52 },
"ord": [{ "oid": 5, "prod": "CNC", "otyp": "L", "ttyp": "B", "px": 53.69, "qty": 1, "tv": 53.69, "cnd": "lte" }]
}],
"error": null
}Active Advance Orders
Retrieves all currently active advance order triggers along with the current day's triggered records (both successfully executed and failed). Supports GTT, GTT_SINGLE, GTT_OCO, VTC, WDO, TSO.
Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| trigger_type | String | Yes | Type of advance order trigger. Allowed values: GTT, GTT_SINGLE, GTT_OCO, VTC, WDO, TSO |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"trigger_type": "GTT"
}GTT_SINGLE Success [200]
{
"status": true,
"message": "Request successful.",
"data": [{
"tid": 582, "uid": "Y09043516", "typ": "GTT_SINGLE",
"stat": 1, "usymbol": "TCS",
"cond": { "ex": "nse_cm", "sym": "TCS-EQ", "tkn": "11536", "ltp": 3124.2 },
"ord": [{ "oid": 636, "ttyp": "S", "px": 3280.5, "qty": 1, "tv": 3289, "cnd": "gte" }]
}],
"error": null
}Executed Advance Orders
Retrieves advance orders that have already been triggered and processed within a specified date range — including both successful and failed executions. By default returns GTT_SINGLE executed triggers.
Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| trigger_type | String | Yes | Type of advance order trigger. Allowed values: GTT_SINGLE, GTT, GTT_OCO, VTC, WDO, TSO |
| startdate | String (YYYY-MM-DD) | Yes | Start date for fetching advance orders |
| enddate | String (YYYY-MM-DD) | Yes | End date for fetching advance orders |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"trigger_type": "GTT_SINGLE",
"startdate": "2025-09-01",
"enddate": "2025-12-31"
}GTT Single Success [200]
{
"status": true,
"message": "Request successful.",
"data": [{
"tid": 582, "uid": "Y09043516", "typ": "GTT_SINGLE",
"stat": 1, "usymbol": "TCS",
"ord": [{ "oid": 636, "ttyp": "S", "px": 3280.5, "qty": 1, "tv": 3289, "cnd": "gte", "norderno": null }]
}],
"error": null
}Advance Order History
Retrieves the complete history and lifecycle events of a specific advance order trigger —
including creation, modification, execution, cancellation, expiration, and deletion. Use
history_type: "action" for state transitions, or "complete" for full lifecycle
with order details.
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"trigger_id": "584",
"history_type": "action"
}Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| trigger_id | String | Yes | Trigger ID whose history is being requested (e.g. 584) |
| history_type | String | Yes | History detail level — action for state transitions, complete for full lifecycle with order details (e.g. action) |
Success [200]
{
"status": true,
"message": "Request successful.",
"data": [
{
"id": 2642,
"tid": 584,
"state": "-1",
"state_time": "2025-12-29T13:17:14.129Z",
"state_data": "DELETED_TRIGGER",
"trigger_status": "Cancelled"
},
{
"id": 2569,
"tid": 584,
"state": "1",
"state_time": "2025-12-29T12:25:23.929Z",
"state_data": "ACTIVE_TRIGGER",
"trigger_status": "Created"
}
],
"error": null
}Delete Advance Order
Allows clients to delete one or more active advance order triggers. Multiple triggers can be deleted in a single request by providing their corresponding Trigger IDs. Once deleted, a trigger becomes inactive and will no longer monitor market conditions or initiate order execution.
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"trigger_ids": ["584"]
}Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| trigger_ids | Array of String | Yes | One or more Trigger IDs to delete in a single request (e.g. ["584"]) |
Success [200]
{
"status": true,
"message": "Request successful.",
"data": {
"deleted": [584],
"notdeleted": [],
"invalidIds": []
},
"error": null
}deleted — Successfully deleted trigger IDs. notdeleted — Trigger IDs that could not be deleted. invalidIds — Invalid or unrecognized trigger IDs.
VTC Orders (Valid Till Cancelled)
What is a VTC Order?
A VTC (Valid Till Cancelled) order is an advance order type that remains active until it is either executed or manually cancelled by the client. Unlike regular day orders, which automatically expire at the end of the trading session, VTC orders continue to remain active across multiple trading sessions.
VTC orders are commonly used by traders who want to place long-term buy or sell orders at specific price levels without having to re-enter the order every trading day.
Key Characteristics
Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| type | String | Yes | Trigger type; must be VTC for Valid Till Cancelled orders (e.g. VTC) |
| expires_at | String | Yes | Trigger expiry timestamp in YYYY-MM-DD HH:mm:ss format (e.g. 2025-12-30 23:59:59) |
| trigger.exchange | String | Yes | Exchange segment (nse_cm – NSE Cash, bse_cm – BSE Cash, nse_fo – NSE F&O, bse_fo – BSE F&O) (e.g. nse_cm) |
| trigger.tradingsymbol | String | Yes | Trading symbol of the instrument (e.g. TCS-EQ) |
| trigger.usymbol | String | Optional | Underlying symbol (e.g. TCS) |
| trigger.scrip_tkn | String | Yes | Instrument token (e.g. 11536) |
| trigger.ltp | Number | Yes | Last traded price at creation (e.g. 3124.2) |
| executions[].transaction_type | String | Yes | Transaction type (B buy, S sell) (e.g. B) |
| executions[].quantity | Number | Yes | Order quantity (e.g. 1) |
| executions[].price | Number | Yes | Order price in Rupees (e.g. 2947.1) |
| executions[].order_type | String | Yes | Order type; only Limit (L) orders are supported for VTC (e.g. L) |
| executions[].product | String | Yes | Product code (CNC delivery, MIS intraday, NRML carry-forward) (e.g. CNC) |
| executions[].strategy_id | String | Optional | Strategy identifier |
| executions[].strategy_seq_no | Number | Optional | Strategy sequence number |
| executions[].strategy_category | String | Optional | Strategy category |
| executions[].order_source | String | Optional | Source of the order |
VTC-specific rule: order_type must be L (Limit) —
other order types are not supported for VTC orders.
Create Advance Orders (VTC)
Creates a VTC order that remains active across trading sessions until executed or manually cancelled. Unlike GTT orders, VTC orders do not rely on trigger conditions — they behave as long-duration limit orders.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"expires_at": "2025-12-30 23:59:59",
"type": "VTC",
"trigger": {
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"usymbol": "TCS",
"scrip_tkn": "11536",
"ltp": 3124.2000000000003
},
"executions": [{
"transaction_type": "B",
"quantity": 1,
"price": 2947.1,
"order_type": "L",
"product": "CNC"
}]
}VTC Success [200]
{
"status": true,
"message": "Request successful.",
"data": {
"tid": 587,
"oids": [644],
"orderDetails": {
"oid": 644,
"nOrdNo": "1310059949"
}
},
"error": null
}OCO Orders (One-Cancels-Other)
What is an OCO Order?
An OCO (One Cancels the Other) order is an advanced order type where two linked orders are created simultaneously for the same instrument. When one of the orders is triggered and executed, the other order is automatically cancelled.
OCO orders are commonly used for risk management and profit protection, combining target and stop-loss conditions into a single automated trading strategy.
Key Characteristics
Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| type | String | Yes | Trigger type; must be GTT_OCO for one-cancels-other orders (e.g. GTT_OCO) |
| expires_at | String | Yes | Trigger expiry timestamp in YYYY-MM-DD HH:mm:ss format (e.g. 2025-12-30 23:59:59) |
| trigger_id | String | Optional | Identifier of the trigger — used when editing (e.g. 585) |
| trigger.exchange | String | Yes | Exchange segment (nse_cm – NSE Cash, bse_cm – BSE Cash, nse_fo – NSE F&O, bse_fo – BSE F&O) (e.g. nse_cm) |
| trigger.tradingsymbol | String | Yes | Trading symbol of the instrument (e.g. TCS-EQ) |
| trigger.usymbol | String | Optional | Underlying symbol (e.g. TCS) |
| trigger.scrip_tkn | String | Yes | Instrument token (e.g. 11536) |
| trigger.ltp | Number | Yes | Last traded price at creation (e.g. 3124.2) |
| executions[].id | Number | Optional | Execution leg identifier — used when editing (e.g. 641) |
| executions[].transaction_type | String | Yes | Transaction type (B buy, S sell) (e.g. B) |
| executions[].quantity | Number | Yes | Order quantity; both legs use the same quantity (e.g. 2) |
| executions[].price | Number | Yes | Order price in Rupees (e.g. 2964.0) |
| executions[].order_type | String | Yes | Order type (M/MKT market, L limit, SL, SL-M) (e.g. L) |
| executions[].product | String | Yes | Product code (CNC delivery, MIS intraday, NRML carry-forward) (e.g. CNC) |
| executions[].trigger_value | Number | Yes | Price at which the trigger fires for each leg (e.g. 2964.0) |
| executions[].trigger_value_type | String | Yes | Trigger reference (e.g. ltp) |
| executions[].trigger_condition | String | Yes | Comparison operator (gte / lte), one per leg (e.g. lte) |
| executions[].strategy_id | String | Optional | Strategy identifier |
| executions[].strategy_seq_no | Number | Optional | Strategy sequence number |
| executions[].strategy_category | String | Optional | Strategy category |
| executions[].order_source | String | Optional | Source of the order |
OCO rules: exactly two execution legs are mandatory per OCO order; both
legs must reference the same instrument and quantity; the two legs must have compatible/opposite trigger
conditions (one gte, one lte).
Create Advance Orders (OCO)
Creates a GTT_OCO order with two linked execution legs. When one trigger is satisfied and executed, the second leg is automatically cancelled.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"expires_at": "2025-12-30 23:59:59",
"type": "GTT_OCO",
"trigger": {
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"usymbol": "TCS",
"scrip_tkn": "11536",
"ltp": 3124.2000000000003
},
"executions": [
{
"transaction_type": "B",
"quantity": 2,
"price": 2964.0,
"order_type": "L",
"product": "CNC",
"trigger_value": 2964.0,
"trigger_value_type": "ltp",
"trigger_condition": "lte"
},
{
"transaction_type": "B",
"quantity": 2,
"price": 3276.0,
"order_type": "L",
"product": "CNC",
"trigger_value": 3276.0,
"trigger_value_type": "ltp",
"trigger_condition": "gte"
}
]
}GTT_OCO Success [200]
{
"status": true,
"message": "Request successful.",
"data": {
"tid": 585,
"oids": [641, 642]
},
"error": null
}Edit Advance Order (OCO)
Request Body
{
"type": "GTT_OCO",
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"expires_at": "2026-12-30 23:24:45",
"trigger_id": "585",
"trigger": {
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"usymbol": "TCS",
"scrip_tkn": "11536",
"ltp": 3124.2000000000003
},
"executions": [
{
"id": 641,
"transaction_type": "B",
"quantity": 2,
"price": 2964.0,
"order_type": "L",
"product": "CNC",
"trigger_value": 2964.0,
"trigger_value_type": "ltp",
"trigger_condition": "lte"
},
{
"id": 642,
"transaction_type": "B",
"quantity": 2,
"price": 3276.0,
"order_type": "L",
"product": "CNC",
"trigger_value": 3276.0,
"trigger_value_type": "ltp",
"trigger_condition": "gte"
}
]
}GTT_OCO Success [200]
{
"status": true,
"message": "Request successful.",
"data": { "tid": "585" },
"error": null
}TSO Orders (Trailing Stop Order)
What is a TSO Order?
A Trailing Stop Order (TSO) is an advanced order type that automatically adjusts its trigger price in the direction of favorable market movement. TSO helps traders protect profits while limiting downside risk without continuously monitoring the market.
As the market moves in the trader's favor, the trigger price automatically trails the market based on a predefined trailing value (fixed amount or percentage). If the market reverses by the specified trailing value, the order is triggered and submitted to the exchange for execution.
Key Characteristics
Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| type | String | Yes | Trigger type; must be TSO for Trailing Stop Orders (e.g. TSO) |
| expires_at | String | Yes | Trigger expiry timestamp in YYYY-MM-DD HH:mm:ss format (e.g. 2025-12-30 23:59:59) |
| trigger_id | String | Optional | Identifier of the trigger — used when modifying (e.g. 591) |
| trigger.exchange | String | Yes | Exchange segment (nse_cm – NSE Cash, bse_cm – BSE Cash, nse_fo – NSE F&O, bse_fo – BSE F&O) (e.g. nse_cm) |
| trigger.tradingsymbol | String | Yes | Trading symbol of the instrument (e.g. TCS-EQ) |
| trigger.usymbol | String | Optional | Underlying symbol (e.g. TCS) |
| trigger.scrip_tkn | String | Yes | Instrument token (e.g. 11536) |
| trigger.ltp | Number | Yes | Last traded price at creation (e.g. 3120.2) |
| executions[].id | Number | Optional | Execution leg identifier — used when modifying (e.g. 653) |
| executions[].transaction_type | String | Yes | Transaction type (B buy, S sell) (e.g. B) |
| executions[].quantity | Number | Yes | Order quantity (e.g. 1) |
| executions[].price | Number | Yes | Order price in Rupees (e.g. 3120.0) |
| executions[].order_type | String | Yes | Order type (M/MKT market, L limit, SL, SL-M) (e.g. L) |
| executions[].product | String | Yes | Product code (CNC delivery, MIS intraday, NRML carry-forward) (e.g. CNC) |
| executions[].trigger_value | Number | Yes | Price at which the trigger fires (e.g. 2964.0) |
| executions[].trigger_value_type | String | Yes | Trigger reference (e.g. ltp) |
| executions[].trigger_condition | String | Yes | Comparison operator (gte / lte) (e.g. lte) |
| executions[].trail_value | Number | Yes | Trailing value by which the trigger price adjusts, per trail_type (e.g. 1.0) |
| executions[].execution_type | String | Yes | Execution leg role — trail for the trailing leg, stop for the stop leg (e.g. trail) |
| executions[].trail_type | String | Yes | Trailing configuration — fixed amount or percentage-based (e.g. Fixed) |
| executions[].strategy_id | String | Optional | Strategy identifier |
| executions[].strategy_seq_no | Number | Optional | Strategy sequence number |
| executions[].strategy_category | String | Optional | Strategy category |
| executions[].order_source | String | Optional | Source of the order |
Enum reference: trail_type — fixed, percentage ·
execution_type — stop, trail.
Create Advance Orders (TSO)
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"expires_at": "2025-12-30 23:59:59",
"type": "TSO",
"trigger": {
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"usymbol": "TCS",
"scrip_tkn": "11536",
"ltp": 3120.2
},
"executions": [
{
"transaction_type": "B",
"quantity": 1,
"price": 3120.0,
"order_type": "L",
"product": "CNC",
"trigger_value": 2964.0,
"trigger_value_type": "ltp",
"trigger_condition": "lte",
"trail_value": 1.0,
"execution_type": "trail",
"trail_type": "Fixed"
},
{
"transaction_type": "B",
"quantity": 1,
"price": 3120.0,
"order_type": "L",
"product": "CNC",
"trigger_value": 3276.0,
"trigger_value_type": "ltp",
"trigger_condition": "gte",
"trail_value": 1.0,
"execution_type": "stop",
"trail_type": "Fixed"
}
]
}TSO Success [200]
{
"status": true,
"message": "Request successful.",
"data": {
"tid": 591,
"oids": [653, 654]
},
"error": null
}Modify Advance Order (TSO)
Request Body
{
"type": "TSO",
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"expires_at": "2026-12-30 23:24:45",
"trigger_id": "591",
"trigger": {
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"usymbol": "TCS",
"scrip_tkn": "11536",
"ltp": 3120.2
},
"executions": [
{
"id": 653,
"transaction_type": "B",
"quantity": 1,
"price": 3120.0,
"order_type": "L",
"product": "CNC",
"trigger_value": 2964.0,
"trigger_value_type": "ltp",
"trigger_condition": "lte",
"trail_value": 1.0,
"execution_type": "trail",
"trail_type": "Fixed"
},
{
"id": 654,
"transaction_type": "B",
"quantity": 1,
"price": 3120.0,
"order_type": "L",
"product": "CNC",
"trigger_value": 3276.0,
"trigger_value_type": "ltp",
"trigger_condition": "gte",
"trail_value": 1.0,
"execution_type": "stop",
"trail_type": "Fixed"
}
]
}TSO Success [200]
{
"status": true,
"message": "Request successful.",
"data": { "tid": "591" },
"error": null
}WDO Orders (When Done Order)
What is a WDO Order?
A WDO (When Done Order) is an advanced order type that allows multiple orders to be executed sequentially based on the status of the previous order. Each order in the sequence is triggered only after the preceding order reaches a specified status.
WDO orders are particularly useful when the execution of one order depends on the successful completion or status of another order, enabling multi-step trading workflows and automated execution chains.
Key Characteristics
Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | Yes | Source of request (e.g. WEB, API) |
| clientCode | String | Yes | Client trading code |
| type | String | Yes | Trigger type; must be WDO for When Done orders (e.g. WDO) |
| expires_at | String | Yes | Trigger expiry timestamp in YYYY-MM-DD HH:mm:ss format (e.g. 2025-12-30 23:59:59) |
| trigger_id | String | Optional | Identifier of the trigger — used when editing (e.g. 589) |
| trigger.exchange | String | Yes | Exchange segment (nse_cm – NSE Cash, bse_cm – BSE Cash, nse_fo – NSE F&O, bse_fo – BSE F&O) (e.g. nse_cm) |
| trigger.tradingsymbol | String | Yes | Trading symbol of the instrument (e.g. TCS-EQ) |
| trigger.usymbol | String | Optional | Underlying symbol (e.g. TCS) |
| trigger.scrip_tkn | String | Yes | Instrument token (e.g. 11536) |
| trigger.ltp | Number | Yes | Last traded price at creation (e.g. 3120.2) |
| executions[].id | Number | Optional | Execution leg identifier — used when editing (e.g. 645) |
| executions[].transaction_type | String | Yes | Transaction type (B buy, S sell) (e.g. B) |
| executions[].quantity | Number | Yes | Order quantity (e.g. 1) |
| executions[].price | Number | Yes | Order price in Rupees (e.g. 3120.2) |
| executions[].order_type | String | Yes | Order type (M/MKT market, L limit, SL, SL-M) (e.g. L) |
| executions[].product | String | Yes | Product code (CNC delivery, MIS intraday, NRML carry-forward) (e.g. CNC) |
| executions[].exchange | String | Yes | Exchange segment for the execution leg (nse_cm – NSE Cash, bse_cm – BSE Cash, nse_fo – NSE F&O, bse_fo – BSE F&O) (e.g. nse_cm) |
| executions[].tradingsymbol | String | Yes | Trading symbol for the execution leg (e.g. INFY-EQ) |
| executions[].scrip_tkn | String | Yes | Instrument token for the execution leg (e.g. 1594) |
| executions[].usymbol | String | Optional | Underlying symbol for the execution leg; omitted on the first leg in the sample (e.g. INFY) |
| executions[].forward_status | Array of String | Yes | Parent order status(es) that trigger this leg — see allowed values below (e.g. ["complete"]) |
| executions[].strategy_id | String | Optional | Strategy identifier |
| executions[].strategy_seq_no | Number | Optional | Strategy sequence number |
| executions[].strategy_category | String | Optional | Strategy category |
| executions[].order_source | String | Optional | Source of the order |
Allowed forward_status values: rejected, open, open pending, complete, validation pending, put order req received, cancelled.
Create Advance Orders (WDO)
Creates a WDO order linking multiple orders in a sequential execution chain. The first
order is submitted immediately; subsequent orders are triggered only when the previous order reaches a
specified forward_status.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"expires_at": "2025-12-30 23:59:59",
"type": "WDO",
"trigger": {
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"usymbol": "TCS",
"scrip_tkn": "11536",
"ltp": 3120.2
},
"executions": [
{
"transaction_type": "B",
"quantity": 1,
"price": 3120.2,
"order_type": "L",
"product": "CNC",
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"scrip_tkn": "11536"
},
{
"tradingsymbol": "INFY-EQ",
"exchange": "nse_cm",
"scrip_tkn": "1594",
"usymbol": "INFY",
"quantity": 1,
"price": 1362.6,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
},
{
"tradingsymbol": "MGL-EQ",
"exchange": "nse_cm",
"scrip_tkn": "17534",
"usymbol": "MGL",
"quantity": 1,
"price": 1273.8,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
},
{
"tradingsymbol": "M&M-EQ",
"exchange": "nse_cm",
"scrip_tkn": "2031",
"usymbol": "M&M",
"quantity": 1,
"price": 3707.9,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
},
{
"tradingsymbol": "IOC-EQ",
"exchange": "nse_cm",
"scrip_tkn": "1624",
"usymbol": "IOC",
"quantity": 1,
"price": 166.6,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
},
{
"tradingsymbol": "FACT-EQ",
"exchange": "nse_cm",
"scrip_tkn": "1008",
"usymbol": "FACT",
"quantity": 1,
"price": 932.8,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
}
]
}WDO Success [200]
{
"status": true,
"message": "Request successful.",
"data": {
"tid": 589,
"oids": [645, 646, 647, 648, 649, 650],
"orderDetails": {
"oid": 645,
"nOrdNo": "1310059953"
}
},
"error": null
}Edit Advance Order (WDO)
Request Body
{
"type": "WDO",
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"expires_at": "2026-12-30 23:24:45",
"trigger_id": "589",
"trigger": {
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"usymbol": "TCS",
"scrip_tkn": "11536",
"ltp": 3120.2
},
"executions": [
{
"id": 645,
"transaction_type": "B",
"quantity": 1,
"price": 3120.2,
"order_type": "L",
"product": "CNC",
"exchange": "nse_cm",
"tradingsymbol": "TCS-EQ",
"scrip_tkn": "11536"
},
{
"id": 646,
"tradingsymbol": "INFY-EQ",
"exchange": "nse_cm",
"scrip_tkn": "1594",
"usymbol": "INFY",
"quantity": 1,
"price": 1362.6,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
},
{
"id": 647,
"tradingsymbol": "MGL-EQ",
"exchange": "nse_cm",
"scrip_tkn": "17534",
"usymbol": "MGL",
"quantity": 1,
"price": 1273.8,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
},
{
"id": 648,
"tradingsymbol": "M&M-EQ",
"exchange": "nse_cm",
"scrip_tkn": "2031",
"usymbol": "M&M",
"quantity": 1,
"price": 3707.9,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
},
{
"id": 649,
"tradingsymbol": "IOC-EQ",
"exchange": "nse_cm",
"scrip_tkn": "1624",
"usymbol": "IOC",
"quantity": 1,
"price": 166.6,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
},
{
"id": 650,
"tradingsymbol": "FACT-EQ",
"exchange": "nse_cm",
"scrip_tkn": "1008",
"usymbol": "FACT",
"quantity": 1,
"price": 932.8,
"transaction_type": "B",
"order_type": "L",
"product": "CNC"
}
]
}WDO Success [200]
{
"status": true,
"message": "Request successful.",
"data": {
"tid": [589],
"modified": [645, 646, 647, 648, 649, 650],
"notmodified": []
},
"error": null
}Reporting & Portfolio APIs
Detailed technical reference, validation parameters, schemas and client code orchestrations.
Client Profile, Order Book & History
Client Profile
Retrieves account and profile information for a Bigul client — including client code, name, DP information, enabled trading segments, available product types, and account permissions. Use after successful authentication to personalize dashboards and validate trading access.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | {{JWT_TOKEN}} |
Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| clientCode | String (query) | YES | Client trading code, passed as a URL query parameter |
| source | String (query) | YES | Source of request, passed as a URL query parameter (e.g. WEB, API) |
Error Response [403]
{
"status": false,
"message": "Access denied: API key/secret invalid, or the requesting IP address is not authorized.",
"data": null,
"error": ""
}Success Response [200]
{
"status": true,
"message": "Profile info fetched successfully.",
"data": [{
"image": "",
"clientcode": "Y09042341",
"poa": "true",
"name": "YOGESH BALKRUSHNA SALVI",
"dpid": "1203350003540038",
"dpName": "YOGESH BALKRUSHNA SALVI",
"activesegments": "NSE|BSE|NFO|BFO|CDS|NCDEX|MCX|",
"brokerid": "BIGUL",
"products": "INTRADAY,DELIVERY,COVER,BRACKET,BO,CO,MIS,CNC"
}],
"error": null
}activesegments — Trading segments enabled: NSE, BSE, NFO, BFO, CDS, MCX, NCDEX
products — Product types available: CNC, MIS, NRML, BO, CO, INTRADAY, DELIVERY
poa — Power of Attorney status for the account
Get Order Book
Provides a complete view of all orders placed by the client across supported exchanges. Returns detailed information including order status, price, quantity, execution details, timestamps, and algo metadata. Tracks the complete order lifecycle from placement to execution, modification, cancellation, or rejection.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}"
}Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | YES | Source of request (e.g. WEB, API) |
| clientCode | String | YES | Client trading code |
Success [200]
{
"status": true,
"message": "Request successful.",
"data": [{
"brkClnt": "--", "ordValDt": "NA", "exUsrInfo": "NA", "mfdBy": "NA",
"rmk": "HT", "ordSrc": "EnterpriseWeb", "prc": "1564.90", "prcTp": "L",
"cnlQty": 0, "qty": 100, "unFldSz": 100, "exOrdId": "1300000000011514",
"actId": "Y090R578", "trgPrc": "0.00", "tok": "2885", "fldQty": 0,
"ordDtTm": "24-Dec-2025 11:49:18", "avgPrc": "0.00", "stat": "Ok",
"prod": "CNC", "exSeg": "nse_cm", "ordSt": "open pending",
"trnsTp": "B", "nOrdNo": "1300000000011514", "trdSym": "RELIANCE-EQ"
}],
"error": null
}nOrdNo — Unique Nest Order Number. Use for order history, modify, cancel operations.
ordSt — Current order status: OPEN, COMPLETE, CANCELLED, REJECTED, TRIGGER PENDING, OPEN PENDING.
fldQty / unFldSz — Filled and remaining unfilled quantity. rejRsn — Rejection reason if applicable.
Get Order History
Provides the detailed lifecycle history of a specific order — including status changes,
price, quantity, exchange submission, modification, execution, rejection, and cancellation events.
Requires the Nest Order Number (nOrdNo) from the Order Book.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"nOrdNo": "1110050961"
}Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | YES | Source of request (e.g. WEB, API) |
| clientCode | String | YES | Client trading code |
| nOrdNo | String | YES | Nest Order Number of the order whose lifecycle history is requested — obtained from the Order Book response (e.g. 1110050961) |
Success [200]
{
"status": true,
"message": "Request successful.",
"data": [{
"cstFrm": "C", "mfdBy": "XX", "trgPrc": "3165.50",
"fldQty": 0, "avgPrc": "0.00", "prc": "0.00", "prcTp": "SL-M",
"prod": "MIS", "trdSym": "TCS-EQ", "updRecvTm": 1766496740617,
"ordSt": "open pending", "trnsTp": "B", "qty": 3, "exch": "NSE",
"nOrdNo": "1110050961", "unFldSz": 3, "exchOrdId": "NA"
}],
"error": null
}Trade Book, Positions & Holdings
Get Trade Book
Provides detailed information about all executed trades. Unlike Order Book (which shows all orders), Trade Book focuses only on executed fills — including fill details, execution prices, quantities, exchange timestamps, and algo metadata. Used for trade reporting, P&L calculation, reconciliation, and post-trade analytics.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}"
}Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | YES | Source of request (e.g. WEB, API) |
| clientCode | String | YES | Client trading code |
Success [200]
{
"status": true,
"message": "Request successful.",
"data": [{
"exOrdId": "1300000000018810",
"actId": "Y09043516",
"fldQty": 3,
"flDt": "23-Dec-2025",
"avgPrc": "3465.00",
"prcTp": "L",
"prod": "MIS",
"exTm": "23-Dec-2025 12:25:41",
"exSeg": "nse_cm",
"trdSym": "TCS-EQ",
"flId": "600001954",
"flTm": "23-12-2025 12:25:41",
"trnsTp": "B",
"nOrdNo": "1110050961",
"ordDur": "DAY",
"stkPrc": "0.00",
"sym": "TCS"
}],
"error": null
}nOrdNo — Maps trades back to their original order. flId — Identifies individual fills for partial executions.
avgPrc — Average execution price. fldQty — Filled quantity for this trade record.
Get Position
Provides day-wise and net-wise position details including buy/sell quantities, amounts, product type, exchange segment, and derivative contract information. Used to monitor intraday and carry-forward positions, calculate exposure, and support portfolio P&L calculations.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}"
}Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | YES | Source of request (e.g. WEB, API) |
| clientCode | String | YES | Client trading code |
Success [200]
{
"status": true,
"message": "Request successful.",
"data": [{
"buyAmt": "1944054.00",
"cfSellAmt": "0.00",
"prod": "NRML",
"exSeg": "nse_fo",
"sqrFlg": "Y",
"actId": "Y09043516",
"flBuyQty": "35",
"flSellQty": "0",
"sellAmt": "0.00",
"posFlg": "true",
"trdSym": "BANKNIFTY25DECFUT",
"sym": "BANKNIFTY",
"expDt": "30 Dec, 2025",
"brdLtQty": 35,
"exp": "31-DEC-2025",
"lotSz": "35",
"optTp": "XX",
"stkPrc": "0.00"
}],
"error": null
}posFlg — true = open position. sqrFlg — Y = eligible for square-off.
flBuyQty / flSellQty — Filled buy and sell quantities for the position.
Get Holdings
Returns current holdings in the client's demat account for the specified product type. Includes quantity, collateral status, exchange mappings, instrument identifiers, and valuation information. Used for portfolio display, pledged securities monitoring, and long-term investment tracking.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Authorization | Bearer {{JWT_TOKEN}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{CLIENTCODE}}",
"prod": "CNC"
}Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | YES | Source of request (e.g. WEB, API) |
| clientCode | String | YES | Client trading code |
| prod | String | YES | Product type filter for holdings (CNC delivery, MIS intraday, NRML carry-forward) (e.g. CNC) |
Success [200]
{
"status": true,
"message": "Request successful.",
"data": {
"hldVal": [{
"clprc": "0.00",
"bseTrdSym": "RELIANCE",
"nseTrdSym": "RELIANCE-EQ",
"ex1": "nse_cm",
"ex2": "bse_cm",
"usdQty": "0",
"hldQty": "1000",
"scripCode": "500325",
"series": "EQ",
"prod": "CNC",
"colTp": "1",
"prc": "1300.00",
"hrCutPrc": "330000.00",
"tok1": "2885",
"tok2": "500325",
"slbQty": "1000"
}]
},
"error": null
}hldQty — Total demat holding quantity. usdQty — Currently blocked/utilized quantity.
colQty — Pledged as collateral. hrCutPrc — Haircut-adjusted collateral value.
Invest Transactions
Retrieves investment transaction details for a specific client within a date range — including purchases, redemptions, SIP transactions, and other investment activity. Used by partner platforms, reporting systems, and portfolio management solutions for reconciliation and analytics.
Request Headers
| Key | Value |
|---|---|
| x-api-key | {{x-api-key}} |
| x-api-secret | {{x-api-secret}} |
| Content-Type | application/json |
| Authorization | Bearer {{CLIENT TOKEN}} |
| x-vendor-auth | {{partner session id}} |
Request Body
{
"source": "{{SOURCE}}",
"clientCode": "{{ClientCode}}",
"from_date": "2026-01-01",
"to_date": "2026-03-31"
}Expected Request Parameters
| Field | Type | Required | Description / Notes |
|---|---|---|---|
| source | String | YES | Source of request (e.g. WEB, API) |
| clientCode | String | YES | Client trading code |
| from_date | String (YYYY-MM-DD) | YES | Start date of the transaction range; must be ≤ to_date (e.g. 2026-01-01) |
| to_date | String (YYYY-MM-DD) | YES | End date of the transaction range (e.g. 2026-03-31) |
from_date / to_date — Must be in YYYY-MM-DD format. from_date must be ≤ to_date.
Response may include transaction date, type, scheme details, investment amount, units, NAV values, and transaction reference numbers.
Market Data Streaming
Detailed technical reference, validation parameters, schemas and client code orchestrations.
Introduction
Market Data WebSocket — Introduction
The Bigul Connect Market Data WebSocket enables real-time streaming of market data across multiple asset classes, including equities, indices, derivatives, and option chains. It provides a persistent, low-latency data feed that allows client applications to receive continuous market updates without repeatedly polling REST APIs. Once connected and subscribed, data is delivered automatically by the server as market events occur.
Key Capabilities
Intended Use Cases
SDK Information
SDK Name: Market Data WebSocket SDK (JavaScript & Python)
This SDK is required for browser-based WebSocket usage. Server-side integrations may use native WebSocket implementations, subject to platform compatibility.
JavaScript WebSocket SDK
Python SDKWebSocket Lifecycle
WebSocket Lifecycle
The recommended connection lifecycle:
Create a WebSocket instance
Register required event callbacks
Connect to the WebSocket server
Authenticate using a valid access token
Subscribe to required market data channels
Receive real-time market updates
Pause or resume subscriptions (optional)
Close the WebSocket connection when no longer required
WebSocket Class — HSWebSocket is a singleton. Only one instance per
application.
var hsSocket = HSLib.HSWebSocket.getInstance();Events / Callbacks
Must be registered before connecting:
| Callback | Description |
|---|---|
| onOpen | Triggered when WebSocket connection is successfully established |
| onMessage | Triggered when market data or server response is received |
| onError | Triggered when a communication or processing error occurs |
| onClose | Triggered when WebSocket connection is closed |
onOpen
var hsSocket = HSLib.HSWebSocket.getInstance();
hsSocket.onOpen = function () {
// Connection established — authenticate here
};
hsSocket.connect("wss://localhost:9230");onMessage
hsSocket.onMessage = function (message) {
// JSON response: auth / market / depth / index updates
};onError
hsSocket.onError = function () {
// Handle error — implement reconnection logic
};onClose
hsSocket.onClose = function () {
// Handle connection close
};
hsSocket.close();Connecting to WebSocket
connect(url: string, heartBeatInterval?: number): void| Parameter | Type | Description |
|---|---|---|
| url | string | WebSocket server endpoint |
| heartBeatInterval | number | Heartbeat interval in seconds (default: 30) |
hsSocket.connect("wss://localhost:1523"); // Default heartbeat = 30 sec
hsSocket.connect("wss://localhost:1523", 35); // Custom heartbeatSending Requests
let authReq = { type: "cn", sessionid: "token1", mode: "N" };
hsSocket.send(JSON.stringify(authReq));Connection Status & Close
if (hsSocket.isConnected()) { hsSocket.send(/* request */); }
hsSocket.close(); // unsubscribes all active channelsBest Practices
Authentication
WebSocket Authentication
Once connected, authenticate using a valid x-access-token. Authentication is
mandatory before subscribing to any channel.
| Field | Type | Description |
|---|---|---|
| type | string | Must be "cn" |
| sessionid | string | Valid x-access-token from Bigul Connect login APIs |
| mode | string | N = Normal, M = Market Watch, H = High Frequency, P = Professional |
Authentication Request
{"type": "cn", "sessionid": "token1", "mode": "N"}Success Response
{"stat": "Ok", "type": "cn", "msg": "successful", "stCode": 200}Important Notes
Subscribing to Market Data
Market Data Subscription
Subscribe Request
{"type": "mws", "scrips": "nse_cm|11536", "channelnum": 1}Unsubscribe Request
{"type": "mwu", "scrips": "nse_cm|11536", "channelnum": 1}| Field | Description |
|---|---|
| type | mws = Subscribe / mwu = Unsubscribe |
| scrips | exchange identifier + instrument token |
| channelnum | Logical channel number |
Streaming Update Response
{"tk": "11536", "e": "nse_cm", "name": "sf", "ltp": "1905.65", "v": "4241579", "ts": "TCS-EQ"}| Field | Meaning |
|---|---|
| tk | Instrument token |
| e | Exchange segment |
| name | Short symbol name |
| ltp | Last Traded Price |
| v | Traded volume |
| ts | Trading symbol |
Indices Stream
Index Data Streaming
The Indices Stream feature allows clients to subscribe to real-time index-level market data such as NIFTY, BANK NIFTY, and other supported indices. Once subscribed, live index values and net change data are pushed automatically.
Subscribe Request
{"type": "ifs", "scrips": "nse_cm|Nifty 50", "channelnum": 1}Index Update Response
{"tk": "Nifty 50", "e": "nse_cm", "iv": "9553.35", "nc": "1.84", "ts": "Nifty 50"}| Field | Description |
|---|---|
| tk | Index token / name |
| e | Exchange segment |
| iv | Current index value |
| nc | Net change from previous close |
| ts | Trading symbol |
Market Depth Stream
Market Depth (Bid/Ask) Streaming
The Market Depth stream provides order book-level information, including the best available bid and ask prices for a trading instrument. This data helps clients understand real-time market liquidity and price levels beyond the last traded price (LTP).
Subscribe
{"type": "dps", "scrips": "nse_cm|11536", "channelnum": 1}Unsubscribe
{"type": "dpu", "scrips": "nse_cm|11536", "channelnum": 1}Market Depth Update Response
{"tk": "11536", "bp": "1905.70", "sp": "1907.00", "ts": "TCS-EQ"}| Field | Description |
|---|---|
| tk | Instrument token |
| bp | Best bid price |
| sp | Best ask price |
| ts | Trading symbol |
Pause / Resume Streams
Pause / Resume Market Data Streaming
The Channel Pause / Resume feature allows clients to temporarily stop or restart market data streaming for selected channels without unsubscribing. Pausing a channel does not close the WebSocket connection — data delivery resumes immediately upon resuming.
Pause Channel
{"type": "cp", "channelnums": [1, 2]}Resume Channel
{"type": "cr", "channelnums": [1, 2]}| type value | Description |
|---|---|
| cp | Channel pause |
| cr | Channel resume |
Data Modes
Lite & Full Data Modes
Lite & Full Data Modes allow clients to control the granularity and volume of market data received, helping balance performance, bandwidth, and data depth based on the application's requirements.
| Mode | Description | Recommended Use |
|---|---|---|
| Lite Mode (lit) | Minimal, essential data (LTP, basic price fields) | Watchlists, market watch screens |
| Full Mode (ful) | Detailed data including depth and analytics | Algo trading, analytics platforms |
Set Lite Mode
{"type": "lit", "channelnums": [1]}Set Full Mode
{"type": "ful", "channelnums": [1]}Option Chain Stream
Option Chain Streaming
The Option Chain Subscription feature allows clients to subscribe to all option contracts (CE & PE) for a given underlying instrument and expiry in a single request. Once subscribed, the WebSocket automatically streams live updates for all relevant option contracts including price, volume, and option-specific data.
| Field | Description |
|---|---|
| type | opc — Option Chain subscription identifier |
| channelnum | Channel identifier |
| key | exchange + underlying token + expiry date |
| stkprc | Reference strike price (usually ATM) |
| highstk | Number of strikes above reference |
| lowstk | Number of strikes below reference |
Subscribe Request
{
"type": "opc",
"channelnum": 11,
"key": "nse_cm|11536|29/07/2021",
"stkprc": 1,
"highstk": 1,
"lowstk": 1
}Both CE and PE contracts are streamed. Updates include price, volume, and option data. The
entire option chain can be paused, resumed, or unsubscribed using the same channelnum.
Order & Trade Updates
Detailed technical reference, validation parameters, schemas and client code orchestrations.
Order & Trade Updates (WebSocket)
Real-Time Order & Trade Updates — Introduction
Bigul Connect WebSocket provides a secure, persistent, real-time communication channel for delivering trade, order, and position updates to authenticated clients. All updates are pushed automatically by the server after successful authentication — no manual subscription or polling is required.
| Property | Value | Description |
|---|---|---|
| Protocol | wss | Secure WebSocket connection |
| URL | wss://{{websocket}}/socket | Bigul Connect WebSocket endpoint |
| Authentication Model | Token-based | Access token passed in initial JSON frame |
| Connection Type | Persistent | Single socket per authenticated client |
TOKEN REQUIREMENTS
Initial Connect Request
{
"type": "cn",
"x-access-token": "{{token}}",
"src": "WEB"
}Success Response (200)
{"ak": "ok", "type": "cn", "msg": "connected"}Error Response (4xx)
{"ak": "nk", "type": "cn", "msg": "failed to connect"}Heartbeat & Ping/Pong
Heartbeat & Ping/Pong
Heartbeat
Keeps the connection active and prevents closure due to inactivity.
{"type": "hb"}Ping / Pong
Verifies the health and responsiveness of the connection.
{"type": "ping"}
{"type": "pong"}| Feature | Heartbeat | Ping / Pong |
|---|---|---|
| Purpose | Keep connection alive | Check connection health |
| Client Initiated | Yes | Yes |
| Server Response | Not required | Pong response required |
| Used for Health Check | No | Yes |
| Used for Timeout Prevention | Yes | Indirect |
Key Notes
Order Streaming
Order Streaming
After successful WebSocket connection and authentication, Bigul Connect automatically pushes real-time order updates.
WHEN ARE ORDER UPDATES SENT?
Core Identification Fields
| Field | Type | Description |
|---|---|---|
| type | String | Always "order" |
| actId | String | Trading account identifier |
| usrId | String | User ID |
| nOrdNo | String | Unique order number |
| GuiOrdId | String | Client-side order reference ID |
Instrument & Exchange Fields
| Field | Type | Description |
|---|---|---|
| trdSym | String | Trading symbol (e.g., TCS-EQ) |
| tok | String | Exchange instrument token |
| exSeg | String | Exchange segment (e.g., nse_cm) |
Order Parameters
| Field | Type | Description |
|---|---|---|
| trnsTp | String | B = Buy, S = Sell |
| prcTp | String | Price type (e.g., MKT, LMT) |
| prc | String | Order price |
| trgPrc | String | Trigger price (if applicable) |
| qty | Number | Total order quantity |
| prod | String | Product type (e.g., CNC) |
| vldt | String | Order validity (e.g., DAY) |
Execution & Status Fields
| Field | Type | Description |
|---|---|---|
| fldQty | Number | Filled quantity |
| unFldSz | Number | Unfilled quantity |
| avgPrc | String | Average traded price |
| ordSt | String | Current order status |
| rejRsn | String | Rejection reason (if rejected) |
| rmk | String | Additional remarks |
Order Update Response Sample
{
"type": "order",
"data": {
"actId": "ABCXYZ14",
"avgPrc": "0.00",
"cnlQty": 0,
"exSeg": "nse_cm",
"fldQty": 0,
"GuiOrdId": "1719307595-727155-ABCDE1114A-ADMINAPI",
"hsUpTm": "2024/06/25 14:56:35",
"nOrdNo": "240625000001273",
"ordSt": "put order req received",
"prcTp": "MKT",
"prod": "CNC",
"qty": 1,
"tok": "11536",
"trdSym": "TCS-EQ",
"trnsTp": "B",
"usrId": "ABCDE1114A"
}
}Trade Streaming
Trade Streaming
Trade updates are generated whenever an order is executed (partially or fully).
| Field | Type | Description |
|---|---|---|
| type | String | Always "trade" |
| actId | String | Trading account identifier |
| usrId | String | User ID |
| nOrdNo | String | Internal order number |
| GuiOrdId | String | Client-side order reference ID |
| fldId | String | Unique trade (fill) identifier |
| trdSym | String | Trading symbol |
| tok | String | Instrument token |
| exSeg | String | Exchange segment |
| exOrdId | String | Exchange-assigned order ID |
| trnsTp | String | B = Buy, S = Sell |
| fldQty | Number | Executed quantity |
| avgPrc | String | Execution price |
| prod | String | Product type |
| exTm | String | Exchange execution time |
| fldDt | String | Trade execution date |
Trade Update Response Sample
{
"type": "trade",
"data": {
"actId": "ABCXYZ14",
"avgPrc": "3846.95",
"exOrdId": "1300000000012260",
"exSeg": "nse_cm",
"exTm": "25-Jun-2024 14:56:35",
"fldQty": 1,
"flDt": "25-Jun-2024",
"flId": "600005781",
"GuiOrdId": "1719307595-727155-ABCDE1114A-ADMINAPI",
"nOrdNo": "240625000001273",
"prod": "CNC",
"tok": "11536",
"trdSym": "TCS-EQ",
"trnsTp": "B",
"usrId": "ABCDE1114A"
}
}Position Streaming
Position Streaming
Position updates reflect changes in the client's holdings as trades are executed, squared off, or carried forward.
| Field | Type | Description |
|---|---|---|
| type | String | Always "position" |
| trdSym | String | Trading symbol |
| tok | String | Instrument token |
| exSeg | String | Exchange segment |
| prod | String | Product type |
| buyAmt | String | Total buy amount |
| sellAmt | String | Total sell amount |
| flBuyQty | String | Filled buy quantity |
| flSellQty | String | Filled sell quantity |
| cfBuyQty | String | Carried-forward buy quantity |
| cfSellQty | String | Carried-forward sell quantity |
| cfBuyAmt | String | Carried-forward buy amount |
| cfSellAmt | String | Carried-forward sell amount |
| hsUpTm | String | Last updated timestamp |
| updRecvTm | Number | Update received time (epoch) |
Position Update Response Sample
{
"type": "position",
"data": {
"buyAmt": "7662.15",
"cfBuyAmt": "0.00",
"cfBuyQty": "0",
"cfSellAmt": "0.00",
"cfSellQty": "0",
"exSeg": "nse_cm",
"flBuyQty": "2",
"flSellQty": "0",
"hsUpTm": "2024/06/25 14:56:37",
"prod": "CNC",
"sellAmt": "0.00",
"tok": "11536",
"trdSym": "TCS-EQ",
"updRecvTm": 1720687201098397200
}
}RELATIONSHIP BETWEEN UPDATE TYPES
| Update Type | Represents | Key Identifier |
|---|---|---|
| Order Updates | Order lifecycle & status changes | nOrdNo / GuiOrdId |
| Trade Updates | Actual exchange executions (fills) | fldId |
| Position Updates | Net holdings after executions | trdSym + prod |
Clients should consume all three update types together for accurate real-time trading state. Use REST APIs for reconciliation and historical data if WebSocket disconnects.