Stay organized with collections
Save and categorize content based on your preferences.
Request Frequency
Update requests
To prevent server overload and to benefit from optimal protection, the Update
API imposes time intervals for how often a client can send requests to the
Web Risk server to perform URL checks
(hashes.search)
or to update the local database
(threatLists.computeDiff).
The initial request for data must happen at a random interval between 0 and 1
minutes after the client starts or wakes up. Subsequent requests can happen only
after the
minimum wait duration
or
back-off mode
time limit has been observed.
If the minimumWaitDuration field is not set in the
response, clients can update as frequently as they want and send as many
threatListUpdates or fullHashes requests as they want.
If the minimumWaitDuration field is set in the response,
clients cannot update more frequently than the length of the wait duration. For
example, if a fullHashes response contains a minimum wait duration of 1 hour,
the client must not send send any fullHashes requests until that hour passes,
even if the user is visiting a URL whose hash prefix matches the local database.
(Note that clients can update less frequently than the minimum wait duration but
this may negatively affect protection.)
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[],[],null,["# Request Frequency\n=================\n\nUpdate requests\n---------------\n\nTo prevent server overload and to benefit from optimal protection, the Update\nAPI imposes time intervals for how often a client can send requests to the\nWeb Risk server to perform URL checks\n([`hashes.search`](/web-risk/docs/update-api#example-hashessearch))\nor to update the local database\n([`threatLists.computeDiff`](/web-risk/docs/update-api#example-threatlistsComputediff)).\n\nThe initial request for data must happen at a random interval between 0 and 1\nminutes after the client starts or wakes up. Subsequent requests can happen only\nafter the\n[minimum wait duration](/web-risk/docs/request-frequency#minimum_wait_duration)\nor\n[back-off mode](/web-risk/docs/request-frequency#back_off_mode)\ntime limit has been observed.\n\nMinimum wait duration\n---------------------\n\nBoth the\n[hashes.search response](/web-risk/docs/update-api#http_post_response_2)\nand\n[threatLists.computeDiff response](/web-risk/docs/update-api#http_post_response)\nhave a `minimumWaitDuration` field that clients must obey.\n\nIf the `minimumWaitDuration` field **is not set** in the\nresponse, clients can update as frequently as they want and send as many\n`threatListUpdates` or `fullHashes` requests as they want.\n\nIf the `minimumWaitDuration` field **is set** in the response,\nclients cannot update more frequently than the length of the wait duration. For\nexample, if a `fullHashes` response contains a minimum wait duration of 1 hour,\nthe client must not send send any `fullHashes` requests until that hour passes,\neven if the user is visiting a URL whose hash prefix matches the local database.\n(Note that clients can update less frequently than the minimum wait duration but\nthis may negatively affect protection.)\n\nBack-off mode\n-------------\n\nFor the recommended backoff procedure, read our\n[Service Level Agreement](/web-risk/sla)."]]
