It is my understanding that in order to make server side requests to the purecloud API, client credentials as a means of authenticating this request might be a suitable option. Also, I understand that a single set of client credentials can be used to generate at most 10 valid tokens concurrently (the 11th invalidating the 1st), and each token expires after at most 48 hours (as mentioned here: https://developer.mypurecloud.com/forum/t/how-are-rate-limits-enforced/1211/3).
However, if we have a single set of client credentials (effectively a single "user") which is used to generate the token necessary to authenticate API requests from a server, and there are more than 10 instances of a service running, each using the same client credentials to retrieve a token for authentication, then some tokens will be invalidated since the maximum number of valid concurrent tokens for 1 set of credentials is 10.
Is there a way to increase the number of valid concurrent tokens generated by a single client credentials (maybe to ~1000)?
If not, what might be the recommended way to authenticate server side requests to purecloud, when there are multiple instances (>100) instances running the server and making requests concurrently. (For example, we considered creating as many client credentials as instances of the server running, and somehow have each instance use one of the unused credentials, however this adds roadblocks on increasing the number of instances dynamically with rps)
Additionally, is it possible to configure rate limiting per token (increase/decrease as needed)?
If the above is going down the wrong path, please let me know what the recommendation for authenticating server side requests to the purecloud API. I have also looked at implict grant, authorization code grant and saml and those do not seem appropriate for server side requests as documented here: https://developer.mypurecloud.com/api/rest/authorization/).
It seems like you have a pretty good handle on the limits that are in place. They are not configurable.
when there are multiple instances (>100) instances running the server
Can you explain this? What are you doing with a server-side app that has so many instances? I'd like to understand more about what you're doing and why before recommending anything.
We want to be able to create/update purecloud agent accounts based on configuration changes for an "agent" account internal to our system which keeps our internal representation of an agent in-sync with a purecloud agent. This results in, as an example, updating the set of queues that an agent is a member of, in our system, which results in a server side request to update the agent in our system followed by a server-side request to the purecloud API to update the corresponding purecloud agent. (This is also because, the person changing the configurations on the client-side may not have direct access to purecloud, and as such requests from the client (FE/browser) cannot be directly authenticated. This requires server side requests needing to be authenticated.
Because of limitations around a maximum of 5 channels per user and a maximum of 1000 topics to listen to via the Notifications API (If there are more than 5000 queues), and listening on channels via 1 set of client credentials (same issue as described in the original post applies here), we plan on polling for conversation objects via the conversations API to determine when certain conversations have been abandoned in a queue to update the state of our internal business objects (for internal analytics, separate from the purecloud analytics) in real time.
Based on the above, what recommendations might you have on how we can go about implementing for the above two usecases/how we can circumnavigate some of the restrictions?
For the first part, I would suggest abstracting the PureCloud API requests out of your 100+ service instances. Each of your instances can make requests to your PureCloud API service, which will make the API requests. This will eliminate the need for multiple auth tokens.
With regard to notification topics, the long term answer is that we are working on a new additional notification solution that is intended for bulk consumption cases like this. The current notification service is architected for single-user use cases, like the PureCloud UI.
For now, you'll have to work within the notification scale limits. I would suggest evaluating the actual setup in your org; I am skeptical that you have more than 5000 queues. If you do, that's something else I'd like to know why. If you must poll, you are probably better off using the analytics conversation detail query with a short interval and looking through the results for abandoned conversations. If you actually do have 5000+ queues with conversations in them, you're going to hit the API's 300 request/minute rate limiter instantly by polling per conversation.
Thanks for the timely reply Tim, I really appreciate it.
On the suggestion of abstracting the purecloud API requests out into a separate service with < 5 instances might lead to a bottle neck if the RPS is high, since not enough boxes will be provisioned to handle the concurrent request volume. Also, in this case, if the rate limiting thresholds are not configurable, what is the recommendation to avoid* hitting the rate limit in this case, if a single set of credentials is used?
On the >5000 queues, we have a set of internal attributes which map to properties of a call (e.g. issue type, language, country, and a couple others). The cardinality of these attributes is such that, if we wanted to create a queue for every permutation combination of these attributes, the number of queues could be > 5000.
Your recommendation of using the analytics conversation detail query is an option, however, the greater the interval over which we query, the less real time this becomes, if we want to poll less frequently to not hit the rate limit (again being able to increase the rate limit for special cases would be helpful here). Is there an alternative which allows for more real time querying that avoids* hitting the rate limit/limits of the Notifications API?
Sorry, that might have been worded poorly. Given the limitations including; rate limiting, the number of tokens per client credentials, and the limitations in place around the Notifications API, each of which you have mentioned are not configurable, as well as given the usecase involving server side requests to the purecloud API I have described, is there a (standard) recommendation around how a server side service authenticates and interacts with the PureCloud API?
I suppose one viable alternative would be to create 1 set of client credentials per instance of the service running.