Daniel_Grosso | 2020-01-13 10:53:16 UTC | #1
Greetings,
Although we understand the issues that led you to implement the “api fair usage” policy we would like to ask you to review this policy based on the following arguments.
When we first started integrating PureCloud with our client’s custom unified front-end this policy was not in place and the Javascript Embeddable Framework was only released 8 months after we started working on this.
We now have a widget that implements the core CTI functionalities using the Js SDK as this was the only way to go 2 years ago. This widget is fully integrated with our client’s unified front-end and keeps both the CRM solution and PureCloud perfectly aligned. Migrating this to Javascript Embeddable Framework to save api invocations might be very cumbersome or even impossible taking into account the level of integration we’ve develop so far.
Furthermore, our client wants to move with us as Partners into adding message channels to their solution using PureCloud. These channels are far more verbose and the “api fair usage policy” might be a blocking issue for us.
Given this, could there be an exception procedure? On our side, we would compromise to use an OAuth client exclusively for our custom widget and this client would be exempt of usage billing.
It could be a written agreement were you could audit this client´s activity every time you want to. We could even submit our code for validation as we would do if using the Embeddable Framework.
Thank you in advance.
Regards, Daniel
tim.smith | 2020-01-13 18:13:38 UTC | #2
What specifically are you doing with the API that's causing you to exceed the allowances? A well-behaved app, even one implementing CTI functionality, generally won't come close to the allowances. For a PureCloud 3 licensed user, that's 140,000 per month or 5,600 per day if there are 25 work days in the month.
The API Usage View will give you a breakdown of what API requests your apps are making. If you can share that breakdown here, I can take a look and try to suggest some things you could do to consume the API more effectively based on the usage patterns.
Daniel_Grosso | 2020-01-17 14:33:57 UTC | #3
Hello Tim.
At the moment, out CTI widget's Oauth Client is not overusing.
However, once we open message channels agents will chat with users and this will generate more invocations.
On the other hand, the number of agents will always be the bottleneck of interactions and, as u said, there will be 5.600 invocations per day, per agent.
We introduced this topic to understand if this exemption could make sense to you in case we end up overusing due to chat messaging integration.
Thank u for anwering. Regards, Daniel
tim.smith | 2020-01-17 23:23:59 UTC | #4
Daniel_Grosso, post:3, topic:6856
However, once we open message channels agents will chat with users and this will generate more invocations.
I wouldn't expect that to be an issue unless your app is already making a lot of requests unrelated to conversations for some reason.
A little math to explain my position: If an agent works for 8 hours and handles a new message every 5 minutes, that's 96 message conversations per day. I'd expect each conversation to make an API request to answer, end, wrap up, and a few to interact with the media. At a minimum, let's say that would take 6 API requests. That's only 576 requests per day. If we estimate them to handle double the volume of messages and also make twice as many API requests per conversation, that's still only 2304 API requests per day. That would be a very busy agent and still leaves ample usage for overhead for presence changes, loading the user's information, etc.
To discuss when you'll hit the limit, if they pull 16 hour shifts and work every week day for a month handling a conversation every 2.5 minutes, then you'll just be a little over the free limit for the conversation activity, and then add on some for overhead. That use case seems rather unlikely, so if you're hitting or approaching the free tier limits for a user, your app is either doing something we haven't discussed or is very inefficient like polling for conversation or presence data.
Don't get me wrong though. I'm not saying that I know you won't go over the limits. I'm saying that without information to explain how your app differs from a typical use case, I don't have any reason to think you'll exceed the limits just because you're using messaging.
Daniel_Grosso | 2020-01-20 14:35:21 UTC | #5
Hello Tim.
Thank u for ur math.
We did not implement the message channel in our widget yet. This is just us making exercises to prevent overusage. Let me just add a few comments:
I'd expect each conversation to make an API request to answer, end, wrap up, and a few to interact with the media. At a minimum, let's say that would take 6 API requests
If it's a webchat or whatsapp, for instance, I'll need to invocate an api for each "communication" of the conversation (if I understood correclty). If we want to support "typing..." it's an api call as soon as the agent presses a key. Am I missing somehing?
polling for conversation or presence data
We are using notifications everytime it's possible :slight_smile:
Thank u again.
Regards, Daniel
Becky_Powell | 2020-01-23 18:51:39 UTC | #6
Hi there Daniel,
Thank you for your question! I understand your concern that messaging channel utilization might cause your client to exceed their fair usage allocation and incur overage charges as a result.
First, let me assure you that our Fair Usage policy was designed to enable cost-free API access for nearly all use cases. We do not expect it to adversely impact organizations using well-formed applications to responsibly consume our APIs, whose usage is in proportion to their number of billable users.
As I understand it, your use case might be an outlier - one that I would like to explore further. While we do not currently offer exceptions to the Fair Usage policy, we are fully open to calibrating this policy in order to minimize impact to those orgs who are "playing by the rules."
Daniel, may I email you directly to continue the conversation?
Kind regards, Becky Powell Principal Product Manager, Genesys Cloud Open Platform
Daniel_Grosso | 2020-01-23 19:31:42 UTC | #7
Hello Becky.
Sure.
Thank u.
Regards, Daniel
system | 2020-02-23 19:31:46 UTC | #8
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 6856