# Historical API end\_timestamp incorrect

**URL:** <https://community.purpleair.com/t/historical-api-end-timestamp-incorrect/10989>\
**Category:** API\
**Created:** [December 21, 2024, 11:38pm UTC](https://community.purpleair.com/t/historical-api-end-timestamp-incorrect/10989 "2024-12-21T23:38:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![cdaringe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.purpleair.com/cdaringe/32/5997_2.png) [@cdaringe](https://community.purpleair.com/u/cdaringe)\
**Post date:** [December 21, 2024, 11:38pm UTC](https://community.purpleair.com/t/historical-api-end-timestamp-incorrect/10989/1 "2024-12-21T23:38:00Z")

</div>

Hi all!

# Problem

The returned historical API response `end_timestamp` field is returning a much later timestamp than any of the returned data, which seems to be _new/changed/breaking behavior_.

# Example

I make a call with the following form, I get back a bogus `end_timestamp`.

```auto
<base-url>/sensors/<sensor-id>/history/json?&start_timestamp=1731628803&average=60&fields=voc,pm2.5_atm,pm1.0_atm,pm2.5_cf_1,humidity,temperature,pressure'

```

The above `start_timestamp` see in a human friendly form is:

```javascript
new Date(1731628803*1000)
Thu Nov 14 2024 16:00:03 GMT-0800 (Pacific Standard Time)

```

The return payload has the following shape:

```json
{
   # ...snip...
   "end_timestamp": 1747180803
}

```

Made pretty:

```javascript
new Date(1747180803*1000)
Tue May 13 2025 17:00:03 GMT-0700 (Pacific Daylight Time)

```

Yikes–May 2025!

I’ve been running my process to periodically sync data for a couple years, and things just started going haywire ~~last month when another volunteer analyst told me we stopped getting data mid-November.~~ maybe in Apr/May 2024?

My sync process was using this `end_timestamp` as a watermark of when to never request data before. The watermark is getting pushed artificially far into the future!

Can you advise?

---

<div class="post-metadata">

**Author:** ![dwhitemv](https://sea2.discourse-cdn.com/flex020/user_avatar/community.purpleair.com/dwhitemv/32/1508_2.png) [@dwhitemv](https://community.purpleair.com/u/dwhitemv)\
**Post date:** [December 23, 2024, 8:30pm UTC](https://community.purpleair.com/t/historical-api-end-timestamp-incorrect/10989/3 "2024-12-23T20:30:44Z")

</div>

`start_timestamp` and `end_timestamp` are NOT related to the period of record for the sensor. They represent bounds of the submitted query, nothing more.

As per the [API docs for the get-sensor-history call](https://api.purpleair.com/#api-sensors-get-sensor-history) and [this post](https://community.purpleair.com/t/loop-api-calls-for-historical-data/4623), the valid values for `end_timestamp` depend on the requested average time and the maximum amount of data returned per call. The returned `end_timestamp` was the one used in the call. For a 1 hour average you can request up to 180 days of data. The data are returned unordered. `end_timestamp` defaults to `start_timestamp` + the maximum time limit for `average`.

Best not to rely on defaults and provide a `start_timestamp` and `end_timestamp` in your call so you get the data you are expecting.

Along that line, there does not appear to be an API query that provides the period of record for a given sensor. `date_created` should be a safe lower bound – no data could possibly exist before then – but if a sensor has gone offline there is no way to know when the last observation was without fetching the entire history up until current. There doesn’t seem to be a field for indicating when a sensor was archived, if that happened, either.