AJO - Clarification on Rate Limiting and Throttling Behavior for Custom Actions Across Multiple Journeys | Community
Skip to main content
A
AkshithaPo
Level 2
October 14, 2025
Solved

AJO - Clarification on Rate Limiting and Throttling Behavior for Custom Actions Across Multiple Journeys

  • October 14, 2025
  • 1 reply
  • 366 views

We are integrating an external push notification system with AJO using Custom Actions. The external system has a strict API rate limit of 2,500 requests per second. As per Adobe’s documentation, when throttling is configured, any additional requests beyond the set limit are queued for up to 6 hours.

We would like to get clarification on how this throttling and queuing behavior works in a multi-journey scenario. Specifically, if multiple journeys are using the same custom action and endpoint simultaneously, we need to understand whether the throttling limit is applied per journey or shared across the endpoint. Additionally, if multiple journeys exceed the limit at the same time, how are requests queued and processed, and what happens if the combined queued volume exceeds the 6-hour processing window.

    Best answer by SatheeskannaK

    @akshithapo Throttling works per host and per sandbox. It will not be at the journey level.

    "A capping limit of 300,000 calls over one minute is defined for all custom actions. In addition, the default capping is performed per host and per sandbox. For example, on a sandbox, if you have two endpoints with the same host (eg: https://www.adobe.com/endpoint1 and https://www.adobe.com/endpoint2), the capping will apply for all endpoints under the adobe.com host. “endpoint1” and “endpoint2” will share the same capping configuration and having one endpoint reach the limit will have an impact on the other endpoint."

     

    "Journeys APIs support up to 5,000 event per second but some external systems or API may not have an equivalent throughput. To prevent overloading these systems, you can use the Capping and Throttling APIs to limit the number of events sent per second.

    Every time an API call is performed by journeys, it passes through the API engine. If the limit set in the API is reached, the call is either rejected if you are using the Capping API, or queued for up to 6 hours and processed as soon as possible in the order they were received if you are using the Throttling API.

    For example, let’s say that you have defined a capping or throttling rule of 200 calls per second for your external system. Your system is called by a custom action in 10 different journeys. If one journey receives 300 calls per second, it will use the 200 slots available and discard or queue the 100 remaining slots. Since the maximum rate has exceeded, the other 9 journeys will not have any slot left. This granularity helps to protect the external system from over-loading and crashing.

    IMPORTANT:

    Capping rules are configured at sandbox level, for a specific endpoint (the URL called) but global to all journeys of that sandbox. Capping is available on both data sources and custom actions.
    Throttling rules are configured on production sandboxes only, for a specific endpoint but global to all journeys across all sandboxes. You can have only one throttling configuration per organization. Throttling is only available on custom actions.

    1 reply

    SatheeskannaK
    Community Advisor
    SatheeskannaKCommunity AdvisorAccepted solution
    Community Advisor
    October 14, 2025

    @akshithapo Throttling works per host and per sandbox. It will not be at the journey level.

    "A capping limit of 300,000 calls over one minute is defined for all custom actions. In addition, the default capping is performed per host and per sandbox. For example, on a sandbox, if you have two endpoints with the same host (eg: https://www.adobe.com/endpoint1 and https://www.adobe.com/endpoint2), the capping will apply for all endpoints under the adobe.com host. “endpoint1” and “endpoint2” will share the same capping configuration and having one endpoint reach the limit will have an impact on the other endpoint."

     

    "Journeys APIs support up to 5,000 event per second but some external systems or API may not have an equivalent throughput. To prevent overloading these systems, you can use the Capping and Throttling APIs to limit the number of events sent per second.

    Every time an API call is performed by journeys, it passes through the API engine. If the limit set in the API is reached, the call is either rejected if you are using the Capping API, or queued for up to 6 hours and processed as soon as possible in the order they were received if you are using the Throttling API.

    For example, let’s say that you have defined a capping or throttling rule of 200 calls per second for your external system. Your system is called by a custom action in 10 different journeys. If one journey receives 300 calls per second, it will use the 200 slots available and discard or queue the 100 remaining slots. Since the maximum rate has exceeded, the other 9 journeys will not have any slot left. This granularity helps to protect the external system from over-loading and crashing.

    IMPORTANT:

    Capping rules are configured at sandbox level, for a specific endpoint (the URL called) but global to all journeys of that sandbox. Capping is available on both data sources and custom actions.
    Throttling rules are configured on production sandboxes only, for a specific endpoint but global to all journeys across all sandboxes. You can have only one throttling configuration per organization. Throttling is only available on custom actions.
    Thanks, Sathees
      Terms & ConditionsAccessibility statement

      Loading footer...