The usual use cases for IBM API Connect that I worked with mostly involved three things: security, monitoring, and message control. The purpose was to address these areas, though there was one feature we did not use. IBM API Connect has the capability to monetize APIs, but I worked for an insurance company that did not want to monetize. They wanted to use it internally and control the information, so monetization was disabled.

After that, we focused on security, monitoring, and message control. For security, we added Active Directory integration so people could connect securely, and we enabled JWT to secure login, password, and token inside JWT.

Monitoring was important because when IBM API Connect is installed on Kubernetes and OpenShift, it includes ELK, which is Elasticsearch, Logstash, and Kibana. When we wanted to monitor something, set an alert, or check the logs, everything was included such as the number of calls, the number of succeeded requests, the number of failed requests, the number of requests with technical errors, the downtime, and the average message time for request response. Everything in monitoring was handled by ELK, and there was a small customization of Kibana dashboards, though it was really limited. The customization of Kibana inside the administration page of IBM API Connect was quite restricted.

Then we had control, which has many parts. The first part was that when we created an API, we had to create a contract using Swagger contract, OpenAPI 2, or OpenAPI 3. We were creating the Swagger and controlling that the message had the minimal requirement of data and structure, or it was rejected by IBM API Connect directly.

The second part was that when we had an API, we had to create what we call a plan, and inside the plan, we could add our customers. Any plan could have rules and policies. For example, we could say that accounting clients have a plan and inside this plan, they can only use GET requests to get information but cannot modify it. All the updates were forbidden.

We created the plans to control who is doing what. The last thing we were doing with these plans was implementing request limitations. In a big insurance company with many millions of clients, when requests come from anything online, batch, and so on, if we say a user coming from a certain server can only make 100 requests per minute, all the other requests get HTTP 529. This is managed by the plan and by the user. We could control and say that a batch from a certain server can only make 10,000 requests per day or 5,000 requests per hour or per minute. This is a rate limit based on the number of requests and the time range. IBM API Connect made this control quite easily, and we could see in the dashboard when someone made too many requests. For instance, if someone was only accepted for 500,000 requests per day but made one million requests, he increased his number of requests by twice and half of it was not allowed. All those things made us limit requests. We limit because we do not want to kill the servers in the backend on the other side. We made tests and stress tested the backend, and when the documentation said a backend can only handle 10,000 requests per day, we needed to be sure that every request coming to it was managed by IBM API Connect in front of it, and only it could handle the requests going to the backend on the other side.

The features or capabilities of IBM API Connect I have found the most valuable and useful are two things that are good, but one of the two is not easy. The first thing is that the development is in JavaScript. When I want to make custom development, I can get a request and handle it as I want. Because there is JavaScript, there are quite no limits. I can do whatever I want with the message, transform it, control, update, anything I want, really. IBM API Connect also has modules, so if I do not want to use JavaScript for custom development, I can use modules. They have modules for XML to JSON and JSON to XML conversion that I do not have to code because they are already included. IBM API Connect has something to put a flow from the request to the backend and from the backend to the response, similar to an ESB. In both directions when something has to go through, I can use it, which is great. So it is time to develop, but if I really do not find what I want into the modules, I can make custom development in JavaScript.

The second thing is that there is even a debugger, but the debugger is difficult to use. It is cool that there is a debugger, but not cool when I want to enable it because it is difficult. I need to use Postman. To debug an API, I need to call another API to enable the debug of this API first. Then when I make my call, I need to call another API to get the message and see all the steps. It is not having a debugger in Java where I can make step-by-step debugging or in any code language. It was not really easy because I need to test, enable debug, send the message test, recall another API, get the steps message in a text file and understand what is the problem and then resolve it. However, Gravitee API has a real debugger with step by step functionality.

I have used the analytics feature of IBM API Connect. The analytics is on the Kibana side through ELK, which is the Elasticsearch, Logstash, and Kibana part of the analytics.

The metrics I found most useful are different for different departments. For the business analyst and for the product owners and managers, they were checking how many requests succeeded and how many requests failed at the end of every month. We preferred to see only the bad requests. We would check if there were any requests refused because there were too many calls in the time range, how many 500 errors there were, and why those 500 errors occurred. Then we would go to the dashboard and check the message response to understand what was the problem. This was the more interesting part for us as architects and technical persons. Product owners, business analysts, and others wanted to see that we had 90 percent of success messages and 10 percent of failed messages and so on. We had different dashboards for different audiences.

There are areas of IBM API Connect that need to be improved. I want what Gravitee made, which is much better. Gravitee made many samples for different use cases. First of all, they made examples of use cases, codes, and what the module expects and what the module returns for multiple examples and use cases inside the development. I do not even have to go to the documentation website because everything is included inside the tool when I work on it. This is great, in fact. IBM API Connect should show examples.

One other thing is the support. The support of IBM is in India. Every time I want to ask something, they say they need logs, they want this, they want that. Gravitee API asks me to explain the problem without asking a thousand times as if it is a request for a green card in the USA. Then they really explain quickly.

IBM is a big company, so everything is standardized with the approach of "You do that, you do that, you request that. If you do not have that, you do not reply to the client." Clients want flexibility today, even if it is a huge company. A stressed client is a client that will want to change to other flexible solutions. When everything is fine, we do not care, but when there is stress and problems, that is when the customer of IBM evaluates the tool really. It is when there are problems. IBM makes a lot of efforts on sales and technical sales, and then that is it.

I have been working with IBM API Connect overall for around four years. There was version 8, version 9, version 10, and after they changed, it is version 2024 I think, 2025. IBM always changes names and so on. But I worked extensively with version 10.

IBM API Connect was very stable. We never had any issue of memory or anything. It was really stable.

The scalability of IBM API Connect is quite variable. When you have on-premise, it is very difficult. When you have Kubernetes or OpenShift, it is very easy. When you have Node.js, it is not quite impossible, I think, but it is quite difficult.

On-premise is very difficult because you need to put a proxy and so on. You need many things. When I mean on-premise, it is a physical machine where IBM API Connect is installed on one VM or physical machine only. If you want to increase scalability, you have to add another VM or another physical machine and install IBM API Connect and make them collaborate together as a cluster. This requires significant effort.

When you have Kubernetes on cloud or on-premise, scalability is easy. We had Kubernetes on-premise because we wanted performance. We had Kubernetes locally because we had to install Kubernetes ourselves, which was our responsibility. So we installed Kubernetes, or we could install OpenShift which is just a top level of Kubernetes in the end. But then inside, I would go to the sys admin of Kubernetes and ask if they could increase the replicas from four to eight, for instance. Everything would be done inside of it and the network would be handled, and the proxification of the URLs and DNS would be done internally. This is easy with containerization.

We quite suffered with Kubernetes initially. First of all, there were minimal requirements that can be found on the website regarding a certain version of operating system, memory, disk, and CPU. We made the initial setup, and when we tried to install, we had many errors. In the end, we asked for an expert of IBM to come help us. It took one week, and he helped us because IBM has information that I do not find in the documentation. It was frustrating that we almost could not install it by ourselves because some information I will never find because IBM keeps it. This is not fair. IBM is very aggressive in the legal part, in the selling part, and in anything.

I participated in the initial setup and deployment of IBM API Connect.

The role of IBM API Connect in accelerating time to market for customers is a difficult question. If you have an expert, it is a big added value to have IBM API Connect. But if you have people learning it, the documentation is not easy, which is typical of any documentation of IBM. It really depends on whether you have an expert or whether you have people learning. However, compared to Gravitee, I would choose Gravitee, unfortunately, for IBM.

I have utilized the automated API creation tools, but we did not prefer it. We used automated conversion for the API. We had old web services with WSDL in XML format, and they wanted them as an API with just sending JSON. So we provided the XSD and the WSDL to IBM API Connect, and it worked quite well. Then it transformed it to a Swagger. Then we took the Swagger and we could continue the CI/CD of this REST service. However, the automated generated API was not our preference. Either we went from WSDL or we created the Swagger by hand. We used Stoplight, which is a Swagger editor. We were working with the business analysts, and we were creating the Swaggers together. Either they provided us an XML or an Excel file with all the structure, or we were doing it all together without an Excel file and creating the Swaggers. When the Swagger was valid, then we installed it into IBM API Connect.

I have been working with Gravitee API, the French solution, while also providing feedback with PeerSpot. It is not the same. It is really not the same. There is Gravitee API, and that is it, because there was Kong but it has not been tested because it was too expensive, so they refused to test it. I installed Gravitee API and worked on it. I mean I installed it, and it is used in production.

I was also working with APIC, IBM API Connect, and App Connect also. I have not been using GraphQL because it is a new feature, really. But I had some questions on it.

My overall rating for IBM API Connect is 7 out of 10.

IBM API Connect has a designer and CLI features which can be used to completely automate the API. The way we use it is different. We really do not need an app dev team in order to create, design, and deploy an API. If a business analyst has a basic understanding of what the input and output payload is, they can directly create the API. We have automated the process. A business analyst fills out an entire Excel sheet with input and output payloads. That payload is fed to IBM API Connect commands and generates the YAML out of it, which is compliant with Open Standards 3.0.

IBM API Connect by default has all the features that are specific to CI/CD processes. IBM API Connect has a rich set of policy management features. We can achieve centralized control over API policies for governance and compliance. If a security team requests compliance features, we can fit IBM API Connect to address or secure whatever needs come out of the security team. All the enforcements can be done using IBM API Connect.

IBM API Connect is an API Gateway. It is purely for securing enterprise-wide APIs from the outside world. It best fits as an API Gateway in DMZ zones. It has a lot of features. It supports OAuth, third-party identity providers, and MFA as well. With the introduction of IBM API Connect V10, it also supports integration with multifactor authentication.

IBM API Connect has a designer and CLI features which can be used to completely automate the API. The implementation approach is different from typical processes. We do not need an app dev team in order to create, design, and deploy an API. If a business analyst has a basic understanding of what the input and output payload is, they can directly create the API. We have automated the process. A business analyst fills out an entire Excel sheet with input and output payloads. That payload is fed to IBM API Connect commands and generates the YAML out of it, which is compliant with Open Standards 3.0.

IBM API Connect by default has all the features that are specific to CI/CD processes. IBM API Connect provides policy management features. We can achieve centralized control over API policies for governance and compliance. Whatever a security team requests in terms of compliance features can be addressed through IBM API Connect to secure the necessary components. All the enforcements can be done using IBM API Connect.

When comparing IBM API Connect with DataPower Gateway, there are many features in DataPower Gateway that are not available in IBM API Connect. Some examples would be connectivity to MQ is not available in IBM API Connect. Custom code needs to be written in order to connect to MQ and exchange messages. This can be achieved, but it is a tedious task. Custom extensions need to be built in order to connect to MQ and exchange data. Additionally, there are enhancements needed when it comes to segregating APIs based on domain.

We did not go with the model of scaling based on licensing. We have a centralized pool for the entire middleware IBM middleware stack, which is quite close to 400 plus licenses. It is distributed among IBM MQ, IBM Ace, IBM DataPower, and IBM API Connect. As far as licensing is concerned, it is pretty flexible. It is not tied to a single product.

Support is extremely good, especially with Sev 1 issues. The research team is brought into calls whenever needed. The support team is strict on their SLAs.

The overall review rating for this product is 9 out of 10.

We use IBM API Connect for healthcare projects, not for telecom services.

The best features IBM API Connect offers in my experience are the middleware capabilities, as it can connect the front end.

You can be more secure using JWT tokens with IBM API Connect. We can optimize API access, which will be more secure. We can add some policies to provide extra security, protect your backend, validate the consumers, and analyze based on the traffic limit to throw things out.

IBM API Connect helps with security by using OAuth 2.0 and basic authentication.

User management to authenticate the user is an important feature worth mentioning.

IBM API Connect has positively impacted my organization, as customer experience is good. Based on the subscription, we can handle the subscription, and customers use the environment as a handler, making the mechanism easy.

Based on the implementation, you can see improvements in onboarding speed. If this is a direct application, you can validate with the user and get the response from the application. If you require multiple transactions, it takes time.

To improve IBM API Connect, based on customer experience, you could work on latency. You can increase scalability and availability. If you're connecting with any other cloud, it connects to the infrastructure which needs to be managed with the customers and cloud providers, so if you have a setup, we can handle it easily.

I have faced latency issues on the server, related to our management. If you need to stabilize your server based on peak traffic, you need to configure the scalability model. You need to know when traffic peaks, so use auto-scaling when traffic comes. If the application is not in use, the value should be zero, and it starts from zero. Based on customer experience, the value will increase, and when there is no customer servicing, the peak would be reduced, making the value remain zero. Following this approach, you should be able to optimize costs and satisfy customer experience.

I have been using IBM API Connect for four years.

In my experience, IBM API Connect is stable enough, but downtime depends on traffic and backend server configuration. If your backend server is down, you may experience downtime. If it is functioning well, you won't have a bad experience and your application becomes more reliable.

IBM API Connect's scalability is good, as you can handle it easily similar to how you manage cloud providers.

I haven't reached out to customer support yet; there is a separate team for that.

I used Google Apigee middleware before switching to IBM API Connect.

My decision to move from Apigee to IBM API Connect depends on the project I worked on.

I have seen a return on investment from using IBM API Connect, as we created multiple plans based on customer usage. In those plans, we can reduce traffic, and based on the traffic, we can optimize the cost.

I have not worked on pricing, setup cost, or licensing for IBM API Connect; that part is handled by the architect.

I did not evaluate other options before choosing IBM API Connect, as I mostly worked with Apigee. It depends on the provider; IBM API Connect allows movement into on-prem architecture, while Apigee is primarily a cloud solution.

My advice for others looking into using IBM API Connect is that it's a good platform to learn from. You can create API proxies easily, implement features effortlessly, and maintain them without hassle. There is also a support team available. It's a bit similar to Apigee and stands out as a unique platform.

Regarding a business relationship with this vendor beyond being a customer, I believe my vendor subscribed to IBM API Connect, and I'm working in the healthcare domain, so that's the vendor basis I believe.

I don't have any additional thoughts about IBM API Connect before we wrap up; it's a good opportunity to learn.

On a scale of 1-10, I rate IBM API Connect a seven out of ten.