Genesys Cloud - Developer Community!

 View Only

Sign Up

  • 1.  API usage

    Posted 2 days ago

    Hi team! 

    I have a question about how the API usage is monitored and billed.

    My customer wants to know if a Data Action which mades API request to an API Endpoint of the own organization is unlimited or limited by the number of agents?

    Thanks for your time!!

    Regards! Abril 


    #PlatformAPI

    ------------------------------
    Abril Churin
    Support Engineer II
    ------------------------------


  • 2.  RE: API usage

    Posted 2 days ago
    Edited by Elisson Fernandes 2 days ago
    Hi Abril,
     
    Yes, there is a limit. Is this endpoint from Genesys Cloud itself? If so, the rate limits are usually documented on this page: https://developer.genesys.cloud/organization/organization/limits

    If it’s an external endpoint, then it would fall under fair use, based on the number of users.

    https://help.genesys.cloud/articles/genesys-cloud-fair-use-policy/

    ------------------------------
    Elisson Fernandes
    ------------------------------



  • 3.  RE: API usage

    Posted 2 days ago

    Hi Abril,

    Adding to Elisson's answer, there are actually two different aspects here in Genesys Cloud:

    1. API rate limits

    If the Data Action calls:

    • Genesys Cloud public APIs

    then the request is subject to the documented platform rate limits:

    • org-level
    • OAuth client-level
    • endpoint-level throttling

    as documented in the developer center limits page.

    2. Licensing / fair usage

    Data Actions themselves are not "unlimited".

    Even if the API endpoint belongs to the same organization, usage still consumes:

    • platform resources
    • integration execution capacity
    • API throughput

    and may fall under:

    • fair use policies
    • integration/platform consumption monitoring

    Important point many customers miss

    Calling an internal Genesys API through a Data Action is still:

    • an external HTTPS request from the integration layer perspective

    So:
    Data Action → Genesys API

    still counts as API traffic and can hit:

    • rate limiting
    • throttling
    • concurrency protections

    Another important consideration

    If the customer plans high-frequency loops or real-time polling through Data Actions, this can become problematic quickly.

    For scalable architectures, Genesys generally recommends:

    • event-driven patterns
    • notifications/webhooks
    • caching layers
      instead of continuous API polling via Data Actions.

    My recommendation

    I would validate:

    • expected request volume
    • concurrent agent usage
    • polling frequency
    • whether there are better event-driven alternatives

    before treating the integration as effectively "unlimited."



    ------------------------------
    Gabriel Garcia
    NA
    ------------------------------



  • 4.  RE: API usage

    Posted 2 days ago

    Hi Gabriel!

    Thanks for your answer.

    The customer wants to deploy a data action which will send an API request to an own endpoint in every new interaction and aprox they have 800 concurrent licences.



    ------------------------------
    Abril Churin
    Support Engineer II
    ------------------------------



  • 5.  RE: API usage

    Posted 2 days ago

    Hi Abril,

    In this case, the main concern is probably not the number of licenses itself, but the interaction volume and the request burst pattern.

    If they plan to execute one Data Action for every new interaction and they have around 800 concurrent users/interactions, this can generate a very high number of simultaneous executions depending on peak traffic, retries, transfers, and routing behavior.

    Technically this is a supported pattern, but I would strongly recommend validating the scalability of the endpoint and the overall architecture before production rollout.

    One important thing many teams underestimate is that Data Actions are not a queueing mechanism. If the endpoint becomes slow or unstable, this can start impacting Architect execution time, routing latency, and even the agent experience depending on where the Data Action is being executed.

    For large-scale environments, I usually recommend keeping the endpoint response very fast and using asynchronous/event-driven patterns whenever possible, especially if the integration does not require an immediate synchronous response.

    I would also recommend load testing the scenario before go-live considering the expected peak concurrency.



    ------------------------------
    Gabriel Garcia
    NA
    ------------------------------