Jump to content


Community Member
  • Posts

  • Joined

  • Last visited

  • Days Won


bug-or-feature last won the day on January 19

bug-or-feature had the most liked content!


Recent Profile Visitors

3,144 profile views

bug-or-feature's Achievements

Frequent Contributor

Frequent Contributor (3/10)

  • Superstar Rare
  • Helpful Rare
  • Great Support Rare

Recent Badges



  1. Sounds similar to this issue: https://community.ig.com/forums/topic/24800-demo-account-position-closed-at-a-non-existing-price/
  2. That shows the account that is logged into the REST API companion. What is important is the credentials you are using in the trading-ig library. Check the file trading_ig_config.py in your project, and make sure it is using the correct account details
  3. @BCC are you logging in to a Spread bet or CFD demo account? To stream a CFD epic, you will need to log in with a CFD account. User name, password and API key will be the same as with a spreadbet account - but account ID will be different. Its the 'acc-number' param in trading-ig. The sample works fine for me with the epic IX.D.NASDAQ.IFD.IP in a CFD demo account, but fails like your snippet when logged into a spread bet account
  4. Ask a question here: https://github.com/Lightstreamer/Lightstreamer-lib-client-haxe/issues The Lightstreamer guys are really helpful in my experience
  5. Hi @KoketsoIG - in my account all the positions have reappeared. Thanks for resolving
  6. There is a serious problem with the DEMO spread bet environment. Over the weekend 7 of my 12 open spreadbet positions disappeared. There is nothing in the history or activity views to say why. There are no closing transactions. On the My IG Dashboard view, my balance and P&L shows as if all the positions still exist; but on the platform view, the balance and P&L is valid for only the visible positions. My problem sounds like @Ravager's issue here. But I know that it is nothing to do with the app, or any browser or caching issue, as the REST API reports the same position list, missing the the same bets. Is anyone from IG looking into this, or know what is going on?
  7. 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 and then 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
  8. There's a section in the FAQ about the API limits https://labs.ig.com/faq Note that the limits described there are for the LIVE environment. The limits in DEMO are different, less, and variable. In my experience though, you still get 10,000 price points per week for historical data
  9. Price data is paged, and the default page size is 20. It is all in the docs https://labs.ig.com/rest-trading-api-reference/service-detail?id=682
  10. 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
  11. 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?
  12. @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?
  13. 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)
  14. Ah, well firstly "all the indices on IG" is a lot less than "all the pricing data". It's still a lot. Spread bets, CFDs, something else? A lot depends what your hypothesis is. Are you investigating spread values? If so, you could get the prices from somewhere else, and sample the IG spread using the Streaming API. With that API you can be subscribed to 40 instruments concurrently. See here Platform choice is a big subject, probably not a question for this forum - I'm sure you have great Google skills being a researcher. But you could start with Yahoo Finance, Google Finance or AlphaVantage
  15. Thanks @KoketsoIG Can you ask the dealing desk to make them consistent please?
  • Create New...