You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Watched bills with changes could be displayed on this schedule while another, less frequent schedule could display the rest of the results, with the scan/query command displaying the results as needed.
in general we track about 180,000 bills
and have an average 3 hour lag between a state publishing any random
update and the system picking it up.
State schedule vary wildly from near real-time to once a day, and the
Timmy the Intern factor in data entry delay from Clerk staff.
And as it relates to public service Pull API calls there is a 1 hour
cache on any specific set of parameters, though 1-2 checks per day is
sufficient for most common identification/update approaches
My argument for not locally caching bills is as follows: The scan command, which does the API queries, is run very infrequently (one to two times a day). It is not a common command to use. The other commands (ignore/watchlist/etc.) operate on the database.json/watchlist, which acts like a cache.
The API documentation says that, within a 1-hour schedule for
search
/searchRaw
, it will serve unchanged cache data (see page 7).The text was updated successfully, but these errors were encountered: