New limit: concurrent audit query executions

Announcements
1

Description

We will introduce a limit to the maximum number of audit query executions that can run concurrently.

Change Category

API

Change Context

This change ensures stability and improves support for large queries across multiple customers.

Change Impact

To prepare for this change, please ensure that any existing query execution is complete before requesting a new query.

Date of Change

We will enforce this limit on a per-org basis beginning immediately. Pending usage data, we will enforce for all organizations within 60 days.

Impacted APIs

/api/v2/audits/query

References

[AUDIT-1401]

2

What will the new limit be?

3

It appears as though the new limit is 1 audit query at a time.

4

Correct, the limit will be one. You can have the next query start immediately following the last.

5

Is this per user?
Or per Org?

I intend to use audit to synchronize cache. Happy to do them one at a time, but concerned if another software product is also querying audit...

6

And what about the API audits/query/realtime . it's the same thing you will update it ?

7

Hi Matt, this is per Org and you could have your query prepared to wait and start when there's availability. These are not expected to be long running queries so should have a minimal impact.

8

This does not affect the realtime query.

1 Like
9

It would be easier to reduce the number of queries if "serviceName" in the query was a list of services and not just a single service. Currently if I want to get all audits for a day, I have to make 49 queries, 1 for each service, but if there was a bulk option to get a list of services it can be done in 1 api call.

1 Like
10

The capability to query by time is being worked on and should be available within the next couple months. Would this address your issue of querying by each individual service?

11

Do you mean "query by time" or by service? We already have the ability to query over time.

Right now the query body looks like this

{
   "interval": "2025-02-13T05:00:00.000Z/2025-02-14T05:00:00.000Z",,
   "serviceName": "PeoplePermissions",
}

which results in needing to run 49 queries, but what would reduce API calls is

{
   "interval": "2025-02-13T05:00:00.000Z/2025-02-14T05:00:00.000Z",,
   "services": ["PeoplePermissions","LanguageUnderstanding","EmployeeEngagement","Directory","AgentConfig","etc"]
}

to get multiple/all at the same time.

12

What's the rationale here to have this set to 1? Seems to me that we're starting to see rate limits more often these days. Do Genesys look at upscaling their infrastructure to cater for the increase in requests, or is the usual approach to throttle things?

Can this limit be increased on request like some others?

13

Soon, you will be able to query for all events over a period of time without selecting a serviceName so that you will only need to run a single query.

2 Likes
14

Hi Vaun, the rationale is that most customers are not attempting to run multiple concurrent queries for Audits, and this supports quicker querying for all customers. Ensuring a single organization can't take up unnecessary resources. At this time, it is not a limit that can be increased on request. If you find issues, please feel free to share that feedback with me directly.

15

When will it be applied?

Currently, serviceNmae is required.
Is serviceName no longer required?
Also, serviceName can only apply one condition.

image
image937×818 58.1 KB

16

Does the new limit HAVE to be 1 for the entire org? Couldn't it, for example, be 5 concurrent audit queries? Or even 1 using client credentials grant (e.g. automation) plus 2 using other grant type (e.g. interactive user)?

I understand that Genesys are trying to protect their infrastructure from being overloaded, but setting the limit to 1 for an entire org seems fraught to me.

Nick.

1 Like