gateway timeouts / rate limits

Hi, thank you for your query we are investigating this issues.

@jesseconnr My most recent version is here - however it's not smart enough to handle server timeouts, so I haven't gotten much use out of it the last 4 months or so. Trying to update it, but finding time has been tough.
https://github.com/Slaggard/WebrootAPIPowerShell-Scripts

FWIW I don't recommend automating the process, because you'll get false-positives as Webroot randomly grabs the MAC addresses of things like the Sonicwall VPN's virtual adapter, various Windows virtual adapters. VM's also sometimes appear as duplicates based on MAC. Unfortunately I don't know of a dependable method for determining duplicates at this time. I've suggested they add a bios serial number column to their schema, as most manufacturers use that properly.

I have been interacting with the API all day today and yesterday and it is constantly timing out still.

Gavsto wrote:

I have been interacting with the API all day today and yesterday and it is constantly timing out still.

Hi, what requests are timing out for you?

@Gavsto I don't know if they're throttling based on this yet, but make sure you're sending a user-agent string in your headers: JosephRi recently gave me a heads-up that they're requiring that now.

Also, while I've never heard them mention specific rate limits, I wonder if there are some in-place. I've started working with Umbrella's API, and it limits requests for each API key to 5/sec and 14/min. It's worth trying a "Start-Sleep -m 500" into your loop (I'll test that myself next time I think of it).

We are having the same issue here. we have 7k+ end points i think and i can only get 2.7k out.

tried start-sleep etc., no joy 😞

strange this one got marked as answered.

We have potentially found our issue and it is to do with the refresh token change.

Thank you for the post DaDDy ICEPOC. Just for clarity, we've had quite a few discussions with our partners around Refresh Token use. A common thread was around the following issue:

A refresh token can ONLY be used ONCE within the 14 day period and a new Refresh Token is also generated alongside the Access Token. For more information and the authentication flow please refer to the guide https://unityapi.webrootcloudav.com/Docs/en/APIDoc/Guide

Was your issue related to this common problem?

I quite often experience time-outs as well. I do not have any sleep processes set.

Just a rough idea of what I do using API

1. Request token
2. Create site
3. Receive Keycode and Site ID
4. Set admin users

I periodically over the past 4 weeks have been having a number of setups fail. It usually will not create the site at all, sometimes we do not receive the keycode, and periodically it just doesn't set the admin users.

I have been working on a script or process to pull a list of all endpoints that we have registered across 4 GSMs and about 2600 sites. The request makes use of a continuation token, and I run into two issues. One the requests time out or the process through which I am running this request times out.

The only reason I am even trying to retrieve this information is to provide our technicians an indication of how many endpoints have not been seen in a specified time frame.

I too have been told that there are no rate limits and there is more and more data being requested through Unity (which is great to hear).

I am continuously trying to determine a way to handle the time-outs, either on the Webroot side and/or our side.

Kind Regards,
Chris

Since a number of you have raised the rate limit point, yes, there are rate limits, even down to specific call types. These are variable and are not published.

The rationale behind the limits are various, but it’s set high enough for normal Unity users to never encounter it, but low enough to stop attacks or incorrect implementations causing disruption to other users.

We continuously monitor network traffic and keep track of errors and ensure they do not climb above certain levels. We are currently seeing well over 100 million calls a week into Unity. Naturally, there will be times where either the Console or Unity will be busy with too many concurrent calls. Although we keep average error levels down to a minimum, as call volumes get larger, the momentary peaks can become more exaggerated.

Some basic guidance that may help:

1- If you are running automation tools, try running them outside of US time zone busy hours.
2- Build in a routine that will backoff and retry in an exponential way if you encounter 429 or 5xx errors. The error types are listed here in the Unity manual.
3- It’s good practice to create a time stamped log file of any errors you receive from Unity. You can then pinpoint when issues occur and what they are.
4- If you are running Console based routines, allow up to a minute for them to execute. Note that if you have very large implementations, you can run multiple routines.

Happy programming!

This is also an issue we are running into.

We have a list of things we would like to implement with this API starting with automation of integrating the billing with the rest of our services. To start we are just using the API to grab All GSM Site's and Number of Active Endpoint at each site (this is simple enough as it only request the one call to https://unityapi.webrootcloudav.com/service/api/console/gsm/{GSMKey}/sites.

One additional piece of info we need, much like chrisrose, is the ability to see what we consider "dead" endpoints, possibly endpoint taken out of production that "should have" been deactivated but are still active.

This would be based on Endpoint Lastseen property.

The issue is there is very limit number of allowed query parameters in the calls for endpoint info.

For example a great option would be something like a request that allowed us to specify filters to return. As the current implementation requires us to simply pull ALL data from the server (which requires multiple calls to get all the data, then we need to handle the query/filtering of the data ourselves

I.e it would be nice to offer something along the lines of:

https://unityapi.webrootcloudav.com/service/api/status/site/{SiteID}?batchSize=1000&NotSeenSince=2019-02-01T23%3A59%3A00.000Z&AttentionRequired=true

I think this would greatly help reduce the load on your end as well as other users.

Instead of the current solution to make pull data on 10000 endpoint, it would allow us to make one call per site for the data on the 100 endpoints we actually care about. Saving both sides the overhead on processing the info on the other 9,900 endpoints. This should also greatly reduce the number of queries made to the server as well as continuation pages would be much less likely and sub-sequent calls shouldn't be needed.

Hi JRenaudette , I think you may be taking about something slightly different here but firstly take a look at Usage reporting https://unityapi.webrootcloudav.com/Docs/en/APIDoc/APIReference#apiReference-SkyStatus-StatusReporting this already includes functionality to to work out 'active EPs'. Many use this for billing and make the process a lot simpler.