Jump to content

Recommended Posts

When requesting price bar history, the expected response has an array of price bars and the (non-finalized) price bar data for the current period (i.e, the period that has not yet completed).

I encountered the bug in the response of the GetPriceBarsAfterDate URL, specifically in the non-finalized-price-bar data called "PartialPriceBar".

By the way, I did not test the other types of history-request-URL-templates.

Anyhow, in a specific case, the PartialPriceBar returns null by error.

The problem in the API code seems to lie in the relationship between The start date and The maximum number of price-bars allowed per GET request.

Let me detail the buggy behaviour with the URL in question.


If I were to request history that fits the max number of price-bars allowed per GET, the response is flawless. Default max value seems to be 4000, even though the GCAPI references 1000 in the docs.

But, any history request that goes back further than the initial 4000-price-bar history, the PartialPriceBar variable does not get defined, and returns null in the response.

The PriceBars array returns properly, albeit with the default maxResults cap, as expected... 4000 price bars starting from the requested date.

In my case, using the 1-Minute Interval, 4000 price bars is roughly 3 days. So, If I were to request history dating earlier than last 3 days, I would get PartialPriceBar null.

Please let me know if you are able to recreate the bug.

In case you do, will the PartialPriceBar bug be fixed, as this feature is really handy and saves from additional GET work-arounds.


Best Regards to the Moderator and the API team.


Share this post

Link to post


Many thanks for the detailed and clear report. I see the same results that you are getting. 

I'll discuss with the API team and reply to you when I have an answer.

Kind Regards, PM

Share this post

Link to post


We don't consider this a bug due to the purpose this function was designed to fill.

When the start date is greater than the maximum 4000 bars then there will be bars missing/dropped between the 4000th bar returned and the current partial bar that is forming, hence it makes no sense to return the partial bar in this case.

For example, take the case when the start date is such that it is exactly 5000 bars in the past. The call will return the 5000, 4999, ..., 1001 complete bars (4000 in total). The 1000 through to 1 complete bars is dropped, so it would be bizarre to then supply the current partial bar given that there is a 1000 bar gap between the current partial and the 1001 returned complete bar.

If you use GetLatestPriceBars you can retrieve the most recent X bars that you specify in the call plus the current partial. Presumably that is what you are looking to do?

Kind Regards, PM


Share this post

Link to post

Your logic is superior, in which case, the null return for partial bar serves as an OFFICIAL security measure.

Even though additionally receiving the partial bar as reference with a single request is handy, the bigger concern is the logic consistency of the server response.

But your reply has cleared that out. There are no server-side mistakes.

This makes things easier on my end as I can remove additional safeguards

Thanks for your reply,

best regards

Share this post

Link to post

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