IBM API Connect Reviews

V3 is way better then v2, and v4 has further improvements. We have the ability to secure, control, transform, catalogue and optimize access to our APIs for external and internal partners and developers.

The APIs are exposed to B2B partners in a secured, and better way. Internal re-usability of APIs are encouraged by cataloguing all the APIs.

It lacks the ability for billing and metering the API usage to invoicing in v3, however, v4 does have this. Automation of deployments is needed.

We've used it over a year, v3 was purchased in Q2, 2014.

Manual steps for deployment is needed.

No issues encountered.

No issue with scalability as the run timefor API Management is proven and time tested i.e. Datapower which all fortune 1000 companies use.

The IBM customer rep was very helpful in the POC phase, and helped us escalate custom/new features which we requested.

Ir's excellent.

No other product was used, and the service was just exposed by Datapower.

Initial setup was straightforward as 50% of the solution was already in place. IBM API runs on IBM Datapower so the setup was only needed for IBM API Management itself.

We did it in house using the same set of Datapower developers supported API Management.

We also looked at WS02 which was way too complex and needed almost 14-15 VMs to run. As we had Datapower, it was a natural choice for us.

If the customer is already using IBM Datapower then it is a no brainer that IBM API Management will complement their existing investment.

My clients mainly use API Connect as an API gateway. A lot of the backend services need to be exposed to other parties, mobile devices, interfaces, etc. 

API Connect's most valuable feature is its ability to act as a gateway. It's very easy to configure security and everything else in it. You don't have to kill yourself implementing custom configurations. Sometimes the customer wants to incorporate their identity provider, and API Connect handles that without any problems. 

One thing about API Connect that could be improved is the security schemes. There are so many security schemes, and from a product perspective, IBM could improve the user experience of the configuration security scheme. It does what it is supposed to do, but it could be easier to configure. The junior developers sometimes find it a bit confusing to configure even though they understand the concept.

And another thing is that I don't know the security policies that we have. For instance, we have a service account, which is needed to connect to some other services. So in those cases, I find it a bit hard to tweak things in the API gateway. And one could argue that it is not the right thing to do with the API gateway. It has a different place to be, which could be why they haven't put it there. But sometimes, you have to tweak around that, and I find it a little bit hard to do that. So if they could accommodate that in there, it would be better for some people.

I've been using it for the last four years on and off. The last time I deployed it was a few months ago.

API Connect is reliable.

API Connect is scalable, but I've found that everything is more stable if you reset the server every 40 or 45 days. Once, we had an incident in which we were unsure about what happened, but it crashed after 60 days. We didn't know the reason. It could've been a mistake in the product implementation. We don't know what happened, but this particular incident occurred two times. After that, we began restarting it every 45 days. So that's the resilience part, but the scalability part works without a problem.
Another thing is that we don't know all of the use cases that we have worked on before, so we didn't go for automatic scaling of the API gateway. That's done in the backend services. So I'll be honest to say that we haven't explored the auto-scalability of API Connect much. Instead, we put that on full throttle. This can cause a bottleneck if we play around with it, so we didn't take many risks. We put that on full throttle and did the tweaking in the backend services. That's how we did it in the past.

I've interacted with IBM support many times. They're good. They get back to you within 12 or 14 hours after you initiate a ticket. IBM support will get on a call with you if needed and guide you. It's no problem. They provide the same level of support to everyone. 

Setting up API Connect is a straightforward process. Maybe it seems more manageable because I've been taking baby steps rolling it out for the last few years. So when we talk about the latest version, it's not a headache if you follow the documentation. Even for an operations person, it's a piece of cake. 

It takes a minimal amount of time to deploy as a product. Including the processes for the organization, installing the product could take half a day. And when we ask the Ops team to do it, it usually takes half a day for them to do it. They have to document the IP and keep a log of what they're doing. 

API Connect itself does not require any maintenance. But when our teams write the business logic into it, that usually requires some support and maintenance. So a team of two people looks after the whole setup. And they work in shifts. Usually, it works on an onshore-offshore model. So one person from the onshore team will be supporting it for some time, and when he goes off, the other person comes up. 

API Connect's license cost could be a little lower. But, unfortunately, there aren't many open-source API gateways. Ideally, some new developers could come up with a minimum-functionality open-source solution. When I look for open-source resources that work with API C or Apigee, I find very few that can do that. It's not available or very popular in the open-source community. I've only worked with large companies that are capable of affording these licenses.  A better option for smaller companies might be to have two or three developers build a custom API gateway. That might be more affordable for them.

I rate API Connect seven out of 10. I would recommend it to customers if they have the money to pay for it, but it depends on the ecosystem. So, as a consultant, I would recommend API Connect if the customer already has an IBM license. Big companies generally have IBM middleware running somewhere, so they might have a license for these things. In cases like this, we would usually recommend API Connect for their purposes rather than spending more money on a different product. And if a client is building something entirely new and has to get a new license, we'll compare the options, including Apigee, MuleSoft, API C, or a custom solution. 

We use this solution for external API spotters and API.

It helped us mainly with the corporation, ownerships with other partners.  

It makes it possible to create close companies with processes to develop mutually, and digital solutions. 

This is our main benefit.

The suite itself is what I find valuable. It has all of the tools that are needed for the specific mission. I have the portal, I have the run time and the security.

The solution itself is valuable.

The automation and the simplicity could be improved.

They could also have more frequent additions.

I would like to see the simplicity improved to make it very easy to deploy and to make it very easy for the regular developer, not an API special developer.

I would like the developers to be able to develop APIs and to make them more accessible.

I would also like to have a DevOps built-in process that is very fast and easy.

The monitoring suite should be ready-made and not have to tailor-make my home.

I have been working with IBM API Connect for three years.

It's a very stable solution.

Our work is very basic. We have not dealt with scaling.

It's IBM, and they take time. I am from Isreal and the support is always from abroad. It's a heaving process.

At times when we have issues and have decided not to turn to support since we know it will take time, and the effort is not as understandable, but we will have a solution at the end of it.

Technical support is an area that needs improvement.

The installation is pretty complex. 

We must also take into consideration that I am referring to the on-premises installation, which by definition is much harder, and relatively speaking it is a bit complex.

It is quite an expensive product.

I would rate IBM API Connect a seven out of ten.

We use IBM API Connect before API publishing for enterprises. If we have a big enterprise and they want to publish their data for the public, we use API connect.

IBM API Connect is a good product, and their technical support is excellent.

The initial setup and installation could be easier. The price could also be better. I would like to see monetization of support, a monetization billing engine, and monetization within the product in the next release.

I've been using IBM API Connect for two years.

IBM API Connect is stable.

IBM API Connect is scalable.

Technical support is excellent.

The initial setup and installation aren't easy. It's complex.

One member of our team implements this solution.

IBM API Connect could be cheaper. We pay for the license yearly.

On a scale from one to ten, I would give IBM API Connect a ten.

We currently use it as our single point of the security catalog for the APIs that the bank has.

The developer portal has been the most useful feature.

Like any typical IBM infrastructure setup, you need to learn to set it up yourself. It's not one of those simple zip files or an archive unzip and you're up and running in some few minutes. Knowledge to set it up is key. 

A more user-friendly portal could be helpful. Something you won't really get lost in. For example, other APIs make it so easy to do a couple of things from the portal, not at the management portal itself. Maybe if IBM can improve on that, it would be most helpful.

The system has not been put through real stress. We use it for our third-party APIs and the connection and so that's not too much stress. I can't give a metrics on its stability. And then at the point of setup, we were already getting a bit of redundancy.

We have knowledge of how to add additional APIs to it. With that, if I were to measure on a scale of one to five, I'll put that at four out of five in terms of scalability. Four meaning it's pretty easy. Once you have the knowledge it's pretty easy to add new APIs to your catalog, create a new catalog, etc. As to if the infrastructure itself is it scalable, I'd put at a two because I remember while we were trying to set up a redundancy we wanted to add an additional protecting node and it took us a day or two to get our head around that.

In our country, there are regulations that don't allow us to really engage and that requires us to go through a proxy to IBM. I can't evaluate their technical support since I have never used them.

The initial setup is complex. Deployment takes about two weeks for different portals. The knowledge takes up time and then there are some other internal processes, but if I were to take out the internal process I would put implementation at about a week.

The way our organization is set up, we have a team that is responsible for infrastructure setup. We also have a team that is responsible for activation setup. So, a three-man team should be able to do the setup.

During the setup, we had to get some professional help from IBM itself. We have people that got trained on the solution, and in terms of integration, they got trained on it. And so they will have knowledge on how to create new integrations and new APIs on it and how to expose APIs on it going forward.

Before choosing IBM API Connect, we looked at 3scale API and API G-Box.

Infrastructure setup was a bit painful. Knowledge up-take was not too painful if you are not doing anything complex. But when you start getting into complex APIs then maybe you need some bit of patience if you decide to use this solution.

At the end of the day, it's a great product, I can't fault it for now. We haven't extensively used it, so I really can't say how it would perform over time, or what kind of issues it would have if it was enterprise-wide. I can't find fault with it, for now, it's doing good.

I would rate the solution of seven and a half out of ten.

My point of view is a bit stiff because I'm a developer. I don't mind going through some tech rigors. But looking at it from a more general standpoint, I don't think anybody wants to go through the process of some technical learnings. In terms of the knowledge base, it's not too fun for developers. In terms of setup, it's almost definitely not fun. Usage is working well and based on the architectural principles we are already facing some bit of redundancy on that.

• GUI-based accelerated API development
• Segregation of ownership and control for different stakeholders
• Self-service Developer Portal: a highly customizable portal based on Drupal CMS
• Security support for oAuth, basic authentication and keys
• Analytics
• High-performance solution when used with DataPower IDG. DataPower IDG can support 8K TPS per appliance
• Easy-to-implement, configurable API security and analytics
• LoopBack projects allow API creation using a datasource

This product has been designed very well and addresses many advanced use cases of API development in a collaborative environment, which are not yet available in other existing products, for example, Layer 7.

• Self-servicing portal allows users to explore APIs, create and manage keys. and manage subscriptions.
• Advance infrastructure load balancer/cluster management features
• GUI-based accelerated API development and deployments

• Production traffic monitoring features can be better.
• A few advanced API managementfeatures such as monetization and portal syndication are not yet available in the product, but are included in the product road map for the near future.
• API hosting needs a separate product (for example, DataPower) or Micro Gateway (a node js component). However, in a few cases, this can be seen as a better overall solution.
• Frequent product design changes were observed during the early stages of this product evolution; however, currently this product is very stable.
• A few minor quality issues were observed during the early stages of this product evolution; however, currently this product is very stable.

I have used it for 1+ years.

Current versions are stable. However, a few minor issues were observed during the early stages of product evolution.

No scalability issues were found.

Technical support is 9/10:

• Highly responsive
• Quarterly enhancement/bug fix releases
• Detailed product documentation

We previously used Apigee. We switched due to version upgrade cost issues and a need for performance improvement.

Initial setup is very well documented and straightforward. However, please refer to API Management experts for the most-optimized solutions.

It's available in SaaS and on-premise versions. This product comes in three offerings: Essentials, Professional & Enterprise.

As per the required API Management components, pricing and licensing might vary on a case-by-case basis.

Enables a cost-effective solution when implemented properly.

Before choosing this product, we also evaluated CA Layer 7, Akana, and Mashery.

API Connect is an easy-to-learn, very advanced, reliable, business-to-business API management product. However, understand your requirements clearly and use expert help for the most optimized yet secure solution.

The API Connect product comes with API management, developer portal, offline API development toolkit and a node js component called Micro Gateway. Licensing can differ for these components.

From an API development features perspective, API Connect and API Management might appear significantly different. However, inherently both products exhibit a very easy, refined and mature API implementation process. I would personally recommend to everyone to use API Connect over API management.

The most important feature is, for sure, the security gateway. But if we think commercially, the possibility for easily creating and exposing service plans and charging is also valuable.

We are planning the usage possibilities of API management inside our company, and outside, as well. Plenty of our web services are spread throughout various enterprise infrastructures and we want to control them in a better way with this tool. Of course, the valuable part outside the company is possibility for tracking and exposing telco services, as well as a commercialization aspect, through a developer community.

We have no suggestions so far.

After six months testing the platforms we now have a preparation period for commercial usage. The platform is technically ready for use. We are using a Data Power XG45 v6.0.0.4 as the gateway layer alongside API Management.

No issues encountered.

No issues encountered.

No issues encountered.

We have no such information so far.

We know that our implementer had some problems while implementing the platform but the main vendors technical support (IBM) responded very quickly and professionally.

No, we didn't. This is our first tool with this functionality.

Initial setup is very simple. Later implementation is a little bit complex (disagreement of reference in documentation, different recommended OS versions for additional parts of the environment etc.)

The implementation team did it with the support of a main vendor team. They have high level of expertise.

No we didn't. Maybe ESB (Enterprise Service Bus which we already use) is one of the solutions for exposing different kind of web or other services for sharing usage data but we realized that API management will be more useful for our wider purposes.

It's a good solution with a simple user interface. It has many different possibilities as a business solution.

We used API Connect for OPIE management. About 50 developers in my company are using it. 

API Connect is a good product, and everything works fine. All the analytics are good, and it is easy to follow up. I like it in that sense. I'm more focused on following up on analytics by seeing how many API calls we are getting and where we see a lot of problems. I was working on that API level.

We used API Connect for at least three years.

API Connect's stability was okay. We ran it on top of the Kubernetes cluster, so it wasn't a standalone service. In the worst-case scenario, API Connect couldn't stay online if all the containers went down. We had to restart all the services. We shut down all the containers automatically one by one. That was the only problem. It didn't happen often— maybe three or four times in two years — but it was still somewhat problematic. API Connect is not fully cloud-native in that sense.

We outsource maintenance to a local company in Finland. They built it for us and maintain it.

API Connect was highly expensive for us, but the decision to switch was made before I joined the company. It seems like the company bought it, but they didn't know how to use it. After two years, they decided to reevaluate and conduct some cost estimates. 

I rate API Connect eight out of 10. If you are using a microservice like Kubernetes, that should be tested to ensure it's working. If you are running API Connect on top of Kubernetes, you trust that you can update the Kubernetes cluster on the fly during the daytime.

In our case, every time we had to update the Kubernetes cluster that API Connect was running on, it was so much work. We could update all the other clusters with no problem. So my advice is to make sure that it is working. Otherwise, I think everything was okay.