Patent Description:
APIs are well known and used extensively to allow seamless interfaces between software applications running on different devices within a networked system. One such use of APIs can be found in services provided by Pitney Bowes Inc. , the assignee of the present invention, for generating shipping labels. The Pitney Bowes Complete Shipping API provides an API platform that provides shipping services to thousands of end users. At its most basic, the API platform provides a method for Pitney Bowes' partners to make API requests for shipping related information, such as shipping label images, rate quotes, address validation services, etc. The platform itself supports multiple carriers, but the bulk of traffic is centered around providing services for United States Postal Service shipping. Like any other API service of this type, there is a finite limit on the number of API requests that can be responded to during any given second. While modern cloud computing infrastructure, such as, for example, Amazon Web Services (AWS), can conceptually scale up capacity on demand, the specific cryptographic requirements necessary to comply with USPS requirements to generate postal indicia (which is effectively US currency) makes infinite scaling more challenging, especially on a minute by minute basis.

The system limitations for APIs can be defined in two ways: (i) Transactions Per Second (TPS) Limitation, and (ii) API Transaction Spacing. With respect to the TPS Limitation, APIs are limited by a total number of transaction requests per second that the API operation is capable of handling, regardless of whether those requests come in simultaneously or are more evenly spread throughout the one second period. With respect to the API Transaction Spacing, this relates to whether or not the API needs to be protected from simultaneous or near simultaneous transaction requests, and if so, how many milliseconds do the calls need to be spaced out. For example, a given API might be able to easily handle <NUM> evenly spaced transactions during a <NUM> second period, but will experience problems if it received <NUM> simultaneous transactions, even though that is only <NUM>% of the maximum TPS the system can handle.

With respect to TPS Limitations, in many instances, the initiator of most API requests comes from a partner (user of the API) rather than from applications controlled by the provider of the API. For example, suppose Company A has partnered with Company B to allow Company A's customers, using Company A's web based application, to make calls to Company B using Company B's API to make a request for some service from Company B. Such a service could be, for example, paying for, generating, and printing a shipping label for a package to be sent through the mail. Each time a Company A customer clicks the button to print a shipping label, Company A's website calls on Company B to generate the label image and pay for the shipping cost. If one of Company A's customers attempts to generate <NUM>,<NUM> labels in a large batch, Company B does not control whether Company A sends those label requests at a rate of <NUM> per second or <NUM>,<NUM> per second. Accepting too many requests per second runs the risk of slowing down the response time of the Company B API, or even crashing internal systems, both of which could affect the user experience of Company A's customers, as well as all other Company B's API customers.

To help with such issues, technology has been developed, including, for example, gateway technology that can automatically scale and perform load balancing based on the current volume of API traffic passing through the gateway. The issue with respect to such gateway technology is that each instance of the gateway can only track the number of requests it is currently handling. Each gateway has no way of aggregating and counting all the requests coming through all of the currently deployed instances of the gateway. For example, suppose there are ten instances of the gateway function currently serving as the gateway for an API, and customers are calling the API at a rate of <NUM>,<NUM> times every second. The gateway load balancers separate out the requests so that each gateway instance is transmitting <NUM>,<NUM> transactions per second to the underlying API. In this example, because each instance is independent, there is no way to accurately determine that <NUM>,<NUM> requests are coming through to the underlying API.

Other types of technology to help to control the traffic of such requests, often referred to as traffic shaping, have also been developed. Such traffic shaping solutions typically operate to limit the number of transactions per second that would be allowed through to the underlying system architecture in a way that has as little impact on users as possible. In cases where one or more users were sending unexpectedly high traffic volume the goal would be to attempt to slow down responses rather than sending back error responses, as interviews with customers indicated that delayed responses were preferred over error responses. Such known solutions typically center around some variation of the "Leaky Bucket" or its variant "Token Bucket" solutions. The analogy used to describe to the Leaky Bucket traffic shaping solution is an actual physical bucket with a hole drilled in the bottom. Droplets of water represent the API requests being sent to the system, and each user sends water droplets into the bucket at whatever rate they wish. The bucket represents a queue, and the hole in the bottom of the bucket represents the rate at which requests will be allowed through. The Token Bucket solution is simply a variant similar to the Toyota "Kanban" system where tokens are generated at a set rate and each request needs to use one of the generated tokens to be allowed through, but this variant doesn't really change the bucket analogy. The primary issue with these solutions is that individual users could misbehave by sending more requests than the system could handle. Because the Leaky Bucket and Token Bucket algorithms operate on a First in First Out (FIFO) basis, the "bad actors," unintentional or otherwise, can use up most or all of the available bandwidth for a given API and thereby negatively impact the customer experience of all other users.

Thus, as noted above, there are areas that present challenges to existing traffic shaping solutions. Existing traffic shaping solutions do not have any intrinsic control of how many requests individual users can send during any given time period. Using the bucket analogy, any given user can fill the bucket at such a high rate that all other users can't get any water into the bucket at all (imagine a bucket with a small hole under a raging water fall). Some solutions do add in the ability to put arbitrary limits on the TPS of individual users, but these limits did not take current conditions into account. For example, an arbitrary limit might be placed on a given user to keep them from sending more than <NUM> Transactions Per Second. However, during low volume periods (such as the middle of the night) there is no reason to limit a customer to <NUM> TPS if the API is capable of handling <NUM>,<NUM> TPS overall. But the same cannot be said for a peak volume period where the total volume of traffic might be close to or exceeding <NUM>,<NUM> TPS due to many different clients utilizing the API simultaneously.

Further, existing traffic shaping solutions do not dynamically account for current conditions. Existing solutions always apply traffic shaping (meaning that the transactions are slowed down) even when customers are behaving well, and even if there is almost no traffic on the API. For example, if the "hole in the bucket" is configured to allow <NUM> TPS, it will allow one API request to be sent to the API service every <NUM> milliseconds. This means that if <NUM> API calls come in nearly simultaneously, the 5th API request will have <NUM> milliseconds added onto its response time even though only <NUM>% the API bandwidth is being used. Additionally, existing solutions are not able to separate TPS protection from concurrent transaction protection. Transaction Spacing and maximum TPS limits are tied together and cannot be easily separated. While some infrastructure needs to be protected from high numbers of transactions, and some need protection against simultaneous transactions, different applications have different tolerance levels for each scenario. If the stated goal is to have the least impact as possible on the customer experience, automatically combining both types of protection into the same solution means that the traffic shaping solution will have a greater negative impact on customers than is absolutely necessary.

Thus, there exists a need for a traffic shaping solution that is able to calculate the total number of API transactions coming through the pipeline regardless of how many instances of the solution are deployed, and would protect internal API infrastructure from being overwhelmed by high volumes of traffic, but doing so in a way that preserved the highest level of customer experience.

<CIT> describes improvements in network security and traffic management. In an embodiment, a request associated with an identifier (ID) is received. It is determined whether the ID exists in a first membership database (MDB). If the ID exists in the first MDB, the request is serviced subject to a rate limit. If the ID does not exist in the first MDB, it is determined whether the ID exists in a second MDB. If the ID exists in the second MDB, the request is serviced. If the ID does not exist in the second MDB, the request is serviced subject to another rate limit. A response is received. The first and second MDBs can be updated based on the type of received response. In an embodiment, the response is classified as indicative of degraded or typical network performance, and the first and second MDBs are updated accordingly.

<CIT> discloses a method and system to avoid customers experiencing a degradation in service associated with the computing resources provided to customers, in which a main queue and a sideline queue may be used to manage and distribute customer events to service endpoints. Customer events may be placed in a main queue and transmitted, by a delivery host, to a service endpoint. If the delivery host receives a throttle response from the service endpoint, the delivery host may enqueue the customer event in a sideline queue and generate and/or store state information associated with the customer event. The state information may include an interval of time at the expiration of which the customer event may be retransmitted to the service endpoint.

<CIT> deals with the enforcement of Service Level Agreement for the services provided over a client-server network. The invention discloses a method, system and a program product for automatic enforcement of SLAs. This is achieved by automatic metering of requests for service and allocation of resources of the server based on the SLA, current available resources and the needs of the customer.

A first aspect of the present invention provides a method for processing an application programming interface, API, request in accordance with claim <NUM>.

A second aspect of the present invention provides an application programming interface, API, request processing system in accordance with claim <NUM>.

A third aspect of the present invention provides a computer program in accordance with claim <NUM>.

The accompanying drawings illustrate presently preferred embodiments of the invention, and together with the general description given above and the detailed description given below, by way of example serve to explain the invention in more detail. As shown throughout the drawings, like reference numerals designate like or corresponding parts.

The present invention alleviates the above problems by providing a traffic rules engine (TRE) that applies traffic shaping only to customers that are utilizing "more than their fair share" of the currently available bandwidth without allowing them to negatively impact the user experience of other users. What is considered a fair share would be adjustable based on increased capacity of APIs as time goes on and systems are optimized and enhanced. The solution of the present invention takes current API traffic into consideration, allowing one or a few high volume users to utilize most of all available bandwidth as long as other users do not need that bandwidth. This includes dynamically measuring and adjusting which users had traffic shaping applied to them based on the overall traffic during any given second. The solution of the present invention avoids any slowdown of customer API requests unless the maximum allowable TPS limit is near to being reached. Furthermore, the solution of the present invention provides the ability to customize the levels of TPS and concurrent transaction protection on a per API basis.

The TRE of the present invention significantly improves the performance of the multiclient network environment in which it is installed by providing a solution that addresses all of the major issues with the existing traffic shaping solutions based on the Leaky Bucket algorithms in the following ways:.

Therefore, it should now be apparent that the invention substantially achieves all the above aspects and advantages. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

In describing the present invention, reference is made to the drawings, wherein there is seen in <FIG> in block diagram form a system architecture overview of a multiclient networked environment in which the TRE according to an embodiment of the present invention is utilized. The networked environment includes a data center <NUM> operated by a service provider that provides services to clients through API requests made by the clients. The data center <NUM> is coupled to a network <NUM>, such as, for example, the internet. Clients of the service provider communicate with the data center <NUM> using one or more remote devices 16a, 16b, 16c coupled to the network <NUM>. Remote devices 16a, 16b, 16c can be any type of processing device, such as for example a personal computer, laptop, tablet, etc. While only three remote devices 16a, 16b and 16c are illustrated in <FIG>, it should be understood that there can be any number of such devices that can access the data center <NUM>.

Each of the remote devices 16a, 16b or 16c are used by a respective client to request a service from the data center <NUM> via the network <NUM> via an API request. The data center includes a one or more servers <NUM>, <NUM>, that are utilized to process the API request and return a result, to the requesting client device 16a, 16b, 16c for use by the client. Each of the servers <NUM>, <NUM> may be a mainframe or the like that is specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored therein to perform the required functions. Such a computer program may alternatively be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, which are executable by a processing device within each server <NUM>, <NUM>. One of ordinary skill in the art would be familiar with the general components of a server system upon which the method of the present invention may be performed. While <FIG> illustrates two servers, it should be understood that any number of servers can be provided.

Referring now to <FIG>, there is illustrated in block diagram form a functional overview of how the TRE according to an embodiment of the present invention integrates within an API workflow. Each of the modules/functions described in <FIG> can be implemented as hardware, software or a combination of the two operating in one or more of the servers <NUM>, <NUM> illustrated in <FIG>. API requests <NUM> for the API operations <NUM> are received from a remote device 16a, 16b, 16c via the network <NUM> by an API gateway device <NUM>, such as, for example, a gateway provided by Apigee. The API gateway device <NUM> manages all incoming API requests <NUM> to the API operations <NUM>. The API Operations <NUM> could be for example, services for shipping related information, such as generating and providing shipping label images, rate quotes, address validation services, etc. The API gateway device <NUM> sends the API request <NUM> to a TRE Load Balancer device <NUM>, which then routes them to the currently deployed instances of the TRE module <NUM>. As illustrated in <FIG>, there are two concurrently deployed instances of the TRE modules 36a and 36b, but any number of instances may be provided.

To maintain a counter of the total number of requests routed to all of the instances of TRE modules <NUM>, one or more counters <NUM> is used, such as, for example, Redis' technology to manage and iterate counters, but the logic for how to react to those counters is maintained in the TRE module <NUM>. The counters <NUM> can be adjusted up or down at times measured in nanoseconds. A counter <NUM> is created for each operation to track the total number of transactions that have occurred during a <NUM> second period, and additional counters are created on the fly for each client that makes an API request <NUM>. For example, if client ABC and client DEF both make fifty API requests during a <NUM> second period, the counters <NUM> will track that one-hundred transactions have occurred during that second, as well as having a counter for each of the clients that shows a value of fifty each. The nature of the counter <NUM> is that it can track a single set of counters regardless of the number of instances of the TRE modules <NUM> that are deployed. This allows for load balancing of the TRE service without sacrificing the ability to track the total number of requests going to the underlying API Operation <NUM>.

A database <NUM> is utilized to store the limit values (as described below) in case a new TRE module <NUM> instance needs to be deployed or an existing instance needs to be reset. The TRE module <NUM> decides if traffic shaping needs to be applied to an incoming API request, and if the incoming API request will be slowed down, refused, or allowed to pass through to the underlying API operation <NUM> (i.e., is processed via the Normal Lane <NUM> or Penalty Lane <NUM> as described below). The API operation <NUM> will receive the request from either the Normal Lane <NUM> or Penalty Lane <NUM>, and perform the requested service. As noted above, such API services could include services for shipping packages, such as generating and providing shipping label images, rate quotes, address validation services, etc., but could be any underlying API service endpoint.

The TRE module <NUM> punishes bad actors by limiting their allowed number of transactions per second, but only so long as they misbehave. The limitation takes the form of slowing down API responses for that user, or in extreme cases some of the API requests <NUM> will be immediately refused. This prevents a single user from using up all of the available bandwidth, but the system logic allows the TRE module <NUM> to give high volume users more leeway to send more traffic through the system if lower volume users are not taking up the bandwidth themselves. The initial checks on how to handle traffic shaping are aimed at protecting the API Operations <NUM> based on the limiting the maximum TPS sent to an API Operation <NUM>. The TRE module <NUM> stores predefined limits that can be easily be tuned and adjusted via an API call or automated logic.

Referring now to <FIG>, there is illustrated in flowchart form the operation of the TRE <NUM> according to an embodiment of the present invention for the Transaction Per Second protection layer. The processing described herein is performed by each instance of a TRE module <NUM> individually from the other instances. The process starts in step <NUM> where an API request <NUM> is received by one of the TRE modules <NUM> instances from the TRE Load Balancer device <NUM>. In step <NUM>, the TRE module <NUM> first looks to see if the total number of transactions that have occurred during the current second, provided by the counter <NUM>, exceeds a set Throttle Limit. The Throttle Limit is set based on an Operation Limit for a specific API service <NUM>. The Operation Limit is the overall maximum transactions per second ( Max TPS) that are allowed for the specific API service <NUM>. This value is determined based on the service being provided by the API service <NUM>, and can vary for different API services. The Throttle Limit must always be less than the Operation Limit, and the Throttle Limit is preferably set anywhere from <NUM> - <NUM>% of the Operation Limit depending on risk tolerance. The higher it is set the greater the percentage of bandwidth that can be used up before the TRE module <NUM> begins throttling any customer transactions (API requests <NUM>). The purpose behind first checking if the Throttle Limit has been exceeded is to prevent the throttling of any traffic (API requests <NUM>) if there is sufficient bandwidth available (i.e., a low amount of API requests <NUM> coming into the system). This can be considered the "tachometer" for the TRE module <NUM>. Setting the Throttle Limit value defines the point at which the available bandwidth of an operation is considered to be nearing a point where TPS is a concern. The purpose of determining if the Throttle Limit has been exceeded is to determine if the Integrator Limit or Standard Limits (as described below) need to be checked against the current TPS flowing through the TRE module <NUM>.

If in step <NUM> it is determined that the Throttle Limit has not been reached, then in step <NUM> the API request <NUM> is processed via the Normal Lane <NUM>, meaning that it is not queued and not slowed down at all based on customer behavior (however, spacing could still be applied as described with respect to <FIG>, but spacing is not based on customer behavior). If in step <NUM> it is determined that the Throttle Limit has been exceeded, then in step <NUM> the TRE module <NUM> checks to see if the customer making the API request <NUM> has an Integrator Limit that applies to that customer. An Integrator Limit (or Customer Limit) is an optional specific TPS limit allowed for that customer for a specific API service <NUM> (e.g. label creation, address validation, etc.) and can be stored, for example, in database <NUM>. These limits can be set by contractual arrangements, such that a customer that pays more for a service can have a higher Integrator Limit than other customers. If the customer does not have an Integrator Limit set, that customer will be constrained by the Standard Limit. The Standard Limit is the Max TPS allowed for any customer that does not have a specific Integrator Limit, and can be set based on the preference of the TRE module <NUM> operator. Thus, each Integrator Limit is a customer specific value. The Integrator Limit could be set lower than the Standard Limit, but generally the Integrator Limit is used to provide a traffic shaping exception to extremely high volume users to give them more leeway or to fulfill a contractual agreement for a guaranteed number of transactions per second. If the customer has an Integrator Limit set then that will supersede the Standard Limit. During low traffic times, neither the Integrator Limit nor the Standard Limit will have any effect on the processing of an API request <NUM>, because the TRE module <NUM> only cares about this value if the Throttle Limit has been exceeded (yes response in step <NUM>).

If in step <NUM> it is determined that an Integrator Limit exists, then in step <NUM> it is determined if the Integrator Limit has been exceeded. If in step <NUM> it is determined that the Integrator Limit has not been exceeded, then in step <NUM> the API request <NUM> is processed via the Normal Lane <NUM>, meaning that it is not queued and not slowed down at all based on customer behavior (however, spacing could still be applied in as described with respect to <FIG>, but spacing is not based on customer behavior).

If in step <NUM> it is determined than the Integrator Limit has been exceeded, then in step <NUM> the API request is processed via the Penalty Lane <NUM>. The Penalty Lane <NUM> for an API operation follows the standard rules for the Leaky Bucket algorithm, but the difference is that only customers that are exceeding their fair share of bandwidth will ever have their transactions processed through in the Penalty Lane <NUM>. Thus, the API requests <NUM> that are processed via the Penalty Lane <NUM> are placed in a memory queue (the bucket) and released at some predetermined rate as set by the system (the hole in the bottom of the bucket) in a First In First Out (FIFO) manner. Although two or more customers might simultaneously "misbehave" by sending exceedingly high numbers of transactions in a short period, which would allow them to negatively affect the user experience of one another because their API requests would be processed through the Penalty Lane <NUM>, this is considered acceptable because both customers have exceeded the suggested number of transactions per second allowable for the API. The Penalty Lane <NUM> can be configured to have its own spacing or to allow transactions through at any rate, but limits the total number allowed through in a second.

Once the API request <NUM> has been processed in step <NUM> through the Normal Lane <NUM> or in step <NUM> through the Penalty Lane <NUM>, then optionally in step <NUM> the API request <NUM> is sent to an optional spacing process (described below with respect to <FIG>) to provide an additional layer of concurrent transaction protection. The optional spacing process is preferably performed after the initial TPS protection describe above so that spacing can occur after any customers that are sending too many requests have had some of their requests weeded out. Once the spacing process is complete (or if the spacing process is not utilized), then in step <NUM> the API request is sent to the API operation <NUM> to be acted upon. It should be understood that only if the Throttle Limit and the Standard Limit (or the optional Integrator Limit) are exceeded will the API request <NUM> be processed via the Penalty Lane <NUM>. This significantly improves the performance of the multiclient network environment in which the TRE module <NUM> of the present invention is installed as compared to the prior art by providing a solution that segregates the transactions of bad actors from those of other users so that bad actors cannot negatively impact well behaved users; defining bad actors on a second by second basis, preventing any need for engineers or product managers to create a predefined list of problem users; allowing machine learning or other analytics to be applied to the system to provide real time optimizations as needed; and not applying traffic shaping at all until bandwidth availability is an issue during the current second. This significantly improves the performance of the system over the current traffic shaping solutions.

Referring now to <FIG>, there is described the provision of spacing between API requests <NUM> as an optional concurrent transaction protection layer (step <NUM> of <FIG>). This spacing process is preferably placed after the initial TPS protection so that spacing can occur after any customers that are sending too many requests have had some of their requests weeded out. When spacing is applied for reasons other than customer behavior it does mean that individual users can affect the user experience of others, the impact of bad actors is minimized because any overuse of the system has already been addressed by slowing or refusing bad actors' transactions before spacing is applied. This layer of the TRE <NUM> is designed to allow customization of how Traffic Spacing is applied. Rather than simply apply a blanket level of spacing to the API requests <NUM> for a protected API, this layer can apply protection based on API request characteristics. This is because some API operations <NUM> may need to have all API requests <NUM> spaced out evenly, while others may only need spacing if certain criteria are met. For example, a reporting API may easily handle a thousand simultaneous requests that each specify a single transaction, but could experience system issues handling <NUM> simultaneous transactions if each request specifies a large date range and requires a response that includes thousands of individual transactions.

After an API request <NUM> has been processed via the penalty lane (step <NUM> of <FIG>) or the normal lane (step <NUM> of <FIG>), then in step <NUM> the API request <NUM> is checked against a set of spacing rules that are configured specific to the API operation <NUM> to which the API request <NUM> is directed. Such spacing rules could be stored, for example, in the database <NUM>. Each API operation <NUM> can have its own set of rules as well as its own set of spacers. For example, there might be three rules and two spacers for a given API operation <NUM>. Two of the rules, each of which might look for a specific field in the JSON body, header, or query parameter, might apply a first spacer value to an API request <NUM>, while the third rule would apply a second spacer value to an API request <NUM>. The first spacer value might be configured to apply <NUM> milliseconds between each API request <NUM>, while the second spacer value would apply <NUM> milliseconds of spacing. Alternatively, there could simply be a single rule and a single spacer configured so that every API request <NUM> for the specific API operation <NUM> has a spacer value applied. In step <NUM>, it is determined if one or more spacing rules apply to the API request <NUM> for the specific API operation <NUM>. If there are no spacing rules , then in step <NUM> the API request <NUM> is sent to the API operation <NUM> without any spacing being applied. If in step <NUM> it is determined that one or more spacing rules do apply to the API request for the specific API operation <NUM>, then in step <NUM> the spacing value is applied to the API request <NUM> (by applying a delay of the time specified in the applicable rule before sending the API request <NUM> to the API operation), and then in step <NUM> the API request <NUM> is sent to the API operation <NUM>.

In accordance with embodiments of the present invention, the TRE module <NUM> supports the ability to adjust the limits, penalty lane limitations, and "spacers" based on real time analysis rules or machine learning to support the alteration of the system configuration based on the existing load on specific API operations. For example, the Penalty Lane and Throttle Limit could be automatically adjusted upwards during known low traffic periods to allow users to time their high speed batches late at night when other users do not need the system bandwidth. The analogy would be adjusting the speed limit of a freeway depending on the number of cars on the road (which is ok in this case because there is no danger of API packets crashing). For example, suppose the following settings are currently in place: <NUM> TPS Operational Limit; <NUM> TPS Throttle Limit;<NUM> TPS Penalty Lane Throughput limit; <NUM> TPS Standard Limit. With these settings in place, imagine that an API operation <NUM> has only a single developer calling it at a rate of <NUM> TPS for a five minute period. After the first second or two their total TPS would be limited to <NUM> because their transactions would be routed to the Penalty Lane <NUM>. However, an intelligent monitoring system could see this situation and see that the API operation <NUM> itself is capable of handling <NUM> TPS but only <NUM> TPS is actually making it to the API operation <NUM>, even though the single user is sending <NUM> TPS. The TRE <NUM> could temporarily adjust the penalty lane TPS limit to something like <NUM> TPS, thereby allowing all of the user's traffic through without any risk of exceeding the <NUM> TPS overall limit.

The present invention significantly improves the performance of the multiclient network environment in which it is installed by providing a solution that addresses all of the major issues with the existing traffic shaping solutions based on the Leaky Bucket algorithms in the following ways:.

Claim 1:
A method for processing an application programming interface, API, request (<NUM>) for an API operation (<NUM>) made by a customer using a remote device (16a, 16b, 16c) comprising:
receiving (<NUM>), at a processing module (<NUM>), the API request via a network (<NUM>) from the remote device;
determining (<NUM>), by the processing module, if a threshold number of transactions per second for the API operation has been exceeded;
if the threshold number of transactions per second has not been exceeded for the API operation, sending (<NUM>), by the processing module, the API request to the API operation via a first processing path (<NUM>) that does not have a limit for a number of transactions per second that will be sent to the API operation;
if the threshold number of transactions per second has been exceeded for the API operation, determining (<NUM>), by the processing module, if the customer has a customer limit value for a number of API requests per second;
if the customer does have a customer limit value for a number of API requests per second, determining (<NUM>), by the processing module, if the customer limit value for the customer has been exceeded;
if the customer limit value for a number of API requests per second for the customer has not been exceeded, sending (<NUM>), by the processing module, the API request to the API operation via the first processing path;
if the customer limit value for the customer for a number of API requests per second has been exceeded, sending (<NUM>), by the processing module, the API request to the API operation via a second processing path (<NUM>) that is different than the first processing path, the second processing path having a predefined limit for a number of transactions per second that will be sent to the API operation;
if the customer does not have a customer limit value for a number of API requests per second, determining (<NUM>), by the processing module, if a standard limit value for a number of API requests per second has been exceeded;
if the standard limit value for a number of API requests per second has not been exceeded, sending (<NUM>), by the processing module, the API request to the API operation via the first processing path; and
if the standard limit value for a number of API requests per second has been exceeded, sending (<NUM>), by the processing module, the API request to the API operation via the second processing path.