It is a proxy entity that is created on API Gateway and imitates the original API. Thus, it is possible to perform various operations before the messages from the client are transmitted to the original API (Backend API) or before the response of the original API is sent to the client.

API Proxy provides a virtualization point for the original API, resulting in a Policy Enforcement Point (PEP).  



As seen in the figure, the request sent by the client (Step 1) is met by the API Proxy on the API Gateway. API Proxy is the proxy of the API to be accessed on the API Gateway and the Client actually communicates with the API Proxy. The API Proxy becomes a client to the API (Step 2) and receives the responses returned by the API (Step 3) and returns a response to the Client itself (Step 4).

Through the configurations made with API Gateway software, the behavior of the API Proxy is customized, and thus security, traffic management, message conversions, service transport and similar requirements can be managed from a central point.


API Proxy,

  • is an API Proxy for stakeholders working on API Gateway (API Designer, API Developer, API Tester, etc.),
  • is an API for API Consumers (clients),
  • is an API Product when released by API Product Managers by creating documentation, Sandbox environment access, and pricing plans.

The orijinal API is called Backend API since it is behind the API Porxy in this topology.

The Benefits of Using an API Proxy

  • The API provides a contract for methods/endpoints that do a specific job. The main issue with the API should be details such as which methods/endpoints it will contain, what parameters they will take, what work they will do, and what value they will return. This part is called Business Logic in the software development context and it forms the heart of the business. Unfortunately, it is often left to be the least important part of the job in the shadow of the common requirements such as security, logging, traffic management, message validation,  error management and others. Worse still, these types of common requirements are often complex tasks that need to be handled by much more experienced, rare and expensive programmers. API Proxy ensures that all these jobs are handled on the API Gateway software only by configuration, without coding.

By using an API Gateway,

    • these configurations can be made by people who are less experienced and even do not necessarily need to be programmers,
    • the programmers can focus on business logic only,
    • and the amount of code that needs to be developed reduces excessively. 

That means;

    • complex and big projects can be completed successfully,
    • with a huge amount of decrease in the costs of development, maintenance, and management.
  • Putting a layer between the client and the API eliminates the tight coupling of client and the API, allowing the API to be moved to another server or uploaded to multiple servers, to change its address, to hide some methods/endpoints from clients or to customize them to clients. Maintenance work on the API does not affect clients, as the access address will not change for the client.
  • Hiding the real address of the API from clients provides extra security.
  • Even for in-house use, direct access to APIs may not be desired. Instead of accessing the API directly, a developer is asked to access and call the API Proxy, whose behavior is customized by  configuration. In such a scenario, access to the API is behind a Firewall, allowing access only from the allowed API Proxy layer. Thus, access to the original APIs is controlled.
  • With the configuration made on the API Proxy, the behavior of the API can be changed and customized without interfering with the code. In this way, it is possible to do many things without code development. This is especially important for legacy services of which code is not easy, or possible in some scenarious, to modify.
  • It becomes possible to open SOAP services as REST.
  • The same API can be opened to different clients with different settings over different addresses.
  • It is possible to perform monitoring, logging, transformation and similar operations on messages.
  • Services offered by multiple APIs can be opened by combining them over an API Proxy.
  • API Proxy inventory is created and thus API inventory is also created. It can be traced to whom, from which addresses, for what reason and with what restrictions the APIs are published.

Briefly, using API Proxies brings very significant advantages in many aspects such as cost, security, monitoring, development or management.

It often comes to mind that adding a layer between the client and API can degrade performance. This concern is unnecessary, because

  • the additional delay of sending a message to the Backend API by passing through an API Proxy with no additional control added, no configuration (no policy added), and sending the returned response to the client via the same route is usually neglectable,
  • all work outside of this period that is configured with API Proxy and handled by API Gateway is already work that needs to be handled somehow. Therefore, it would not be wrong to think that handling the processing time that will result from these works by the API Gateway, which has been specially developed and optimized for this purpose, and whose performance has been increased to a certain level, will generally be more effective than a software developer's code,
  • API Gateway software provides opportunities to increase performance with facilities such as cache and load distribution,
  • API Gateway software provides the ability to monitor performance. Thus, it gives you the ability to catch delays that can cause API traffic to stall, spanning seconds or perhaps minutes, whether they are caused by the API Gateway or the Backend API,
  • even if there is an unavoidable delay of a few milliseconds in a scenario using API Gateway, this cost should be paid for the benefits provided.

You can refer to the Quick Start page to quickly create and access an API Proxy.