We have observed that some of our partners and customers are calling the Security Events endpoint of the Elements API, requesting several years of event data.
This can cause an increased data processing load for the API consumer, and will also affect them in the longer term. Read on for more details.
This is creating an abnormal load on our API, which can be impactful to both WithSecure and our other customers.
Facts
- Older Security Events are never updated, so if you have retrieved them once there is no need to retrieve them again. Retrieving them again incurs bandwidth usage and processing cycles both for you and for WithSecure.
- We have a limitation of 30 days of Security Events per request, although this is not currently enforced. From the documentation on Security Events, we have the following:
persistenceTimestampStart
date-time | Lower bound for persistence timestamp in the returned security events. Minimum allowed value is 2022-08-01T00:00:01Z. The time range between persistenceTimestampStart and persistenceTimestampEnd must be no longer than 30 days. |
persistenceTimestampEnd
date-time | Upper exclusive bound for persistence timestamp in the returned security events.
The time range between persistenceTimestampStart and persistenceTimestampEnd must be no longer than 30 days. |
Recommendations
- Only collect the full range of events once and store them for future use
- Only request a maximum of 30 days of events per request
- If you need to request 90 days of data, you can make 3 requests for 30 days each
Recommended Polling Pattern for Integrations (SIEM, Data Lakes, etc.)
For integrations that continuously ingest Security Events (e.g., SIEM pipelines), we strongly recommend using an incremental polling approach:
- Poll the Security Events endpoint at a regular interval (e.g., every 5–15 minutes).
- In each poll, request only new or updated events since your last successful request by using the persistenceTimestampStart parameter.
- Maintain a checkpoint (e.g., last seen persistenceTimestamp) in your system to ensure continuity between requests.
Example pattern:
Initial fetch:
- Retrieve a historical dataset once (e.g., last 30–90 days, split into 30-day windows).
- Store the latest persistenceTimestamp from the response.
On subsequent polls:
- Use the stored timestamp as persistenceTimestampStart
- Set persistenceTimestampEnd to the current time
- Retrieve only newly available events
Future Changes
We will start enforcing the 30 day limitation per request starting from September 7th 2026.