Jump to content
  • 0

Can't access /history/transactions v2 via API


Rick

Question

I'm trying to access /history/transactions v2 via API, in order to retrieve accurate entry and exit times (not supported in v1).

I'm writing in C#, based on the API samples, but they only seem to support v1, and not the v2 documented in the Reference guide.

Anyone know how to amend the v1 code to make it support v2 ... the call in sample code is

        public async Task<IgResponse<TransactionHistoryResponse>> lastTransactionPeriod(string transactionType, string lastPeriod) 
        {
            return await _igRestService.RestfulService<TransactionHistoryResponse>("/gateway/deal/history/transactions/" + transactionType + "/" + lastPeriod, HttpMethod.Get, "1", _conversationContext);
        }

.. and yes, I did try just changing the "1" to a "2" ... I get an Error 500.

Any help most gratefully received!  This has been driving me crazy!

Link to post

3 answers to this question

Recommended Posts

  • 0

I use the transactions endpoint in my Excel Add-in and it works well. However, as you say it need to be set to API V2 as V1 is no longer supported.

The API version needs to be set on the request header, for example:

Quote

            HttpClient client = new HttpClient();
            client.DefaultRequestHeaders.Add("Version", "2");

I would check the code where the actual request is made and make sure this is being set correctly.

I hope this helps.
 

  • Like 1
Link to post
  • 0

Thanks for responding Andy.

Stepping through the code, the relevant section of the IG sample API code can be precised as

var client = new HttpClient();

            ...

            if (conversationContext != null)
            {
                if (conversationContext.apiKey != null)
                {
                    client.DefaultRequestHeaders.Add("X-IG-API-KEY", conversationContext.apiKey);
                }
                if (conversationContext.cst != null)
                {
                    client.DefaultRequestHeaders.Add("CST", conversationContext.cst);
                }
                if (conversationContext.xSecurityToken != null)
                {
                    client.DefaultRequestHeaders.Add("X-SECURITY-TOKEN", conversationContext.xSecurityToken);
                }
                client.DefaultRequestHeaders.Add("VERSION", version);


            }          
            //This only works for version 1 !!!           
            //client.DefaultRequestHeaders.TryAddWithoutValidation("version", version ?? "1");

            ...

            var response = new HttpResponseMessage();
            string content = null;

            switch (method.Method)
            {
                case "POST": ...

                case "GET":
                    var myGetTask = client.GetAsync(_baseUrl + uri);
                    response = myGetTask.Result;                                 
                    break;

This returns transaction data quite happily using Version 1 of the interface (but without the additional V2 data), but errors if I try to run it with Version=2 ...

image.thumb.png.47a7f5cd0a93873ac2e7c49c603463d4.png

Any ideas?  Note the comment in the IG code!!! Or could you send me a code sample in VB from your spreadsheet, to see if I can translate into C# (shouldn't be too difficult) ...

Rick

 

Link to post
  • 0

Well, as always with these things, if you beat your head against the wall for long enough you can probably fix it 🤣.  I realised that the sample code uses the URI /history/transactions/{transactionType}/{lastPeriod} to access the V1 interface.  V2 uses a slightly different URI ... just /history/transactions, with variable parameters  passed using the '?' construct.  I picked this up from the API Companion app, which helpfully shows the generated GET URIs.  Then I had to invent a new V2Transaction type ( since the demo code only supports V1) to persuade JSON to deserialise to result for me.  Problem (eventually) solved.

I'm still grateful to Andy for responding, and giving me confidence that there are those out there who care.  If anyone wants more details on this particular problem, let me know, and I'll try to post some revised code (once I've cleaned it up, of course!).

Link to post

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • General Statistics

    • Total Topics
      15,142
    • Total Posts
      73,173
    • Total Members
      61,488
    • Most Online
      5,137
      14/01/21 09:51

    Newest Member
    Sanjjay82
    Joined 08/05/21 07:12
  • Posts

    • Yes. IG does trade against retail traders. IG also has a lot of institutional traders. If your are trading low volume stock or Singapore CFD equities, the dealing desk will manually lock your order for a good 30 seconds so that you cannot delete nor change the order price level for the 30 seconds when they there is another bigger clients want to unload.  I have been locked this way as many ast 4 times in the past and cost over SG$10,000 loss. When I called IG, it said the dealing desk manually lock my orders with an excuse they are putting my order on hold so that they hedge it on the Exchange. In the first place I trade CFD and CFD is internal market within IG environment and our trade does not affect the market. It is highly irresponsible to lock our order. My complaints to IG for compensation via calls and emails all went without any positive response and the replies from them are as stated above. CFD market is internal market and our order should not be touched by dealing desk at all time even if there is no liquidity to fill our order then our order should just be left unfilled. At no time our order should never be locked by Dealing desk. To me this is day light robbery. Secondly, IG has deployed internal algorithm to hunt your hard stop losses and also filled in your limit order with a spike to the dot before immediately move in the opposite direction big time. Thirdly, some time IG platform will freeze and unable to re-login back when you are in a trade. This made it extremely dangerous when we cannot see the price action on the chart. This had happened to me a few times. Fourthly, nowadays even if your platform freeze or has other problem on your trade, call to their dealing desk during US market opens 100% of the time no support or dealing desk will pick your calls. My phone was kept ringing for 30mins or more and many different days. This is again does not speak well of the kind of support IG gave clients. The only attraction I use IG is the ease of use of their trading platform. These kind of  underhand tactics above are played out in IG on daily basis which made our day trading very difficult to win. It is very visible if your trade the small time frame how IG's manipulations are done.     The above comes from someone who trade daily with IG for the past 3 years. I am even considering to stop trading through IG because of the above under hand tactics. Sometimes     
    • Does IG aim to profit from client losses? No. Our business model is based on providing individuals with the opportunity to trade the world’s financial markets, in exchange for fair and proportionate transaction fees. It's a well-known fact that trading successfully is difficult, and most speculative traders tend to lose. However, we do not typically benefit from trading losses that an unsuccessful client may experience. Mostly, our clients offset each other’s positions. For example if client A buys one lot of the DAX and client B sells one lot of the DAX, both sides of the trade are covered. This means we're not exposed to the profit or loss of either client. Instead, we make our money via the spread (i.e. the transaction fee) that each client pays to trade. Sometimes, a large majority of clients will trade in one direction. When this happens, we'll protect our exposure to risk by hedging in the underlying market. For example, if client A and client B both buy the DAX, we may buy actual DAX futures. This then covers the amount we'll pay out if both clients are successful.
×
×
  • Create New...