Konrad

When order preview is visible on the chart, and target/stoploss prices are out of the current view - chart is resizing itself in order to include target/stoploss prices in the view and when price is moving up/down, the chart is also jumping up/down to keep target/stoploss prices in the view.

Hey IG any comment on this? K.

I think there are differences in SL operations on different accounts.but I'll try to answer regardless: I'm not an expert here but I'd lean towards (1) however - technicaly it's not a 'short' transaction because you are not borrowing any stocks - IG is just placing a 'sell/stop' order with the stop-loss price - but the price is not guaranteed because it's up to the market to hit your price level when the order is placed? - this it a technical question for IG and I'm not sure if they are willing to share this information and bear in mind (pun) that there are few types of stop loss - normal, guaranteed, trailing - so there is more intricacies this: https://www.investopedia.com/terms/s/stoporder.asp can be helpful K.

Hi I've fetched some historic data (MINUTE resolution one of the NYSE epics) using Rest API - I've done it using DEMO account and I've noticed some weird values in pre/after market hours Data structure: date, volume, openBid, openAsk, closeBid, closeAsk, highBid, highAsk, lowBid, lowAsk Eamples: 2023/03/08 00:00:00,320,0,0,0,0,0,0,0,0 2023/03/08 00:04:00,167,8220,0,8220,0,8220,0,8220,0 2023/03/08 00:10:00,1359,0,8233,0,8231,0,8233,0,8231 2023/03/08 00:14:00,1,0,0,0,0,0,0,0,0 all examples above shows that: - there was a vlume > 0 which indicates that something was traded but there are missing bid/ask prices (especially in the first example) so my questions are: should I expect data from PROD environment to be more reliable? are you (IG) going to fix these data points somehow in the future? Thanks K.

Ok cool, thanks! I'll be more forgiving during weekends then

it looks like even API conpanion has some issues:

If I've noticed an odd behaviour of the platform, which is probably 'a bug' not a feature, is there a dedicated place where I can raise it? Cheers K

I have a code for data fetching using igAPI. I works perfectly fine but... only Mon-Fri. And weekends for me are days when I can test changes... on demo endpoint - but for some reason during weekend I get various 40x responses. Do you guys have a maintenance of demo servers during weekends? Cheers K

Hi My prev answer was obviously... stating the obvious... sorry for that. 'Resolution' should stay at 5 min. 'Price' means if you are looking at Ask price, Bid price or Mid of both of previous two - if you don't know which one to set - leave it at 'Mid' Indicator params for RSI: 'Period' - means how many {Resolution} data points (candles) are taken into this alers - in you case 1 point = 5 min - so set it to the lowest value (2) - otherwise you'll be spammed and then you have 'over', 'under'. 'crosses' + value - this is self explanatory Be careful with 'crosses' value - because during 'longer' timeframes - like 5 min - RSI can cross the line 30/70 many times - because indicators are calculated in real time - you can notice that indicator of the 'current' candle is moving up-down with the price change - it'll stop when the candle {Resolution} period is finished. 'Alert me' - this is crucial for you. If you leave it with default "Immediately' value - it means that alert will be generated every time RSI meets you conditions - so if during your 5 min candle, RSI is crossing 30/70 threshold (and we know it will), you'll be notified. The safest approach for you is to set it to 'At the end of the candlestick' + 'Once' - in this configuration you should be notified max twice (once for each candle) Cheers K

Hi I think the reason why you are flooded with alerts is 'OR' keyword

ech... ok I've found default setting for this... thanks IG support for ignoring this message for over a month, you are the best! K

so is this a bug or intentional bad design decission? K

However... now I realise that there are differences between accounts so it might be that on Share Dealing account the third trade will be merged with the first long and you's endup with 1 long (avg down) and 1 short... My prev answer is true for CFD account for sure

Wait a sec... So why there is a parameter called 'when filled' with 2 options 'net off'/' force open' in both 'new deal' and 'new order' actions K

When trading on any platform (CFD) each deal has a default trade execution type set to 'net off'. What is the reason behind choosing this value as the default one? I'm asking because I just lost some money (again) when opening new position against another already existing position. Imho most ppl when they see name 'new deal' they expect to open new position - if they already have an opened position on the opposite side of the market, they should know about it and the intention behind new deal is to open a hedge - not to trim an existing position. Also, hedge is (again Imho) better solution from customer's perspective - it doesn't involve loosing money. So why IG has decided to go for 'net off' option? Possible solutions: 1. Leave the fiend empty but required - this will prompt a trader to make a conscious decision. 2. Make it configurable. 3. Make 'force ooen' as a default option. 4. Add another option to edit existing position (as ame way as you can edit limit/stoploss) - for situations such as closing only fraction of existing position... K

Is there an option in IG to 'add' to one of my existing positions? looking at 'net off / force open' radiobutton I'd assume that 'net off' should average up/down my existing position (in case of opening new pos in the same direction as the existing one) but this is not the case so... is there such option hidden somewhere or maybe there is a plan to introduce it in the future? Thanks for all the answers. K

You'd endup with 3 positions (2 long 1 short) Unforutnately I couldn't find any option to average up/down your position - in IG world every trade is a separated position.

Ok just got the answer. I was sending api version "1" explicitly in headers...

Thanks Andy! I'll double check it on my side of the wire then...

Hi I'm following API reference and I'm stuck on requests for getting historic prices. According to ref sheet I should send a GET req to following uri: v1: /prices/{epic}/{resolution}?startdate={startdate}&enddate={enddate} v2: /prices/{epic}/{resolution}/{startDate}/{endDate} v3: /prices/{epic} However all of them gives me 404 response. (my framework works ok when I define resolution and number of points in /prices/{epic}/{resolution}/{numPoints} request => uri: https://demo-api.ig.com/gateway/deal/prices/SA.D.AMD.DAILY.IP/MINUTE/1) in the description of startDate/endDate we can see: startDate (String) Start date (yyyy-MM-dd HH:mm:ss) But uri https://demo-api.ig.com/gateway/deal/prices/SA.D.AMD.DAILY.IP/MINUTE/2022-11-16 15:00:00/2022-11-16 15:03:00 doesn't work, I've tried many orher formatting including proper UTF-8 encoding of all the special characters but this end up with 400 response... So my question is: how should the correct url look like for historic prices in a given period of time? Thanks K.

Repro steps: 1. place a share deal/order and select 'force open' option 2. try to place another deal/order on the same ticker 3. right hand side panel remembers all the values for size, stop, limit, but not 'force open' - this radiobutton falls back to default 'Net off' option Would it be nice to fix this?