Inconsistent PM2.5 readings when using automated API polling from mobile environments?

Hi everyone,
I’ve been working on a small personal project to monitor the real-time air quality in my neighborhood using the PurpleAir API, but I’ve encountered a strange data discrepancy that I can’t quite figure out. I’m currently trying to automate a process that pings my sensor’s /json endpoint and pushes the data to a local dashboard on my phone, but the numbers I’m getting through the script aren’t matching the values displayed on the real-time map.

To help with the automation logic, I’ve been experimenting with a delta mod on my mobile setup to see if I can force the script to run more consistently in the background without being throttled by the OS. However, it seems like when the script execution is handled through this modified environment, I’m seeing intermittent “429 Too Many Requests” errors, even though my polling frequency is well within the recommended guidelines for sensor owners.

Has anyone else noticed issues with API rate-limiting or data truncation when triggering calls through third-party executors or custom mobile scripts? I’m trying to determine if the issue is with how the mobile environment handles the TLS handshake or if there’s an internal buffer on the PurpleAir side that flags these automated requests differently than a standard browser session. I’d really like to avoid losing historical data points during high-activity periods like wildfire season, so if anyone has advice on optimizing mobile script triggers for more stable API ingestion, I’d love to hear it!