Verity stores information for processed request URLs in the Verity database. Data stored includes:
...
If a request for a processed page URL is received, Verity recreates a JSON response based on the stored data (unless the ignoreCache flag is explicitly set for a page analysis request).
Time to Live (TTL) for Verity Data
JSON response data is maintained by Verity for a time-to-live (TTL) period. There are different TTL periods for Page, Video, Image, and Text content.
Pages are further analysed to differentiate between website home pages and all other pages on the site (as website home pages typically update frequently). For example, https://www.latimes.com/ (the home page of the Los Angeles Times) updates frequently, so Verity assigns a TTL of 30 minutes. The page https://www.latimes.com/travel/list/la-best-dog-friendly-hikes-trails-beaches-parks is unlikely to be updated frequently, so Verity assigns a longer TTL of 30 days.
Verity considers a home page to be a web page accessed at either:
<website URL>/
<website URL>/index.html
Content Type | Default TTL | |
|---|---|---|
Website home page | 30 minutes | |
All other pages | 30 days | |
360 days | ||
14 days | ||
30 days | ||
Every Verity response includes a processedAt field and expiresAt fields, indicating the date and time that classification data was generated and will expire from Verity storage:
| Code Block |
|---|
"processedAt": "2021-05-25T17:57:03.690Z" "expiresAt": " |
...
2021- |
...
06- |
...
24T17: |
...
57: |
...
03. |
...
690Z" |
Time to Live (TTL) for Verity Data
GumGum saves GumGum backs up Verity page and video analysis classification data for 11 months. The page, image, and video metadata is backed up for 180 days.
Client Cache TTL Configuration
GumGum expects clients to store Verity classification result data in their own environment. GumGum recommends that clients configure a TTL of at most 30 days for their cached classification data. Beyond the configured TTL period, updated classifications can be requested from the Verity API.
...