How does the relation between DealId and DealReference work in the different API endpoints

[SZZ]

I'm trying to follow the documentation here: https://labs.ig.com/rest-trading-api-reference

My goal: I want to open an order via API, get frequent updates via lightstream and a final update when the order is closed, including P&L information.

I open the order by putting a request to /gateway/deal/positions/otc v2. This works and returns a deal id and a deal reference

Then I confirm the order by deal id using /gateway/deal/confirms/ v1. This also works.

I also get updates via the lightstream API on the trade type OPU with the status OPEN and DELETED when the order is closed. Again, the DealId and the Reference match. But the DELETED update does not contain a P&L information.

 

So on DELETE I access the activity transaction history by deal ID: /gateway/deal/history/activity v3. This also works, but also does not contain P&L, but therefore a description with a new Id, reading "Position opened: [some id]". This id consits of the last part of the DealId.

Afterwards, I access the transaction history on /gateway/deal/history/transactions v2. Here I finally have a P&L, but the reference field contains a new reference that never showed up before. There is just no way to link the transaction to the activity or to an order.

 

So the question: Is there any way to get P&L information on a closed position based on deal Id or deal reference? I really don't want to match opening date and epic name, that's just bad practice.

 

 

 

 

 

[ColinAgbabiaka]

@SZZ did you get anywhere with this? It's also a problem I recently came across.

[bug-or-feature]

INFO:trading_ig.rest:GET '/history/activity/', resp 200
                   date                  marketName                      epic  period    level direction           dealId
0   2023-11-10T05:45:05           Oil - Brent Crude        EN.D.LCO.Month6.IP  JAN-24   8034.5      SELL  DIAAAANP68C8YAQ
1   2023-11-09T05:45:11  10-Year T-Note Decimalised  IR.D.10YEAR100.Month2.IP  DEC-23    10845       BUY  DIAAAANPPY34SAG


INFO:trading_ig.rest:GET '/history/transactions', resp 200
            openDateUtc              dateUtc              instrumentName  period openLevel closeLevel   size        reference profitAndLoss
0   2023-10-27T18:59:23  2023-11-10T05:45:05           Oil - Brent Crude  JAN-24      8923     8034.5  +0.53  DIAAAANP68C8YAQ      £-470.91
1   2023-09-26T17:17:04  2023-11-09T05:45:11  10-Year T-Note Decimalised  DEC-23   10814.4      10845  -0.62  DIAAAANPPY34SAG       £-18.97

The dealId field from the activities endpoint (/history/activity) matches the reference field from the transactions endpoint (/history/transactions)

[ColinAgbabiaka]

Thanks for confirming @bug-or-feature - the confusion is caused by what I presume is a Demo env bug, where the transaction reference generated for a closed trade is only half the length of the typical deadId character length 🤦‍♂️.

Here's an example: 

"date": "06/11/23",

"instrumentName": "FTSE 100 Cash (£10)",

"period": "-",

"profitAndLoss": "£25.00",

"transactionType": "DEAL",

"reference": "NR3HSJAP",

"openLevel": "7420",

"closeLevel": "7415",

"size": "-0.50",

"currency": "£",

"cashTransaction": false

The prefix of DIAAAAN was missing in this scenario and I couldn't in good faith presume it'd always be the same thus the confusion. Perhaps someone in the IG team could address how widespread this bug is.

 

[bug-or-feature]

@ColinAgbabiaka I'm not sure about any DEMO env bug - my example responses were from DEMO too.

My responses were from futures based spread bets, dated. Yours looks like an undated CFD, is that correct?

[ColinAgbabiaka]

@bug-or-feature oh right, faire enough, just an assumption about it being solely the DEMO env. Yes that's right, an undated CFD position that originated from a working order being filled.

[bug-or-feature]

Hmm not sure what is going on. My previous examples were market orders. I just tried a working order, and the transaction response contained the full 15 character reference field, eg DIAAAANXXXXXXXX

Maybe someone from IG can explain. Why does the reference field in the /history/transactions response sometimes contain the full dealId, and sometimes just the portion after DIAAAAN?

 

[bug-or-feature]

I've done a bit more digging - I think there is a bug. And now I understand the issue as described by @SZZ It looks to me like the /confirms endpoint returns the wrong dealId when closing a position. The Streaming API also reports the wrong dealId from the TRADE Subscription. They both respond with the dealId of the opening trade instead of the closing trade.

The correct closing trade dealId is reported by the /history/activity endpoint, and by the /history/transactions endpoint. So there is a workaround for your issue right now @SZZ . Once your trade is closed, look at the response of the /history/activity endpoint. Find the dealId where the affectedDealId is the ID of the opening trade, and description is "Positions/s closed: XXXXXXXX". Then lookup that dealId in the response of the /history/transactions endpoint, with field name reference.

I have reported this to the webapi team, will post any updates here

[bug-or-feature]

UPDATE:

I told the Web API team about this issue via their email address webapisupport@ig.com. Their reponse was: we know about this, it's not a bug. The excuse was

Quote

I understand that this is not 'consistent' with the history section but i looked through both reference documents and we also did not specify which dealID it is supposed to return

and then

Quote

This was how it is when we developed the API and we can submit this as a feedback to them to consider for future improvements.

My interpretation is: it has been like that since the API was released. They know its wrong, but to change it now would admit the mistake.

So for now, the laborious workaround mentioned above is the only solution.

Maybe if enough people make a noise about it, they will fix it. But I doubt it