Option Chain Response imporvement suggestions... currently its a mess

Developer API
,
1

Namaskara,

The current implementation of Option Greek Response JSON is a mess.

{
“status”: “success”,
“data”: [
{
“expiry”: “2025-02-13”,
“pcr”: 7515.3,
“strike_price”: 21100,
“underlying_key”: “NSE_INDEX|Nifty 50”,
“underlying_spot_price”: 22976.2,
“call_options”: {
“instrument_key”: “NSE_FO|51059”,
“market_data”: {
“ltp”: 2449.9,
“volume”: 0,
“oi”: 750,
“close_price”: 2449.9,
“bid_price”: 1856.65,
“bid_qty”: 1125,
“ask_price”: 1941.65,
“ask_qty”: 1125,
“prev_oi”: 1500
},
“option_greeks”: {
“vega”: 4.1731,
“theta”: -472.8941,
“gamma”: 0.0001,
“delta”: 0.743,
“iv”: 262.31,
“pop”: 40.56
}
},
“put_options”: {
“instrument_key”: “NSE_FO|51060”,
“market_data”: {
“ltp”: 0.3,
“volume”: 22315725,
“oi”: 5636475,
“close_price”: 0.35,
“bid_price”: 0.3,
“bid_qty”: 1979400,
“ask_price”: 0.35,
“ask_qty”: 2152500,
“prev_oi”: 5797500
},
“option_greeks”: {
“vega”: 0.0568,
“theta”: -1.2461,
“gamma”: 0,
“delta”: -0.0013,
“iv”: 50.78,
“pop”: 0.15
}
}
}
]
}

I am proposing a better, cleaner and easier to process alternative Response JSON structure…

{
“status”: “success”,
“expiry”: “2025-02-13”,
“underlying”: {
“symbol”: “Nifty 50”,
“spot_price”: 22976.2
},
“option_chain”: [
{
“strike_price”: 21100,
“pcr”: 7515.3,
“call”: {
“instrument_key”: “NSE_FO|51059”,
“market_data”: {
“ltp”: 2449.9,
“volume”: 0,
“oi”: 750,
“prev_oi”: 1500,
“bid”: { “price”: 1856.65, “qty”: 1125 },
“ask”: { “price”: 1941.65, “qty”: 1125 },
“close_price”: 2449.9
},
“greeks”: {
“delta”: 0.743,
“gamma”: 0.0001,
“theta”: -472.8941,
“vega”: 4.1731,
“iv”: 262.31,
“pop”: 40.56
}
},
“put”: {
“instrument_key”: “NSE_FO|51060”,
“market_data”: {
“ltp”: 0.3,
“volume”: 22315725,
“oi”: 5636475,
“prev_oi”: 5797500,
“bid”: { “price”: 0.3, “qty”: 1979400 },
“ask”: { “price”: 0.35, “qty”: 2152500 },
“close_price”: 0.35
},
“greeks”: {
“delta”: -0.0013,
“gamma”: 0,
“theta”: -1.2461,
“vega”: 0.0568,
“iv”: 50.78,
“pop”: 0.15
}
}
},
{
“strike_price”: 21200,
“pcr”: 7515.3,
“call”: {
“instrument_key”: “NSE_FO|51059”,
“market_data”: {
“ltp”: 2449.9,
“volume”: 0,
“oi”: 750,
“prev_oi”: 1500,
“bid”: { “price”: 1856.65, “qty”: 1125 },
“ask”: { “price”: 1941.65, “qty”: 1125 },
“close_price”: 2449.9
},
“greeks”: {
“delta”: 0.743,
“gamma”: 0.0001,
“theta”: -472.8941,
“vega”: 4.1731,
“iv”: 262.31,
“pop”: 40.56
}
},
“put”: {
“instrument_key”: “NSE_FO|51060”,
“market_data”: {
“ltp”: 0.3,
“volume”: 22315725,
“oi”: 5636475,
“prev_oi”: 5797500,
“bid”: { “price”: 0.3, “qty”: 1979400 },
“ask”: { “price”: 0.35, “qty”: 2152500 },
“close_price”: 0.35
},
“greeks”: {
“delta”: -0.0013,
“gamma”: 0,
“theta”: -1.2461,
“vega”: 0.0568,
“iv”: 50.78,
“pop”: 0.15
}
}
}
]
}

Kindly give a thought and implement this… easy to do…

Regards
Rathnadhar K V

2

Hi @RathnadharKV, Thank you for your suggestion. While we can’t incorporate this directly into the current API version due to its usage by many users, we’ll definitely consider this structure when a newer version with additional features is released.

3

I suggest you have a development branch … that is exposed to developers and one that is updated on weekly basis to say the least.

We will code, test and report issues in the developer branch.

Once its stable to go, you can go ahead and merge with main branch as new release version.

Regards
Rathnadhar K V