Kaseya Community

VSA REST API Rate Limit

This question is answered

Hello!

We have a Kaseya hosted instance of VSA up and running. I need to populate between eight and 15 custom fields per device (planning for 2,000 devices).

I have the REST API up and working in a test environment (request token, append token to auth header, then a PUT request for api/v1.0/assetmgt/AGENTGUID/customfields/FIELDNAME with the necessary data). 

  1. Is there a rate limit in place for the API that I need to take into account?
  2. We would like a five to ten minute window for these fields, would that be feasible?
  3. I am currently making eight separate requests (one for each field). Is there a way to group these into a single API call?
  4. When I make a request for a bearer token, how long is that token valid for? I see the return specifies an offset in minutes (420 in my case), but that also happens to be my timezone (-7 hours) so I'm thinking that's the real meaning of the offset.

Thank you in advance, really enjoying the community and helpful posts here!

Verified Answer
  • Eric,

    I just completed the updates and tests a short while ago. I updated 27 custom fields with no inter-call delay. Basically called the Update Agent Custom Field Value API as quickly as possible for each item, logging each action. The logs only record to the second, but all 27 completed within 3 seconds. Log started at hh:mm:54 and completed at hh:mm:56. 15 of the updates completed with timestamps of hh:mm:55, which should give a good indication of how quickly the updates can be made. I might be able to trim this a bit if I reduced the logging to failures only Our entire audit of 100+ items now completes and updates VSA in under 12 seconds.

    Hope this helps!

    Glenn

    PS - I ran several more tests - getting an average of 15-16 updates per second pretty consistently - on the internal network but routing to the external interface. These numbers may be reduced slightly for remote updates. I've done some remote API queries to collect client data and while you can "feel" an initial delay, it isn't significant. We'll be testing this internally before publishing it, so I should have more data next week on external performance.



    Added info
    [edited by: gbarnas at 6:46 AM (GMT -7) on Jun 12, 2018]
All Replies
  • I'm updating our Audit tool in the coming week or so to use the API to write the results directly to the custom fields. We populate up to 40 fields with the audit tool - currently by multiple requests from a procedure - get data, update custom field with results, rinse, repeat (39 times). We're doing this daily on 3000 endpoints internally, and all of our MSP clients are doing the same.

    I don't have an answer today, but as soon as the new code is tested, I'll let you know. I'm expecting that something that takes 3-4 minutes to complete will take 20-30 seconds based on the testing I've done so far.

    I don't see a way to populate multiple fields with a single call, though.

    Glenn

  • Thanks for the information Glenn! I'm looking forward to seeing your results, please keep me posted.

    Eric

  • Eric,

    I just completed the updates and tests a short while ago. I updated 27 custom fields with no inter-call delay. Basically called the Update Agent Custom Field Value API as quickly as possible for each item, logging each action. The logs only record to the second, but all 27 completed within 3 seconds. Log started at hh:mm:54 and completed at hh:mm:56. 15 of the updates completed with timestamps of hh:mm:55, which should give a good indication of how quickly the updates can be made. I might be able to trim this a bit if I reduced the logging to failures only Our entire audit of 100+ items now completes and updates VSA in under 12 seconds.

    Hope this helps!

    Glenn

    PS - I ran several more tests - getting an average of 15-16 updates per second pretty consistently - on the internal network but routing to the external interface. These numbers may be reduced slightly for remote updates. I've done some remote API queries to collect client data and while you can "feel" an initial delay, it isn't significant. We'll be testing this internally before publishing it, so I should have more data next week on external performance.



    Added info
    [edited by: gbarnas at 6:46 AM (GMT -7) on Jun 12, 2018]
  • Thanks for the update Glenn. Your results give me confidence that our api calls will work just fine. Thank you for taking the time to reply!

  • Eric - happy to help! We were satisfied enough with the results to update production, and this rolled out to all of our MSP customers last week.

    The next tool to get released is a utility that migrates the agent from one VSA / license to another - will actually use the API to uninstall the agent, then install the new agent and register into the proper machine group. This will be handy when moving from SAAS to On-Prem, or migrating to a different VSA instance.

    Glenn