We're upgrading the infrastructure behind the Data Export REST API to improve performance and consistency when iterating over exported data. This update changes how a few iterator operations behave, and importantly changes how far back you can pull historic data if your integration falls behind. Please review the summary below and confirm your integration is ready.
Target rollout date: November 30, 2026 for customers who do not use any of the changing features listed below.
January 31, 2027 for all other customers.
Important: Reduced support for historic data pull
Today, if your export session falls behind and exceeds the normal retention window, the API automatically recovers by pulling from a separate, long-retention data store — so historic data is always recoverable, even after a long gap (at the cost of occasionally re-delivering a few duplicate events).
After this update, that automatic recovery is removed. If a session falls behind the retention window, you will receive an error instead, and your cursor will reset to the earliest data still available within that (shorter) window. Data older than that will no longer be retrievable through this iterator.
What this means for you: if your integration relies on being able to catch up on historic data after an extended outage or idle period, you should plan to poll or checkpoint more frequently going forward, and build alerting around the new error response so a gap doesn't go unnoticed. We'll confirm the exact retention window in a follow-up update.
What else is changing
| Operation | Today | After this update |
|---|---|---|
| head | Restarts from the oldest available data, but also switches your session onto a slower data path for the rest of that session. | Restarts from the oldest available data. |
| next | Fetches the next batch forward in time; returns an empty response when you're caught up. | No change. |
| resend | Re-fetches the previous batch; your cursor does not move. | No change. |
| tail | Jumps your cursor to the latest available data. | No change. |
| timestamp | Jumps to the given timestamp and iterates forward. | We're refining this behavior for requests made far from your current position. We'll share full details in a follow-up update before rollout. |
What you should do
- Review how your integration handles gaps or outages. If you've relied on being able to catch up on historic data no matter how long you've been offline, that safety net is going away — build in monitoring so a lapsed session is caught early.
- Update your error-handling to expect an explicit error (instead of a silent, automatic recovery) when a session has fallen behind the retention window, and resume by treating this the same way you would a head call — understanding that you'll only get data from the current window forward.
- If you use head as a routine way to reset your position, no action is needed — you'll simply see more consistent performance going forward.
- If you use timestamp seeks, no immediate action is needed; we'll follow up with specifics before this change ships.
Timeline
- November 30, 2026: rollout for customers who do not use any of the changing features described in this notice. No action is needed from you if this applies to you.
- January 31, 2027: rollout for all other customers, including anyone who uses head, timestamp, historic data pull beyond the retention window, or multiple iterators per event type.
Questions?
Reach out to your Netskope CSM/TAM or Netskope support.
