Jump to content
  • 0

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



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.






  • Like 1
Link to comment

8 answers to this question

Recommended Posts

  • 0
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)

  • Like 1
Link to comment
  • 0

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.


Link to comment
  • 0

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?


Link to comment
  • 0

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

  • Like 1
Link to comment
  • 0


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


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


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

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • image.png

  • Posts

    • Crypto trading is a bit complicated when it comes to understanding the dynamics in profit making. Some people are more inclined to technical analysis which of course has been the widely used trading tool but some are more inclined to fundamentals but sticking to fundamentals alone could be highly risky in my own opinion even though crypto is also financial instrument that often respond to news updates.  A blend of the two could provide a safety net for traders in minimizing losses compared to potential profit. The above case scenario is largely attributed to perp futures trading and other derivatives. TA and FA could also be very useful for spot trading but I feel timely listing of projects could largely determine one's profit from investing in a project. These may not be for all projects cos some are **** coins. This could be a personal perspective but I have noticed listing speed is also another important factor to consider along with project fundamentals when trading and if we are to include listing speed as a factor for choosing trade then it will affect our choice of trading platform cos some are more inclined to top cap projects while others are more inclined low cap gems.   My experience with ORDI has proven this trading skill rewarding. ORDI was first listed on Bitget before other exchange joined the listing party after it saw rapid adoption reflecting in it significant MCap growth. This chart should give us a glimpse of my experience with this strategy.
    • In a stunning display of market momentum, the PANDORA token, the first of its kind, has skyrocketed an astonishing 4872% from its introduction on February 2nd to February 7th. This remarkable performance has not only caught the attention of cryptocurrency enthusiasts but has also solidified PANDORA’s position as a groundbreaking asset in the digital currency landscape. Pandora's ERC-404 protocol revolutionizes the token landscape by seamlessly blending the qualities of ERC20 and ERC721 standards. This experimental mixed implementation enables persistent liquidity and non-fungibility for NFTs, unlocking a realm of possibilities previously unexplored. Adding to the excitement, Bitget Wallet is gearing up to introduce a specialized section dedicated to ERC-404 token market listings. This feature creates a hub for tokens that blend the best of both worlds—the liquidity of ERC-20s and the uniqueness of ERC-721 NFTs. I have come to believe that, the electrifying surge of PANDORA token and the innovative ERC-404 standard is not just a fleeting trend but a window into the future of cryptocurrency.
    • A significant turning point in the #PORTALxBitget collaboration is the listing of $PORTAL on Bitget through the Candybomb event, which opens up benefits and synergistic prospects like 1. Diversified Trading choices: Users now have access to a wide range of trading choices thanks to $PORTAL's listing on the exchange, including cutting-edge leveraged trading capabilities and spot trading. This gives customers the freedom to interact with $PORTAL in a way that suits their preferred level of risk and trading techniques. 2. Community Synergy: By uniting the exchange users and the pre-existing $PORTAL community, the Candybomb event stimulates community engagement. Through this synergy, a positive environment surrounding #PORTALxBitget may be developed, encouraging cooperation, information exchange, and sustained interest in the project. Could this recent collab stimulate the  stage for a fruitful and mutually beneficial relationship between #PORTAL and exchange.
  • Create New...