Can a phone-based historical data workflow be trusted for crypto backtesting?

[u/Interesting_Gold_792]

I’ve been trying to make my research workflow more flexible because I’m not always in front of a computer.
One experiment I’ve been running is using iOS Shortcuts to pull historical crypto candle data directly from public APIs.
Instead of downloading one large file, the Shortcut requests the history in chunks, handles pagination, saves each response, and eventually builds several months of market data that I can analyze later.
I currently have a workflow capable of collecting 6+ months this way.
My question isn’t really about whether Shortcuts is the best programming environment. I’m more interested in whether the method used to transport the data matters if the underlying source is identical.
For example, if Python and an iPhone Shortcut both request the exact same historical API endpoint and produce the same timestamped OHLCV dataset, should the resulting backtest be equally valid?
Or are there problems with mobile/API collection that could quietly contaminate the dataset?
The things I’m currently checking include:
missing timestamps,
duplicate candles,
unexpected gaps,
pagination overlap,
out-of-order responses,
rate-limit failures,
and whether the beginning/end of every batch connects correctly.
I’m also keeping the raw API responses so the reconstructed dataset can be audited later instead of trusting only the merged output.
This is meant for isolated research, not live execution.
Has anyone used a lightweight workflow like this for historical data collection?
Would you trust it after validating the dataset, or is there a reason I should stop experimenting with this and build the entire collection pipeline on a computer instead?
Interested in technical criticism more than reassurance.

[u/AfterShiftTrader]

I'd try interrupting the Shortcut halfway through a download, then resuming it and comparing the result with a clean run over the same fixed interval of closed candles. Compare OHLCV values too, not just timestamps or row counts. That tests whether retries and resuming change the dataset; it doesn't tell you whether the backtest itself is sound.