alpacahq
Portfolio History equity value sometimes incorrect temporarily
Describe the bug At 8 PM ET every trading day, the current equity value is supposed to be added to the day-level Portfolio History. A new timestamp and value is indeed added but the value is a duplicate of the previous value, not the current equity value. At some later point, the value gets updated to the correct one but it is incorrect for some amount of time.
To Reproduce Steps to reproduce the behavior:
https://paper-api.alpaca.markets/v2/account/portfolio/history?period=3D&timeframe=1D&intraday_reporting=extended_hours&pnl_reset=per_day- Wait until after 8 PM ET.
- Make the same request as in step 1.
Expected behavior Comparing the before and after responses, there should be a new timestamp and value. The value should be different than the previous value, not the same.
Screenshots At the time of this bug report, it is 2:22 AM ET. The API returns the following:
{
"timestamp": [
1738717200,
1738803600,
1738890000
],
"equity": [
505508.7,
504599.02,
504599.02
],
"profit_loss": [
-1140.52,
-909.68,
0
],
"profit_loss_pct": [
-0.0023,
-0.0018,
0
],
"base_value": 506649.22,
"base_value_asof": "2025-02-03",
"timeframe": "1D"
}
Notice how the last two equity values are the same.
Does this issue happen only on paper trader? Have you observed it live api?
The calculation of end of day balances are computed after the market closes. On Feb 7, daily balances for the Feb 6 market day were computed beginning at around 2:45am, which is why you did not see updates at 2:22am EST.
When publishing the response for the portfolio history API, missing entries are forward filled, and you saw the previous daily balance carried forward from 1738803600 to 1738803600.
This isn't a bug.
If more granular data is required at end of day, consider a smaller interval until the final daily balances are computed and available, e.g. 15min.
Hi @pvigliatore! Sorry, I missed your comment yesterday.
Does this issue happen only on paper trader? Have you observed it live api?
Yes, both paper and live.
The calculation of end of day balances are computed after the market closes. On Feb 7, daily balances for the Feb 6 market day were computed beginning at around 2:45am, which is why you did not see updates at 2:22am EST.
Ah, interesting. Is that the Beginning-of-Day Sync mentioned here? I’m curious why the timestamp is 8 PM ET but the equity value calculation needs to wait until the next day. Couldn’t it be calculated during the End-of-Day Calculation mentioned in the same doc?
When publishing the response for the portfolio history API, missing entries are forward filled, and you saw the previous daily balance carried forward from 1738803600 to 1738803600.
This isn't a bug.
I disagree that this isn’t a bug. I think any historical data points returned by the Portfolio History API should be immutable. If a data point is not ready yet, then it should not be returned. Otherwise, inaccurate values can be returned, which causes confusion.
Can we reopen the issue? To summarize, there’s two issues here:
- Bug: Data point is returned even though the underlying data is not yet available.
- Not ideal but understandable: Data point calculation is delayed until the Beginning-of-Day Sync. Perhaps the calculation could instead happen shortly after extended market close at 8 PM ET or at least during the End-of-Day Calculation at 11:30 PM ET?
I sympathize with your concern.
We agree that forward filling yesterday's closing value is not the most correct response, and are prioritizing the issue accordingly. It may not be addressed immediately because of other initiatives, and also because the issue occurs under specific and limited conditions. Specifically, for daily histories during the between market close and the next market open.
The portfolio history service is not intended for use in trading decisions. The positions or account endpoints are available if you need to know the exact buying power or portfolio value that is considered by the order management system.
An extra note about immutability. Sometimes corporate actions or other data must be retroactively added to our system and therefore it is always possible for prices to be updated in a way that would affect the portfolio history, making the chart mutable.
We agree that forward filling yesterday's closing value is not the most correct response, and are prioritizing the issue accordingly. It may not be addressed immediately because of other initiatives, and also because the issue occurs under specific and limited conditions. Specifically, for daily histories during the between market close and the next market open.
Great, thank you! Shall we reopen the issue for tracking purposes?
The portfolio history service is not intended for use in trading decisions. The positions or account endpoints are available if you need to know the exact buying power or portfolio value that is considered by the order management system.
Right, I’m using the Portfolio History API for reporting purposes only. Still, seeing an incorrect value caused confusion, so I reported this bug to y’all.
An extra note about immutability. Sometimes corporate actions or other data must be retroactively added to our system and therefore it is always possible for prices to be updated in a way that would affect the portfolio history, making the chart mutable.
Hmm I’m curious what kind of data would cause the history to be altered. Shouldn’t everything be settled by the End-of-Day Calculation?
Also, what do you think of my prior question copied below:
Not ideal but understandable: Data point calculation is delayed until the Beginning-of-Day Sync. Perhaps the calculation could instead happen shortly after extended market close at 8 PM ET or at least during the End-of-Day Calculation at 11:30 PM ET?
The development team and product teams are working together to balance expected behaviour with the least disruptive option. If may cause problems with other partners if the API response abruptly stops returning a result for the newly ended session.
Not ideal but understandable: Data point calculation is delayed until the Beginning-of-Day Sync. Perhaps the calculation could instead happen shortly after extended market close at 8 PM ET or at least during the End-of-Day Calculation at 11:30 PM ET?
There are a number of jobs scheduled at the end of day and there are dependencies between them. Improving the performance of these tasks is on the roadmap. At the moment there are ongoing projects to bring new value-adds to end users that are prioritized above performance improvements to EOD processing.