APIs enable communication between different systems and facilitate the integration of applications. Whether retrieving weather data, accessing payment services, or streaming videos - APIs are the backbone of digital services. However, with the increasing use of APIs, challenges in terms of their performance and security also grow. This is where rate limiting and throttling come into play to ensure stable and secure API usage while guaranteeing fair access for all users. What is Rate Limiting? Rate limiting refers to the restriction of the number of requests a user or system is allowed to send to an API within a specific time frame. This is used to distribute resources fairly, prevent abuse, and control server load. For example, a payment provider allows a maximum of 100 API requests per minute per user. If a user attempted to send 200 requests within a minute, the requests exceeding the limit would be blocked. This ensures that no single user excessively burdens or abuses the API. Proven methods for load limitation in APIs: Fixed Window Limiting: A fixed number of requests per time unit is allowed. An API allows a maximum of 1,000 requests per hour. When the limit is reached, further requests are blocked until the next hour. Sliding Window Limiting: The requests are counted within a sliding time window. If an API has a limit of 100 requests per minute, not all requests are reset at a fixed minute, but are continuously recalculated. Token Bucket: Requests are only accepted if enough tokens are available in the bucket. A system can provide 10 tokens per second, and each request consumes a token. When the bucket is empty, users must wait until new tokens accumulate. Leaky Bucket: Requests are processed evenly to prevent load spikes. Instead of 1,000 requests being processed immediately, they are processed gradually so that the system remains stable. What is Throttling? Throttling is a special form of rate limiting where API performance is dynamically adjusted to ensure system stability. Instead of immediately rejecting requests when the limit is reached, throttling ensures that API requests are slowed down or queued. A practical example of throttling is ticket sales for large events, such as concerts or sporting events. When a new ticket sale starts, millions of users simultaneously access the platform. To prevent the system from being overloaded, the platform applies throttling: Users are placed in virtual queues, and their requests are processed gradually. This way, the system remains stable, and the sale proceeds in an orderly manner without the system collapsing. Differences between Rate Limiting and Throttling Both rate limiting and throttling aim to regulate API usage and avoid overload. However, the essential difference lies in how these limitations are implemented. Rate limiting works with fixed upper limits and blocks requests as soon as the set limit is exceeded. This is particularly useful for preventing abuse, for example, by bots that could excessively burden an API. As soon as a user reaches the maximum number of allowed requests, they receive an error message and must wait until the limit is reset. Throttling, on the other hand, does not rely on absolute blocking but slows down the processing of requests or places them in a queue. This allows the system to flexibly react to load peaks without immediately excluding users. While rate limiting sets a hard limit, throttling ensures a dynamic adjustment of load distribution. Both mechanisms have their justification and are combined depending on the use case to make APIs both performant and fairly usable. Why are API Usage Limits Important? APIs are essential components of modern software landscapes and enable communication between different systems. However, without suitable usage limits, they can quickly become a weak point. Rate limiting and throttling are therefore indispensable measures to ensure security, stability, and efficiency. 1. Protection against Abuse and DDoS Attacks Without limits, malicious actors could send countless requests to an API to overload or deliberately disable it. A classic example is a DDoS attack (Distributed Denial of Service), where a server is flooded with requests until it no longer responds. By setting a request limit, for example, 100 requests per minute per user, a system can detect and defend against such attacks early on. 2. Fair Use of Resources Imagine an API provided by a company to retrieve weather data. Without limitations, a single user could send millions of requests and claim the entire server capacity, leaving other users empty-handed. Rate limiting ensures that all users have equal and fair access rights, and no individual monopolizes the system. 3. Prevention of Server Overload APIs have limited capacity - both in terms of computing power and memory consumption. An e-commerce platform, for example, offers an API for product requests. If millions of queries hit the server simultaneously, it could slow down or block the checkout process for real customers. Rate limiting keeps API performance stable and prevents unexpected system failures. 4. Avoid Overloading Backend Systems and Databases Many APIs are closely linked to databases and other backend systems. If an API is used uncontrollably, it can lead to a significant load on the database. An example would be a financial service provider offering an API for transaction requests. If a bot incessantly retrieves account balances, it could slow down the database, delaying real banking transactions. 5. Cost-Efficiency Many APIs use a pay-per-use pricing model, where each request incurs costs. A company using a cloud computing API might unknowingly send thousands of requests per second without limitation - leading to an enormous bill. Limits help avoid such unexpected costs. 6. Better User Experience When an API is overloaded by excessive traffic, load times increase for legitimate users. For example, a streaming platform without rate limiting could stutter due to excessive API requests, resulting in choppy videos and long load times. A limitation ensures consistently high service quality. 7. Protection against Credential Stuffing Cybercriminals use automated attacks to test stolen login credentials from previous data leaks en masse. This is known as credential stuffing. An attacker tries tens of thousands of username and password combinations within minutes. A limit of 5 login attempts per minute could stop this attack early. 8. Prevention of API Scraping Companies invest heavily in protecting their data. Without limits, bots could uncontrollably query an API and extract sensitive information. For example, an API for real estate prices could be exploited by competitors to systematically steal price data and gain unfair market advantages. 9. Protection against Brute-Force Attacks Brute-force attacks aim to guess passwords or API keys through mass trial and error. A well-known example is the attack on online accounts: Without limitation, millions of passwords could be tested per second. A limit that triggers a short lock after several failed attempts effectively protects against such attacks. 10. Detection of Suspicious Activities A sudden, unusual request pattern can be an indication of an attack or abuse. For example, a banking API might notice that an IP address suddenly sends an extremely high number of requests to gain access to account data. Such anomalies can be detected and specifically blocked through limits. 11. Restricting Abuse of API Keys API keys are often the gateway to a system. If compromised, an attacker can send requests unhindered - for example, to retrieve data en masse or perform fraudulent transactions. Rate limiting ensures that even with a stolen key, the damage remains limited by detecting and stopping atypical usage behavior. Best Practices for Using Rate Limiting and Throttling Rate limiting and throttling are essential mechanisms to efficiently control API usage and prevent system overload. They help distribute resources fairly, reduce abuse, and ensure stable performance. API gateways typically offer these functions out of the box as API policies, making them easy to implement and configure. 1. Define Clear Limits It is crucial that users know exactly how many requests they are allowed to send within a specific time frame. For example, a weather data API might have a limit of 1,000 requests per hour, while a finance API sets stricter limits of 100 requests per minute to prevent abuse. These limits should be transparently communicated in the API documentation so that developers can adapt their applications accordingly. 2. Provide Error Messages and Alternatives When users exceed a limit, the API should return clear error messages. A common practice is using the HTTP status code 429 (Too Many Requests), combined with a Retry-After header indicating when requests can be made again. Additionally, API providers can offer alternative solutions such as premium plans with higher limits or delayed processing to accommodate users. 3. Utilize Adaptive Limits Static limits are not always optimal. Adaptive rate limits dynamically adapt to the current server load. For example, a streaming service might allow 5,000 requests per hour under normal conditions but lower the upper limit to 3,000 requests during peak times to avoid server overload. This technique is often combined with machine learning-based traffic analysis to detect malicious requests in real-time. 4. Implement Caching and Load Balancing To reduce API requests, responses can be cached, and requests can be distributed across multiple servers (load balancing). A practical example is a news service frequently asked for the latest headlines. Instead of forwarding each request to the API, a CDN (Content Delivery Network) can provide cached responses for a short time, so repeated requests do not burden the API. 5. Use API Keys and User Authentication To prevent abuse and enable targeted control over usage, APIs should use key-based authentication. For example, a social media API could assign individual API keys to developers, allowing them to set specific limits based on subscription models. Token-based authentication (e.g., OAuth 2.0) can ensure that only authorized users can access sensitive data. Practical Examples of Rate Limiting and Throttling Rate limiting and throttling are essential mechanisms in numerous industries. They ensure reliable API usage and prevent excessive system loads or security risks. 1. Cloud Services: Fairness and Cost Control Large cloud providers use rate limits to ensure that all customers can access resources fairly. For example, a cloud storage service can limit the number of uploads per minute to avoid excessive usage by individual customers. 2. E-Commerce Platforms: Protection against Scraping and Abuse Online marketplaces use throttling mechanisms to restrict automated price queries. Without such limits, competitors or bots could massively retrieve product information to create real-time price comparisons. Additionally, rate limiting protects APIs from DoS attacks, where massive amounts of requests are intentionally made to disrupt the service. 3. Financial Sector: Fraud Prevention and Security Banks and payment service providers use rate limiting to detect fraudulent transactions. For example, a payment provider could limit the number of withdrawals per hour to a certain amount to block suspicious activities. If an account suddenly performs hundreds of transactions in a few minutes, the limit is reached, and the API stops further requests until a manual review takes place. 4. Search Engines: Infrastructure Protection Search engines limit API requests to optimally distribute server resources. Developers using the Search API usually have a daily limit, e.g., 1,000 requests per day for free users. Those needing more must switch to paid plans. This ensures that large companies do not claim the entire search service for themselves and smaller users can also benefit from the API. Conclusion Rate limiting and throttling are essential mechanisms for controlling API usage. They protect systems from abuse, ensure stable performance, and guarantee fair distribution of resources. While rate limiting regulates access through fixed limits, throttling enables flexible load adjustment to avoid overload. Companies benefit from these measures not only through increased security but also through improved user experience and optimized cost control. The implementation of effective API usage limits is, therefore, an essential component of modern API architectures. Through the targeted use of rate limiting strategies and throttling mechanisms, API providers can efficiently protect their services and make them scalable in the long term.

The high level of networking of mobile apps, cloud applications and Software as a Service (SaaS) used in business, industry and the private sector places high demands on services and software systems. Complex and powerful API interfaces from the API Economy are now used to implement business requirements. The central key of the offered services are the versatile functions and information that can be used by the open interfaces. Many of the daily used applications are based on different interconnected services. If one of the interfaces involved fails, the service offered no longer works! To ensure that the functionality, reliability, performance and security of the APIs are met, API testing is a must. For API tests, the APIs (Application Programming Interfaces) are tested directly and within the framework of integration tests. The tests are performed at message level. The incoming data as well as the expected results of the interfaces are tested. The regular and automated execution of the tests during the API lifecycle ensures that the APIs are error-free and stable. Quality assurance is an important component in the provision of highly available APIs.

Anyone involved in the planning, design and development of API interfaces will sooner or later have to deal with the API definition and one of the popular description languages. A good API is characterized above all by positive quality characteristics. First and foremost, this includes clear consistency, the easiest possible usability and a suitable abstraction. The importance of a helpful documentation should be ensured from the beginning and must never be underestimated. As soon as the API is to be made available to other developers, it is imperative to document as detailed and comprehensive an API definition and description as possible. A powerful Web API is only successful if its structure is well represented. Technical specifications such as end points offered, HTTP methods and parameters used, and how requests should look are essential. All these specifications ensure good usability and, if formulated appropriately, also support automatic code generation. The description language used to create an API definition is left to the developer. Here we highlight the most common languages like Open API, Swagger and RAML. Open API Under the leadership of the Linux Foundation, a special working group called the "Open-API Initiative" was founded in 2015. At the same time, Swagger was taken over by SmartBear - the tool manufacturer of the well-known and respected SoapUI. Both steps led to the renaming of Swagger to the Open-API Specification (OAS) under the aspect of remaining manufacturer-neutral. In the meantime 26 members such as Adobe, SAP, PayPal, eBay, Google, MuleSoft and also Microsoft belong to it. The consistent further development takes place on GitHub and opens thereby the participation in the project to any interested party through issues or pull requests. In mid-2017, version 3.0 of Open-API was approved and published. Compared to the previous version 2.0, a clearer structure could be achieved especially on the top level of the hosts and security. Another big step forward was made in supporting the JSON scheme. Based on the formats JSON or YAML 1.2 different languages like Java, JScript, .Net, Ruby, Scala or Gitlab can be used. Also in Open-API the starting points Contract-/API-First or alternatively the program code via Code-First exist. A detailed description of Open API can be found in our practical article Open API Specification. Swagger The Swagger API project was launched by Tony Tam in 2011. In today’s highly networked business world, it is increasingly important to allow distributed applications to communicate with central servers via API interfaces. For a long time, APIs were preferably described using the WSDL (Web Service Description Language). Probably the biggest disadvantage is the technical implementation of REST interfaces. One of the biggest advantages of Swagger, however, is the language-neutral and machine-readable format, which is usually defined with JSON or YAML. In addition, it offers a powerful extension mechanism. Swagger also has the IDL (Interface Definition Language) for simplified programming of RESTful interfaces. In addition, Swagger supports both Code-First and Contract-/API-First development. Various tools such as the core library (swagger-core), the visualization interface (swagger-UI), a powerful editor (swagger-Editor) and the code generator (swagger-Codegen) make it easy to develop and test powerful interfaces. As part of the description Swagger Tooling can be used. Based on the source code, a complete documentation can be generated automatically. A much more detailed description of Swagger can be found in our article Swagger. RAML What started with Swagger as a quasi-standard for REST-based applications has been more clearly structured and extended with the Open-API specification. However, there is no standard for the description of a REST API, but SOAP-based Web services have always been described by WSDL documents. With RAML (RESTful API Modeling Language) another important tool for API First Development is now available. The requirement for a uniform description of REST API’s is not really new. An API definition usually includes the following contents such as entry points, resource paths, GET/PUT methods with parameters, business objects, types and error codes. Mulesoft’s developers summarized the necessity and advantages of the API definition in the modern RAML description language. They benefit greatly from many predecessors such as WADL and Swagger. An API description is provided in YAML file format. This makes it very easy to read due to its simplified notation, on the one hand, and on the other, even complex hierarchies can be represented very well. An accompanying documentation can also be given over several chapters. Query parameters can be defined for individual methods and can also be used as so-called "traits" in other methods. Details and possible applications for RAML can be found in our TECH article RAML. Conclusion The description languages listed here have a solid basis and many followers. Swagger is the quasi-standard for REST-based API definitions due to its wide distribution and tool support. RAML is a technically modern and lightweight description language that provides various tools for API modeling. The Open API Specification is based on Swagger and introduces clearer structures and meaningful extensions and will probably establish itself as the new standard in the long term.

API-Economy: With API products to new sources of revenue The tremendous success of APIs in recent years has opened up completely new perspectives for developers. More and more companies are realizing the immense economic and organizational benefits of an API-based software architecture. The next step was foreseeable: APIs became API products, tailored to the individual needs of customers. For companies, this means concentrating on the essentials. For developers of API products, it means the emergence of a new, lucrative market. API products are digital competence API-Economy, the economic sector that deals with the development and distribution of API products, is based on a simple but captivating insight: Not everyone can know everything. Acquiring the additional skills needed for your own business model takes time, money and resources. Since the development of new business areas usually requires a number of new competences, the effort multiplies with each additional competence - an effort that in many cases does not pay off. The alternative would be to simply purchase the missing competence. This is the moment when APIs come into the picture. From the API to the API product In simple terms, APIs are interfaces that enable software to access specific functionalities of other applications. In other words, the software uses the expertise it has been given through the API without having its own program code describing that expertise. The problem with this is that the API usually provides only one special competence. In order to cope with complex tasks in companies, however, combinations of different competencies are usually required, which must be precisely coordinated with each other. This task is fulfilled by API products, i.e. the combination of different APIs for different parts of the task. The individual APIs must not only fulfil their special tasks, but must also communicate optimally with the other APIs in order to interact smoothly in the interest of the target. Developers of API products have two options to create a custom API product: Either all APIs contained in the product originate from own development or the API product consists of specially coordinated, already existing APIs. In many cases, combinations are also possible: Competences for which third-party APIs already exist are served by these. All others require the development of new APIs. The product then consists of existing and new APIs, which are optimally adapted to each other. There are no limits to special functions In particular, the combination of third-party APIs and self-programmed APIs opens up undreamt-of possibilities for developers to design individual applications for the respective customer. Solutions are conceivable that target API products for internal use within the company or those that are designed as part of the business model for use by corporate customers. In this way, differentiated soft limits can be implemented, such as throttling, in order to limit the number of accesses within a certain period of time. These and other functionalities can be integrated into the API product exactly according to the customer’s individual requirements. When it comes to pricing, the developer has every option open to him - from price per query to graduated prices for different expansion stages and flat solutions. In addition, price models based on special application scenarios are conceivable. Conclusion API products are the answer to the problem of companies generating additional competencies with justifiable effort. For developers, API products represent a virtually inexhaustible new market in which they provide companies with the skills they need through tailored solutions.

The focus on customer needs is of increasing interest to the banking world. Financial institutions agree that there is enormous potential in APIs, the abbreviation for Application Programming Interface. The APIs allow the use and evaluation of data and functions on bank accounts. The opening of core banking functions to third-party providers opens up new possibilities. Why do financial service providers increasingly rely on Open Banking? The financial world is facing a new era, the extent of which cannot yet be realistically estimated. A change of direction that attacks the traditional self-image of banks. Away from the rigid fetter of perseverance, towards new flexibility, which internationally operating market operators and market participants hope for. In fact, the wishes and requirements of customers and their consumer needs are the focus of developments. A perspective that allows financial service providers to position themselves innovatively which definitely represents a new challenge. The compass of the European Union undoubtedly points in the direction of intensifying competition. With the Payment Services Directive II (PSD II), nothing stands in the way of opening up the banking infrastructure and it replaces the voluntary nature in favour of the binding commitment. What are the advantages of Open Banking for the markets and providers? A provider who initiates and partially controls the payment process via API primarily benefits from the acquisition of information. Knowledge about the customer, which goes beyond the necessity of the pure sales or service process. This will result in a set of rules that is more than just the administration of customer data. In the future, those who have control over the information will shape and control the market. The new currency at the financial centers is knowledge of customer behavior. There is no question that nothing is more valuable than information about it, who at what time which product via which medium has bought or statistically would like to buy it. What does Open Banking mean for the customer? With Open Banking, banks give third-party providers the option of accessing customer data and triggering transactions on bank accounts. The customer, in turn, has access to a number of services under one interface. This new type of customer-friendliness has the advantage that all bank transactions can now be handled flexibly and with greater convenience. Several accounts can be managed within one application. For this purpose, third-party providers for payment and financial transactions (FinTech companies) offer apps that can access existing bank details via APIs. Through these API’s comprehensive availability of the bank data is possible for all other providers. For customers, banking and management of external financial data and services will become simpler, more versatile and more innovative. What possibilities do customers have with Open Banking API’s? An app offered by a third party (FinTech) can be used by the bank, the app provider and the customer. In the future, customers will be able to complete all their financial transactions and integrate additional services on a single platform. The configuration of such frontends is largely carried out by the customer himself. For the providers, usability (user-friendliness) is the main focus, while the complex networking of all data determines the development process in the background in order to provide the various services. How can a user interface be structured for the customer in the future? Depending on the bank details and additional services, the platform can be set up under the banner of Personal Finance Management (PFM): Multi-Banking, all bank accounts at a glance Comprehensive functions and transactions become possible Credit cards are included Handling of all payment transactions via accounts and credit cards Integration of additional payment service providers Integration of investment platforms Connection to shop platforms (Amazon, Shopify, etc.) Administration Bitcoin-Wallet and other crypto currencies Through intelligent networking through APIs, all services are connected to each other and are in direct exchange. Banks are transforming themselves into market designers and flexible service providers, opening up new and innovative business fields.

APIs - the revolution for the networked car In addition to home and workplace, the car has been developing into the third living space for some time now. There are few scenarios in which modern man spends more time. Accordingly, many areas of everyday life are gradually being transferred to the car. Only the consistent networking of the car with its environment, as made possible by the use of APIs, makes this expansion of the usage profile in the mobile vehicle possible. The car as a pure means of transport is a thing of the past Telephoning in the car as the only means of networked communication is no longer sufficient for most users. The possibilities of handling professional and private affairs while driving are far too important for modern lifestyles. The topic is so important to drivers that, according to a study by McKinsey Management Consultants in 2015, 37 percent of participants would even accept a change of brand in order to use a well-networked car. The rate of increase is particularly striking: in the previous year 2014, only 20 percent of respondents said so. Automobile manufacturers as API pioneers According to a study by Microsoft, the design departments of automobile manufacturers today occupy a leading position among the developers of API implementations in motor vehicles. The application spectrum lies in all areas of automobile technology. Apps on mobile devices in particular will determine the future of API development. This starts with the purchase, to configure the tailor-made car on the smartphone or tablet in every detail. Car manufacturers assume that these comfortable user environments made possible by APIs will promote brand loyalty and customer retention in particular. The Internet of Things is particularly important in the automobile industry for the consistent use of APIs. The link between manufacturer, dealer and supplier scores particularly well here. This leads to a wide variety of application scenarios. Navigation always up to date An assistance system controlled via an API can keep the digital map material of the navigation system up to date in real time, including any changes in the course of the road, current obstacles caused by construction sites or traffic jams caused by traffic accidents. This allows dynamic route planning based on real-time data. Proactively identify technical problems A number of sensors, which are integrated into relevant components and functional groups, transmit their findings to the manufacturer via API. Detected problems bring twofold benefits: On the one hand, the driver has the chance to prevent the damage that has not yet occurred in advance. On the other hand, the incoming information supports the manufacturer in making design improvements to the vehicle in the event of an accumulation of similar problem messages. Remote control of the car - no problem via APIs The driver has access to numerous functions and information via an app, regardless of whether the current location is in the car or not: Forgot to lock the door? Using the app, the current status can be determined conveniently from the sofa and the lock can be adjusted. Do you need to refuel tomorrow? A glance at the API-controlled fuel gauge allows you to read the current fuel level - and the oil level - at the same time. How far does the residual charge in the battery of the electric car last? The information is immediately available via the app, with an estimate of the possible remaining kilometres. These are just a few examples of networked data communication. Other applications include the networked logbook and information on when the next inspection is due. Services in all areas The range of functions that can be applied via API is constantly growing. Already today, car apps allow the user to locate the nearest parking space or the vehicle parked in a foreign environment. The search for the nearest petrol station is also standard in many vehicles today, as is navigation to special destinations, from gourmet restaurants to ATMs and hospitals. But this is only the beginning. First applications for restaurant reservations or hotel and flight bookings show where the journey is going. APIs as the underlying technology will enable solutions in the future that nobody thinks about today. Conclusion The car is no longer just a means of transport. As an essential living environment, it will support a constantly increasing number of professional and private activities. The factors of safety, location-independent information exchange and real-time communication are of particular importance. The car thus becomes a central control centre for private and professional life.