1. leader badge
    We have been using Apigee mostly for proxy FGIs. We also use its security features as well as traffic control features.The developer portal is very useful to customers.
  2. leader badge
    The ease of use of the solution is excellent.This solution is very flexible, and it's very compatible with the other Azure products.
  3. Find out what your peers are saying about Google, Microsoft, MuleSoft and others in API Management. Updated: March 2021.
    474,857 professionals have used our research since 2012.
  4. leader badge
    The solution has been very stable.The most valuable feature is the scalability.
  5. leader badge
    The functionalities on offer are very good.The solution offers a pretty good SLA.
  6. leader badge
    One of the most valuable features is the option to have all integration patterns constantly updated in one platform. That is the main strength I see in using SEEBURGER Business Integration Suite (BIS). It means I can use a very old-fashioned pattern, combined with a very modern pattern. There are no limitations in terms of combining components because all the components simply fit together.
  7. This solution is a little bit faster, easier to use, and has better integration than the other solutions I have experienced. Its open-source features are very good, especially for your production work.
  8. report
    Use our free recommendation engine to learn which API Management solutions are best for your needs.
    474,857 professionals have used our research since 2012.
  9. The mobile access gateway (MAG) is tremendous. We loved the portal part the most, which had monetization and showed how people were using the stuff. It is a good product as a whole and has a lot of microservices and granular features.
  10. Its security feature is the most valuable because it is mainly a security solution. It has easy authentication and authorization, and its integration is also useful.

Advice From The Community

Read answers to top API Management questions. 474,857 professionals have gotten help from our community of experts.
I'm Financial Technology Solution Consultant in a large company. What is the role of ESB/ API Managers in a digital banking environment?
author avatarPaul Perez
Real User

ESB and API are really different entities. If you read about a kind of competition between both products, there is a misunderstanding. 

API is used to expose your services, checks the access rights, security, invoicing, etc.

ESB on the other side, provide new services by aggregating existing applications and resources. 

Mixing roles creates great difficulties since API are not made to create new processes and ESB is weak when managing accesses.

Another point, API products are often linked to HTTP and don't manage service access through FTP, message which is useful when you do integration projects.

In the bank, ESB puts together, new and legacy resources such As the mainframe, to create new business processes. The API is a convenient way to access to that service.

I hope it is useful.

Feel free to contact me for more detail

author avatarRohit SAHNI

The industry framework has changed rapidly. Instead of a strong core and multiple interfaces mostly hardcoded with channels, banks are moving to a light and flexible product processor with APIs that can be consumed by various partners in the fintech echo systems. API managers are going to be an integral part of next-gen banking as they will own revenue generation and building a network of opportunities for the banks through integrations and partnerships to help the bank become a lifestyle bank rather than a traditional bank which will loose to the competition to the challenger banks. 

Can you explain the differences between API Gateways and ESBs? What considerations are there for a business choose one over the other?
author avatarArchana Bhat

ESB is enterprise service bus primarily to have an architecture where many systems can integrated with each other seamlessly, which means that there is away to just hookup any system be it legacy with the plugins that is provided by the products, this avoids point-to-point connections.
The primary duties of an ESB are:

1.Route messages between services
2.Monitor and control routing of message exchange between services
3.Resolve contention between communicating service components
4.Control deployment and versioning of services
5.Marshal use of redundant services
6.Provide commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service.

API Gateway:

API Gateway is the main part of API management. We all know how and what APIs are and what the are used for. These can be small chunks of services or a large set of service having many operations, with APIs we do computation or some logic required to satisfy the incoming request, but these services when used by external users called consumers we need to bring in some kind of system which can manage the requests and response for that consumer.

For example, a consumer is looking for some service in a JSON format and gives the details on a different like firstName as FName etc. For the same if we change the API itself it would go redundant for another consumer who needs it in different way. Also, the API provider would want to see the traffic make sure there is a regulation on the traffic that comes in, change for the requests that are made or see the trend of each call made or check on the TPS,Not only that, can have a way to display the services that are available to be consumed.

API gateway is the answer to all these in addition to it gives a way to do the below:
Security policy enforcement
Traffic Management policies
Load balancing
Dependency resolution
Cache management

For a business to choose between the both is the need of what kind of service is required, below set of questions might help to decide the same:

1. Is the purpose to provide a service to be consumed? - API Gateway
2. Is the purpose to integrate two different systems which cannot otherwise talk to each other - ESB
3.Is the purpose to do aggregations and mediation which involves logic - ESB
4. Is the purpose only to manage the incoming service request and do basic validation, security, threat protection,authentication? - API gateway
5. Is the purpose to provide a layer on top of your underlying API services? - API gateway

author avatarRobert Solomons
Real User

Centralization of integration and the mediation of payloads are the main reasons why many organizations with Enterprise Resource Planning applications decided on an ESB "Enterprise Service Bus" for their organizations. With a multitude of connections protocols like JDBC, SFTP, JMS, REST, SOAP, and HTTPS there is not an application that some of these ESB's are not able to connect to. It has the ease of connectivity and the ability to handle the transformation of any data structure regardless of the data formats. An example of this would be to connect to APP 1 using SFTP to pick a file with CSV content and then transforming the CSV content to JSON content based on specific data mapping rules and forwarding the data to APP 2 using REST. Message persistence, Message Queening, Guaranteed Delivery are some of the other abilities. Asynchronous message processing is preferred over Synchronous message processing.

Most of the requirement for API's stems from the business wanting APPS for customers, simple integration with vendors and HR departments wanting apps to communicate to their employees. All this has to be achieved with agility, speed of execution, and is key to API calls which is why mapping of deep structured data to another data format is not advisable.
API management would be best suited in an organization with a SaaS 1st approach since most SaaS services have out of the box APIs. The key to the success of APIs is its ability to exchange data near real-time. Synchronous ( request-response ) exchange of data without data mediation is best suited for APIs.

In conclusion, API's is quick and easy away to consume data. While there is a need for an ERP solution it would make sense to have a native ESB and an API tool to call the backend without any data mediation.
A smaller organization who opt for SaaS is where API management is best suited.

author avatarDeepakMishra


An API gateway is an API management tool that sits between a client and a collection of backend services. An API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.


An Enterprise Service Bus (ESB) is fundamentally an architecture. It is a set of rules and principles for integrating numerous applications together over a bus-like infrastructure. ... This decouples systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus.

An ESB is a centralized middleware platform that is used to integrate various enterprise systems and applications. ESBs replace the need for point-to-point communication, which is highly complex and not easily scalable.

Which is the Right Choice for Business?

Both API management solutions and ESBs have a common purpose: closer integration between various systems, applications, and data. However, the similarities stop there. In general, API gateways are more agile and flexible, making them better suited for the modern enterprise IT landscape.

Going with an ESB is probably the best route for your company if:

Many of your systems and applications remain on-premises.

You’re mainly concerned with your internal systems, not external third-party integrations.

You prefer a more logical, “exposure-centric” model.

Using an API manager is likely the better choice for your company if:

You need access to features and functionality not available with ESBs.

You want a more flexible solution that is better suited for e.g. microservices architectures.

You prefer a more agile, “consumption-centric” model.


An API Gateway is a proxy provided for the client. The Gateway gives the client a consistent interface regardless of any changes within the internal system. It allows the internal system to change without affecting the client. 
The API Gateway can also provide consistent cross-cutting concerns such as security logging, reporting and API analytics.

An ESB (Enterprise Service Bus) provides a means for service-to-service communication. With this technique, services do not need to communicate with each other, reducing coupling. 

API management tools often have additional features and capabilities that are not present with an ESB.

API management is more flexible and optimized for newer tech developments such as microservices, whereas ESBs are not.

API management solutions are typically consumption-based, while ESBs have an exposure-based model.

ESB is traditional middleware used in SOA solutions for routing, message transformation, protocol bridging, among other things. A new category of middleware solutions called API Gateway are now offered by several vendors. These solutions are commonly described as the central point to access the REST and SOAP services offered publicly by an organization. However, API Gateway solutions seem to offer a subset of typical ESB features.

Today, the Service Mesh pattern has become popular for microservices. A Service Mesh implementation can provide both an API Gateway and service-to-service communication, along with load balancing, security and many other features.

author avatarBalu Sosale
Real User

An API gateway is something that typically acts as a proxy for your web services and provides interesting value, such as: logging, making SOAP services callable like REST services, debugging help, tracing, etc... Because the API gateway is a sitting between the consumer and your services, it can easily capture traffic and do these sorts of things

An Enterprise Service Bus (like nServiceBus) is designed to sit on top of a messaging protocol (like RabbitMQ) to give it functionality that does not come with (or functionality that is difficult to implement) the basic messaging or pub-sub, for example: Database stored durable messages, retry logic, listener encapsulation, easier ways to subscribe to messages, and sagas. You can use the messaging protocol without using an ESB but not the other way around. For example, you can use RabbitMQ without using nServiceBus.

author avatarSubramanian Ananthakrishnan

An API gateway typically sits in the topmost layer of the northbound to accept all API requests coming in from Applications whether it be channels, third party trusted or non trusted servers. The API gateway has few key primary responsibilities such as :

* Authentication of the API request using PSK or tokens
* Throttling of the requests based on assigned quota or overall traffic handling capacity of the underlying application layers
* API registry management with structure interchangeability (XML to JSON to WSDL etc) support using Swagger
* Sandboxing of API.

Basically it would enable anything to do with the service API in its own form.

Sometimes it's also configured for advanced functions such as API Monetization, where the APIs are rated on a tariff and the registered API partners are invoiced for the usage..

An ESB sits South of API GW and has its own set of functions (although there are no standards specified) such as:
* Composition of the service API itself. i.e exposing a composite service API by combining or transforming multiple atomic service APIs from the underlying registered services
* Transformation of API (converting from one protocol to other or one structure to another)
* Routing of the API in one to one OR one to many forms
* Orchestration of the flow of services using some form of workflow implementation such as BPM
* And finally, enabling the publish and subscribe of these composite and atomic service APIs

In the microservices world as well, the ESB has a big role to play, unlike many theories that think otherwise. A layer that needs to organize all those millions of microservices getting created and enabling a meaningful composite structure for the external world to consume.. someone to maintain a registry so that duplicate development of a service is avoided within the same organization. Manageability of microservices.

author avatarAravindKashyap

The major difference is that API gateway exposes a set of services to consume. On the other hand, ESB s gives two-way relationships, so both service providers and consumers actively participate in terms of communication. Unlike API gateway, ESB allows the computation entity to be service as well as the consumer on-fly where gateways restrict the setup to have a single behavior.

An API Gateway is a proxy provided for the client. The Gateway gives the client a consistent interface regardless of any changes within the internal system. It allows the internal system to change without affecting the client. The API Gateway can also provide consistent cross-cutting concerns such as security logging, reporting and API analytics.

An ESB (Enterprise Service Bus) provides a means for service-to-service communication. With this technique, services do not need to communicate with each other, reducing coupling. ESBs often use guaranteed messaging for inter-service communication.

author avatarRao Nanduri

API Gateway is used for managing the APIs (like securing, publishing, subscribing etc for end-to-end management of APIs)
ESB is Enterprise Service Bus - helpful in integrating multiple applications in different format through message transformation, routing etc.

How are API gateways used in API management? What are the benefits of using API gateways?
author avatarJun Hwang
Real User

Usage spectrum of API G/W is quite broad so that the questions are: I would say it totally depend on what the feature you're looking for.
First of all, you need to understand what the microservices means and what it's stemmed from in the history of the evolution in software architecture. Then, you'd understand the API gateway as a design pattern. Other than that, I totally agree with Steven's opinion below.

author avatarOmar Madaeen

API gateway is an API management tool that sits between a client and a collection of backend services.

An API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.

Most enterprise APIs are deployed via API gateways. It’s common for API gateways to handle common tasks that are used across a system of API services, such as user authentication, rate limiting, and statistics.

Why use an API gateway?

At its most basic, an API service accepts a remote request and returns a response. But real life is never that simple. Consider your various concerns when you host large-scale APIs.

You want to protect your APIs from overuse and abuse, so you use an authentication service and rate limiting. You want to understand how people use your APIs, so you’ve added analytics and monitoring tools.If you have monetized APIs, you’ll want to connect to a billing system.You may have adopted a microservicesarchitecture, in which case a single request could require calls to dozens of distinct applications.Over time you’ll add some new API services and retire others, but your clients will still want to find all your services in the same place.

Your challenge is offering your clients a simple and dependable experience in the face of all this complexity. An API gateway is a way to decouple the client interface from your backend implementation. When a client makes a request, the API gateway breaks it into multiple requests, routes them to the right places, produces a response, and keeps track of everything.

An API gateway’s role in API management

An API gateway is one part of an API management system. The API gateway intercepts all incoming requests and sends them through the API management system, which handles a variety of necessary functions.

Exactly what the API gateway does will vary from one implementation to another. Some common functions include authentication, routing, rate limiting, billing, monitoring, analytics, policies, alerts, and security.

author avatarreviewer1145859 (Independent Consultant at a financial services firm with 10,001+ employees)

An API Gateway is a façade and an entry point. In my view, it’s used as a façade is it’s defining characteristic.

As a façade it abstracts the service implementation from the service consumer ie if the API is my\savingsaccount\1\balance, the consumer of that service need not be aware that the implementation is Cobol on an IBM Mainframe or cached data on Redis, nor should the consumer care so long as the information about the requested account balance is returned within expectations (the “contract”). As a façade, the API Gateway abstracts the “what” do you want from the “how” it is provided. In this sense it acts as a router and may leverage a protocol converter, abstracting the business service from the technical implementation.

As an entry point, the Gateway protects the service provider from unauthorized access by ensuring only authenticated requests are made, facilitating authorization by associating authenticated requests with specific trusted profile tokens that can then be used by the service implementation ie if the API is my\savingsaccount\1\balance, the gateway may route the request based on the associated token, no token for “savings account”= no routing to service implementation, but the decision on whether the authenticated requestor is allowed to see the balance for account “1” is the responsibility of the service implementation (either by evaluating each request or by providing finer-grained authorization tokens to be returned by the authentication service to the API gateway). The API Gateway entry point may also provide protection against threats such as DDoS and code injection both directly, and in conjunction with underlying firewall and load balancing capabilities.

The API Gateway should also provide information for monitoring and analytics so as to allow an over-arching API management capability to provide API contract and SLA management.

author avatarManju Karjigi
Real User

API Gateway is a unique entry point for clients to consume the API services which are deployed in the backend systems. You can imagine yourself going to Pub. Bouncer, in this case, is API GW, and accessing drinks once you get inside is representations of API services. (if it's of so bad example to compare, just ignore this).
However, coming back to the core part of API GW. Authentication, Security, Traffic control, Logging.
* Protects the backend services. Only authorized clients will get access.
* GW will help you manage this depends on how you want to protect the service.
* Spike arrest, Quota limit, Concurrentratelimt
* GW will help you to manage role-based access
* Administrator, Deployer, Monitor
* GW will help to manage routing, composition and protocol translation
* It depends on which GW you are going to make use of and to what scale.
* We have both Apigee and CA7
* Apigee is in AWS Cloud facing the internet, intranet and extranet traffic
* Whereas CA is appliance version and just at on-premise.
* So, it depends on your need and the features of each GW vary. Products like Apigee will give you the flexibility to define env (Trial, Test, Prod) and Productization is a great feature too.

author avatarreviewer1111221 (Principal Architect at a tech services company with 11-50 employees)
Real User

API Gateway provides a centralized control centre for API provisioning. It faciliates standard ways for securities, service policy, logging etc application. When number of APIs are large, this much reduce development effort and promot standardization of common practice

author avatarSteven Longheinrich

This is answered on numerous external referenced articles, specifically this one in Developer Zone( see reference): "An API gateway provides a single, unified API entry point across one or more internal APIs.They typically layer rate limiting and security, as well. An API Gateway can help provide a unified entry point for external consumers, independent of the number and composition of internal microservices." The key is understanding the need to decouple the external consumer from the internal microservice using an architectural concept called "proxy", which is simply providing an independent way of getting to the data that is not directly coupled to a microservice. There are downsides as well, one of which is separately maintaining the set of API proxies on an API Gateway in addition to maintaining the portfolio of microservices. See the following article for a good summary of positives/negatives:
Reference: https://dzone.com/articles/why-do-microservices-need-an-api-gateway
Note: These are my personal views from an architecture perspective.

See more API Management questions »

What is API Management?

API Management refers to the practices and tools that enable an organization to govern and monitor its Application Programming Interfaces (APIs). Today, the term almost always means management of RESTful APIs using the JSON language.

API Management controls how the gateway passes calls to the back-end service and then hands off the response back to the invoker site. Most large companies have built out APIs for their customers and for internal use. There is a choice to have the data on-premise or in the cloud, whichever works best for the situation.

API management tools typically allow for security policy definition and enforcement, including authentication and authorization of API consumers. They can throttle API calls and limit usage based on established SLAs and resource allocation agreements.

IT Central Station users are looking for a healthy API gateway that manages transformation engines to modify requests and responses in real time. Publishing tools report access and usage policies, and manage the API lifecycle. API Management is responsible for collecting data analytics and other metrics, and monitors load balancers and debugging, especially e-mail notifications, error logs and validation errors. Clients using APIs have access to better insights into their usage because APIs impact many products and services, and API Management is critical to agile operations.

IT Central Station users want ease of use in API Management for monitoring these security gateways against malicious attacks. Aspects most important to IT include Directory Authentication, API Security, Life Cycle Management, Deployment Management and Service Registry, discovery and a repository. There should be built in API Aggregation, Traffic Management, Mobile Optimization, HTTP Acceleration and Data Caching.

IT teams specifically look for API Management to oversee encryption, decryption, credential management, URL management and prevention against XSS and SQL Injection threats. API Management will monitor exposed functionality and monetization. API Management solutions are integral to a 24/7 need to keep everything running, and running well. Good planning and project management will help IT choose the best combination of monitoring tools for API Management.

Find out what your peers are saying about Google, Microsoft, MuleSoft and others in API Management. Updated: March 2021.
474,857 professionals have used our research since 2012.