How to get the time of the last trigger poll?

The most common, and recommended, approach is to implement your endpoint and/or configure your polling API request such that you return a paginated list of objects in reverse chronological order. Include enough data in this response, or result page, to include any new data/events since the last poll - anywhere from 5 to 15 minutes depending on the user’s Zapier subscription plan. Queues can get backed up, so adding in buffer there is a really good idea so users don’t miss data. 

Including all data since the end of time is not recommended for a normal Zap polling trigger (Supporting the still-in-beta-at-the-time-of-this-writing Transfer feature is a different answer). Zapier will only grab the top of the result set anyway, the latest ~100 objects in the array. 

Include enough data in this response, or result page, to include any new data/events since the last poll - anywhere from 5 to 15 minutes depending on the user’s Zapier subscription plan.

My point was that if we had a way to obtain the actual time of the last poll we could make this more precise and not have to figure out the user’s Zapier subscription plan (which I doubt we have access to anyway). 

Including all data since the end of time is not recommended for a normal Zap polling trigger

That was an exaggeration on my part.  I wouldn’t actually do that, though in theory that’s really the only way to ensure that you get all the data since the user’s Zap’s last poll.  I guess that wouldn’t really work in practice, anyway if, as you say, Zapier only grabs the latest ~100 items.

I should also point out that to have precise control, and the most efficient implementation, rest hooks are a superior option to build triggers.

I should also point out that to have precise control, and the most efficient implementation, rest hooks are a superior option to build triggers.

Indeed, but unfortunately I don’t have that option right now. 

@Zane  Is there a way we can know the Zap User’s subscription plan to identify the polling time in run time?

@venkatesh, no, subscription info is not surfaced in the bundle. You could probably derive that from your API logs, but I feel like trying to implement a solution for those specifics is setting your integration up to be brittle.