More queries

joy

A couple of requests/queries:

1. Is there any call to fetch the margins (for all the segments) at one go (like return an array of margins). If not can you please add it to your todo list.

2. The login (/session/token) response returns the following exchanges:

"exchange": ["CDS", "MCX", "BFO", "BSE", "NSE", "NFO"]

while the parameters (/parameters) call returned

"exchange": ["NSE", "BSE", "NFO", "CDS", "MCX", "MCXSX", "BFO"]

note: mcxsx is missing in the former.

Do I presume the former is the exchanges enabled for the said user id while the later is the complete list of exchanges supported by Z (and all may not be enabled for the user).

sujith

Hi @joy,

1. Is there any call to fetch the margins (for all the segments) at one go (like return an array of margins). If not can you please add it to your todo list.

Checkout this thread for margins API details.

2. The login (/session/token) response returns the following exchanges:
"exchange": ["CDS", "MCX", "BFO", "BSE", "NSE", "NFO"]
while the parameters (/parameters) call returned
"exchange": ["NSE", "BSE", "NFO", "CDS", "MCX", "MCXSX", "BFO"]
note: mcxsx is missing in the former.

Do I presume the former is the exchanges enabled for the said user id while the later is the complete list of exchanges supported by Z (and all may not be enabled for the user).

Yes, it means that MCXSX exchange is not enabled for the user.

joy

1. Is there any call to fetch the margins (for all the segments) at one go (like return an array of margins). If not can you please add it to your todo list.

Checkout this thread for margins API details.

@sujith

1. let me rephrase.

Currently I have to query 2 times (one for equity and another for commodity) to get the account values (pls note I am referring to the users cash balance etc and not the margin for individual scripts)

My request is a endpoint like "/user/margins" (note the endpoint has no segment defined) which will return the data (an array) for all the available segments (both for equity and commodity).

{
   "status": "success", "data": 
          [
              {   margin/account value for equity   }, 
              {   margin/account value for commodity   }
          ]
}

2. thanks for the clarification.

sujith

Hi @joy,
It doesn't make sense, these APIs are meant to be called once a day. I hope you are not calling this often.

joy

@sujith if the api supprots margin/accounts information we pull the data from the api as and when required. If the api does not supports margin/accounts information (or otherwise) we calculate it internally. Since the Kite API supports the accounts information we are pulling it periodically.

So that we can design our application accordingly what are the best practices suggested by Z.

tia

sujith

@joy,
I am afraid we can't consolidate it into a single http call. It has too much data.
You can fetch it once and cache it.
Can you tell me a scenario where you need to keep on fetching data.

joy

Can you tell me a scenario where you need to keep on fetching data.

@sujith when an order gets filled/partfilled we need to calculate the updated account value, update the position etc.

of-course it can be calculated internally, however data from the api is preferred.

joy

I suppose we are still not in sync

I am referring to the funds and margins as documented here
https://kite.trade/docs/connect/v1/#funds-and-margins

The response is certainly reasonable. An array of 2 segments will hardly make any difference.

{
  "status": "success",
  "data": {
    "enabled": true,
    "net": 0.0,
    "available": {
      "cash": 0.0,
      "intraday_payin": 0.0,
      "adhoc_margin": 0.0,
      "collateral": 0.0
    },
    "utilised": {
      "m2m_unrealised": 0.0,
      "m2m_realised": 0.0,
      "debits": 0.0,
      "span": 0.0,
      "option_premium": 0.0,
      "holding_sales": 0.0,
      "exposure": 23285.85,
      "turnover": 0.0
    }
  }
}

Vivek

@joy We don't have consolidated response for margins internally to our OMS hence even if we abstract internally we have to make two API calls and hence more prone to failures. We will try to work with our OMS vendor to consolidate the response but it might take quite some time.

joy

@vivek thanks for the clarification.