Documenting Observations - Kite Connect Java Client from Zerodha

gautamsatpathy

Orders

Orders Combinations seen so far - (what I have executed today and hence what I am getting from Kite Connect):

Source,Product,Order Type,Order Variety,Transaction Type,Validity,Instrument Type
MANUAL,CNC,MARKET,AMO,BUY,DAY,STOCK
GTT,CNC,LIMIT,REGULAR,SELL,DAY,STOCK
MANUAL,CNC,MARKET,REGULAR,SELL,DAY,STOCK
  • GUID is missing from orders executed via GTT or a REGULAR MARKET order.
  • User ID is always NULL
  • Symbol is always NULL
  • Order Variety is in small case
  • Executed GTT Orders do not have the Trigger Price populated. IT is NULL.
  • gautamsatpathy
    The idea behind this thread is to document what I am seeing while working with the Kite Connect Java Client in terms of how it behaves. That is what values it is returning under different conditions.

    Would request all users to add their observations for the benefit of the wider community. This is particularly important given the dismal state of documentation of the Java client.
  • gautamsatpathy
    gautamsatpathy edited June 2021

    Holdings

    Call to KiteConnect getHoldings() method.
    • Account Id is always NULL.
    • Overnight Futures do not show up under Holdings. They are only visible in Net Positions.
    • Holdings sold today will show up in the Holdings list but with Price = null, Quantity = null, P/L = null.
  • gautamsatpathy
    Ticks WebSocket Timestamps
    • Tick Timestamp and Last Traded Time are both returned at second resolution.
    From KiteTicker.java
    long lastTradedtime = convertToLong(getBytes(bin, 44, 48)) * 1000;
    if(isValidDate(lastTradedtime)) {
    tick.setLastTradedTime(new Date(lastTradedtime));
    } else {
    tick.setLastTradedTime(null);
    }

    and

    /* Convert binary data to long datatype*/
    private long convertToLong(byte[] bin){
    ByteBuffer bb = ByteBuffer.wrap(bin);
    bb.order(ByteOrder.BIG_ENDIAN);
    return bb.getInt();
    }

    In KiteTicker.java, Zerodha is using bb.getInt() and returning a "long". Assuming that the original JSON response has the millisecond data, this will lose data and we see that the value returned by the convertToLong() method is multiplied by 1000 to get a long to use as lastTradedTime.

    The Zerodha code effectively throws away the millisecond information and truncates the time to "second" level resolution.

    @ToDo Double check the JSON response data to see if Zerodha is sending the millisecond data from the server.
  • gautamsatpathy
    Kite Ticker Responses for Each Mode

    Actual responses from the Kite Connect Ticker API using the different modes available.

    Mode LTP
    Mode: ltp, Tradeable? true, Token: 6191105, Last Traded Price: 2827.0,
    High: 0.0, Low: 0.0, Open: 0.0, Close: 0.0, Change: 0.0, Last Traded Quantity: 0.0,
    Average Traded Price: 0.0, Vol Today: 0.0, Total Buy Qty: 0.0, Total Sell Qty: 0.0,
    Last Traded Time: null, OI: 0.0, OI High: 0.0, OI Low: 0.0, Tick TS: null

    Mode QUOTE
    Mode: quote, Tradeable? true, Token: 828673, Last Traded Price: 106.35,
    High: 108.2, Low: 106.0, Open: 107.7, Close: 106.9, Change: -0.5144995322731631,
    Last Traded Quantity: 10.0, Average Traded Price: 107.02, Vol Today: 142342.0,
    Total Buy Qty: 1550.0, Total Sell Qty: 0.0, Last Traded Time: null, OI: 0.0,
    OI High: 0.0, OI Low: 0.0, Tick TS: null

    Mode FULL
    Mode: full, Tradeable? true, Token: 57623559, Last Traded Price: 68287.0,
    High: 68569.0, Low: 67687.0, Open: 67920.0, Close:67670.0, Change: 0.9117777449386729,
    Last Traded Quantity: 1.0, Average Traded Price: 68047.4, Vol Today: 74458.0,
    Total Buy Qty: 3054.0, Total Sell Qty: 3877.0,
    Last Traded Time: Wed Jun 23 20:35:56 IST 2021, OI: 27585.0, OI High: 38188.0,
    OI Low: 27585.0, Tick TS: Wed Jun 23 20:35:57 IST 2021
    The FULL Mode also gives the 5 Depth BID & OFFER data.

    The main problem I see here is with the LTP & Quote Ticks. The Timestamp fields are both NULL!

This discussion has been closed.