We have an important update to the HTTP postback (webhook) APIs that will go live on Monday, 13th Nov, 2017. In addition to the Postbacks you receive currently (COMPLETE, CANCELLED, REJECTED), you will start receiving a new UPDATE Postback for every update that happens to an order including parameter modifications and partial fills and trades.
What changes? Refer to the Postback JSON structure here. Starting Monday (13 Nov), you will get Postbacks that come with "status": "UPDATE" in addition to the three existing statuses (COMPLETE, CANCELLED, REJECTED). There is no change to the rest of the body.
You'll want to keep an eye on the "pending_quantity" and "filled_quantity" fields to track trade updates to an order.
EDIT: What's in the next release (#4)? - Updated WebSocket (binary) protocol with new fields (trade timestamp, Open Interest, circuit values) - Realtime order and trade postbacks over WebSockets - Realtime position updates over WebSockets
Hello, Right now as per Dashboard update.. The URL POSTed. This has to be an HTTPS url. And based on Latest release , update to the HTTP postback (webhook) So we can use HTTP url. Pls Clarify RPS.VINOD
@rpsvinod No, its just a reference to webhook. You still need HTTPS to receive postbacks. You can checkout Letsencrypt to generate SSL certifcates for free - https://letsencrypt.org/
Received email update that the "Postback (Webhook) APIs that will go live on Monday, 13th Nov, 2017."
I dont use postbacks as of now. I only uses kite connect for placing/modifying/cancelling orders and websocket for live price. Can I ignore this release? In other words, can i be sure that it will not impact my live implementations?
When can we expect the same feature through Websockets and just not throught Postbacks as what would be released on 13 Nov. Order Updates and Status (Partially filled/ quantity filled) through Websockets is overdue now.
@Prem Postbacks are easy to process and you don't need client library support. Just need to parse the JSON and match the signature.
@Ones This is going to a be a part of release 4. It's taking time because it involves breaking changes to the binary WebSocket protocol. I've added an edit to the original post above. Take a look.
Is the c# dot net official library updated with latest Kite API 3.0 release ? If yes, could you please provide the link for the same? Also how to use/code post webhooks with a c# application? I dont own any website. Can we still get post hooks to c# application? Any sample code please?
Hi @vijay407, You can use the new bulk fetch APIs, fetch historical data for a particular time (minute) in the new version of .NET client. As of now, to use postbacks you need a remote setup as Kite Connect will post data to that endpoint for every order status update. In coming days, we are planning to stream postbacks in websockets for which you don't need remote setup. You can check out latest version of .NET client here and examples here.
I read API Doc but not able to know what to do at client side to receive Postback via postback URL. Suppose I have added my postback url like: "http://demopostback.in"
Then what will be the next step at client end(In my Java Program). I have to call Orderr API again and again.
Can you please guide, how to listen Postbacks from java program??
@Kailash Are you pushing new updates to libraries as well to benefit from these. If yes, please make them connect to new 3.0 backend.
If no, then you would appreciate you have lost credibility around timelines. As you keep bemoaning, a lot may be dependent on external dependencies over which you have no control (and I doubt that is the only reason), a final roll-out could still take a long time.
As an alternate approach, please roll-out significant updates as soon as you reach those milestones. Like you, even we traders are not immune to the need to constantly upgrade and innovate. Especially, those of us trading intraday, we need faster and faster and more and more efficient execution. I hope you appreciate that.
@Kailash, For an user who want to use tick data streamed over websockets over quotes API, I have two requirements:
a. Backfill: In websockets, we miss data because of network issues, system crash etc. Right now, these are permanent black holes in data. Now that you will be providing timestamps in tick data, if you can introduce backfill as well, it will be great. If this is too onerous, even if you could add the functionality of fetching tickdata (even if for same day only) from quotes api, maybe we can pull this missing data when we reconnect after disconnection.
b. Volume since last tick: One minute candle can be formed by resampling tick data, wherin you take open as price in first tick, close as price in last tick, high as highest of price in ticks comprising that candle and low as lowest of price in the ticks. Volume generally should be sum of volumes in individual ticks. Its a fairly simple task and this can be used to create candle for any desired time frame. This is infact standard operating procedure.
However, currently we don't have the volume_traded_since_last_tick field. Which means that if we want to resample ticks to form candles, we have to either: i. Calculate this volume_traded_since_last_tick field locally on the fly in on_tick handler. Which means we have maintain state of volume in last candle as well as do a subtraction, both of which introduce latency and consequently, undermine our fast execution expectations. ii. When we form candle, we calculate OHLC as indicated. However, for volume in current candle, we subtract the volume in the last tick in current candle from volume at the end of last candle/last tick in last candle. While this is no problem for static data, it is a complicated task to accomplish on streaming data without introducing latency.
My own belief is that if you will introduce these two features, and put tutorials on how to convert tick data to candles, a lot of traders (who are using the simpler quotes API in websocket usecase) will actually migrate to websockets.
@sauravkedia As I've stated in the past posts, a significant portion of the backends have already been upgraded. That's what we've been doing for over a year.
The client libraries will be released and updated together with all breaking changes to avoid the scenario you are talking about--to avoid multiple upgrades and changes at your end. Once the new WebSocket protocol is ready, we'll upgrade all client libs to 3.0.
a) Unfortunately, this is not going to be possible. We do not have the infra to store tick data as we are not allowed to distribute it.
b) This is how we do it on Kite web's charts. It's going to be difficult for us to stream it but we can consider making this a part of the WebSocket client libraries so that you don't have to do the additional work.
@Kailash Kudos for #3 Release. Thought not much of an impact for me as I don't use postbacks for now. I am more interested in #4.. that seems to have some real good features - primarily position updates via WS. What is the current timeline for #4 release? Thanks Ravi
I noticed that the prices are not accurate and up-to-date in Bulk Quotes API.
Attached below is the snapshot of one of such quotes. There are many such commodities where prices are not accurate. Any problem today or are the data delayed ? Please have a look.
Right now as per Dashboard update..
The URL POSTed. This has to be an HTTPS url.
And based on Latest release , update to the HTTP postback (webhook)
So we can use HTTP url. Pls Clarify
RPS.VINOD
I dont use postbacks as of now. I only uses kite connect for placing/modifying/cancelling orders and websocket for live price. Can I ignore this release? In other words, can i be sure that it will not impact my live implementations?
It is possible to implement this in Java kiteconnect library????
If yes, kindly update java kiteconnect by implementing this feature.
Kindly reply ASAP.
@Ones This is going to a be a part of release 4. It's taking time because it involves breaking changes to the binary WebSocket protocol. I've added an edit to the original post above. Take a look.
How to register for order postback?? Kindly explain it. How to work with postback work with postback webhooks?
Please reply ASAP.
Then -> https://kite.trade/docs/connect/v1/#postback-webhooks
If yes, could you please provide the link for the same?
Also how to use/code post webhooks with a c# application? I dont own any website. Can we still get post hooks to c# application? Any sample code please?
You can use the new bulk fetch APIs, fetch historical data for a particular time (minute) in the new version of .NET client.
As of now, to use postbacks you need a remote setup as Kite Connect will post data to that endpoint for every order status update. In coming days, we are planning to stream postbacks in websockets for which you don't need remote setup.
You can check out latest version of .NET client here and examples here.
I read API Doc but not able to know what to do at client side to receive Postback via postback URL.
Suppose I have added my postback url like: "http://demopostback.in"
Then what will be the next step at client end(In my Java Program). I have to call Orderr API again and again.
Can you please guide, how to listen Postbacks from java program??
If no, then you would appreciate you have lost credibility around timelines. As you keep bemoaning, a lot may be dependent on external dependencies over which you have no control (and I doubt that is the only reason), a final roll-out could still take a long time.
As an alternate approach, please roll-out significant updates as soon as you reach those milestones. Like you, even we traders are not immune to the need to constantly upgrade and innovate. Especially, those of us trading intraday, we need faster and faster and more and more efficient execution. I hope you appreciate that.
You can try this python implementation. Read the comment on top of the code to setup postbacks.
If you want to use Java you might need to set up a local tomcat server and create a JSP page to process post back information.
We have started working on new versions of client libraries for our new backend. They will be out soon.
a. Backfill: In websockets, we miss data because of network issues, system crash etc. Right now, these are permanent black holes in data. Now that you will be providing timestamps in tick data, if you can introduce backfill as well, it will be great. If this is too onerous, even if you could add the functionality of fetching tickdata (even if for same day only) from quotes api, maybe we can pull this missing data when we reconnect after disconnection.
b. Volume since last tick: One minute candle can be formed by resampling tick data, wherin you take open as price in first tick, close as price in last tick, high as highest of price in ticks comprising that candle and low as lowest of price in the ticks. Volume generally should be sum of volumes in individual ticks. Its a fairly simple task and this can be used to create candle for any desired time frame. This is infact standard operating procedure.
However, currently we don't have the volume_traded_since_last_tick field. Which means that if we want to resample ticks to form candles, we have to either:
i. Calculate this volume_traded_since_last_tick field locally on the fly in on_tick handler. Which means we have maintain state of volume in last candle as well as do a subtraction, both of which introduce latency and consequently, undermine our fast execution expectations.
ii. When we form candle, we calculate OHLC as indicated. However, for volume in current candle, we subtract the volume in the last tick in current candle from volume at the end of last candle/last tick in last candle. While this is no problem for static data, it is a complicated task to accomplish on streaming data without introducing latency.
My own belief is that if you will introduce these two features, and put tutorials on how to convert tick data to candles, a lot of traders (who are using the simpler quotes API in websocket usecase) will actually migrate to websockets.
The client libraries will be released and updated together with all breaking changes to avoid the scenario you are talking about--to avoid multiple upgrades and changes at your end. Once the new WebSocket protocol is ready, we'll upgrade all client libs to 3.0.
a) Unfortunately, this is not going to be possible. We do not have the infra to store tick data as we are not allowed to distribute it.
b) This is how we do it on Kite web's charts. It's going to be difficult for us to stream it but we can consider making this a part of the WebSocket client libraries so that you don't have to do the additional work.
Kudos for #3 Release. Thought not much of an impact for me as I don't use postbacks for now. I am more interested in #4.. that seems to have some real good features - primarily position updates via WS. What is the current timeline for #4 release?
Thanks
Ravi
This is with reference to Kite Bulk Quotes API. (https://kite.trade/docs/connect/v1/#retrieving-quotes-in-bulk)
I noticed that the prices are not accurate and up-to-date in Bulk Quotes API.
Attached below is the snapshot of one of such quotes. There are many such commodities where prices are not accurate.
Any problem today or are the data delayed ? Please have a look.
We have made some changes. Let us know if you face the same issue again.