IBM API Connect Reviews

This solution enabled our business to get our solutions quite fast. Instead of waiting for weeks, or even months in some cases, it actually helped the movement from a bimodal to a faster depth of solution in a matter of the rate at which the organization could change. It was not a technological hindrance, it was more a change management aspect of the people that kept the movement back. But, we proved that the technology can keep up, it's the people that have to change faster. The fact that the product can provide both security and scale to quite a large number of products, is basically the reason why we chose it, and that's what we like about it.

The most valuable feature is the security we get from this solution. I know of a bank that uses it to ensure that everything is secure. The second feature I like is the retail environment, where we actually want to be able to provide as many suppliers and consumers with APIs as possible. If you are well-trained in the writing of RESTful API's, you can actually publish an API in a matter of minutes, test it, and publish it.

It is still a very new product. We're still finding our feet on the latest version of it because it gives you the capability to move into the cloud. We have not yet taken that leap into cloud because of the uncertainty of what the moving parts are, and that's why we'll have to wait and see. I would like to see more stability, however, and I do believe the newer version will offer that.

The new version is very unstable. There are a lot of fix patches and a host of known errors. They've started it on their website. So we're waiting for some of that to stabilize before we continue, but we're working around that as far as possible. The old version 5 was quite stable. We were able to put a lot of business commercial APIs in place. It is actually being monetized, and the guys are making money out of that. 

This is a robust system that is easily scalable. When it comes to the amount of users, it all depends on how you tackle the implementation, because in the first case, we basically had people that's running the infrastructure, setting the infrastructure up, and there you need a number of roles to set up the ecosystem itself. Then you must have the API providers. That could be including some business people as well as some testing people. And then obviously the running of it is basically minimal. With the new approach, we have very few people that can actually do the job. You have to, on a case-by-case, request time from people to do some work for you. There's no dedicated staff. The whole business approach and the whole implementation approach varies from organization to organization.

We plan to increase usage because if you want to make a business digital, that is one of the routes to go. Obviously, if you want to get mobility included in your portfolio of services, you have to go that route.

We've had no hassles with IBM when it comes to technical support. Whenever I log a PMR, they respond. In one instance they actually drove a guy in from their site to come and do a site visit. In another case they flew a guy in from Germany. They know that they have us as a customer and that's why they provide us with good support.

It is not too difficult to work on the solution itself, but to get it to fit within the organization, is something else. There is a vast difference between business models, between a banking setup and a retail setup. One must, first of all, get the business-aligned, because today business plays a bigger role than in the past. With APIs, it's inside-out thinking, meaning that business owners of the data will have to decide how they're going to do it, which is a change in some organizations where IT normally drives the technology. Now, all of a sudden, you have to tell the business, "You have to make decisions which IT will enable".

We used a team of people to implement the solution, and the first time we installed it, we had to pivot twice. All in all, it took us six months, and we had a dedicated team of about 15 people to do it. Once we'd pivoted twice and experimented with it, it took us approximately five months to get it up and going. The latest product, the new iteration, is run through a project, which doesn't have dedicated staff, and it has been ongoing for almost 13 months now. We're not yet done with pivot one.

We used IBM directly because we bought the product from them. We basically got them onsite to explain what their blueprint meant. The documentation was quite good, so all we had to do is get them to come and agree with the pattern we've selected. Now we're still finding our feet, experimenting and making up our minds.

We do see an ROI, because, in the past, we could not monetize services. Now we can sell our data. 

The basic appraisal based on the two models is available on their website. The one is PVU-based and the other one is consumption-based. But that is a ballpark figure. Obviously, when you engage with them in a contract, they can negotiate. 

We did evaluate a lot of other options. We were led by Gartner and Forrester with regards to that, and then we did site visits to other companies that implemented products, and we had a look at their solution. We spoke to some of their staff. Based on that, we did the due diligence, and then we selected the product. This solution came out on top.

The product itself delivers on what is documented and we don't need any additional features. Currently, there are some features that are not working because of known errors. I would like to see an improvement in the stability, however. Once we've got it stable, we can push the limits. We can see what works and what doesn't work, and then we can comment on what is required for the future. I will, therefore, rate this a seven out of ten.

It provides a good, simplified user interface to design and secure your APIs.

First of all, it gels well with the other IBM products that we have. It resolves some of those integration problems that we earlier used to have. It provides OAuth2 authentication, which is like what we use in our APIs. So, these are the two main benefits of this product, as compared to what we were using earlier.

A lot of the features require improvement, such as better integration with the other suites of the product and a more secured way to put it on the cloud. Another useful feature needed is to make API development more easier and simpler for development, especially on the management of other artifacts, like the client IDs and other stuff.

I would rate the stability a seven to eight out of ten; it's still evolving. There are features which are missing, that are there in the other similar product from another vendor. Overall, it's good.

The scalability is good, it's at par.

We have used a lot of the technical support! We work with IBM on a lot of custom enhancements, that suits our needs. They are really proactive in regards to listening to the customers. So, they also provide a few fix packs to us sometimes.

We have a relationship with IBM. They approached us with this product and as I mentioned earlier, it integrates pretty well with our other IBM products that we use in-house. So that made us to go toward this product.

IBM are the market leaders, when it comes to integration technology. So, their proven ability and experience is why we chose this vendor.

Experience is the number one criteria while selecting a vendor. The second factor is the brand and the relationship, of course, it matters.

We do have other vendors that we use. However, the majority of our integration is on IBM.

It's good. They have really good use cases. So, it's worth investing time in these products, and if it suits your needs, then you can really go for it. It does support a wide variety of use cases.

We are a regulation entity dealing with many sensitive services. We carry out supervision and regulation for FinTech companies and other financial institutions. We are partners with IBM and I'm the project delivery director.

In general, this is a powerful system. We're currently only using one or two functionalities from API Connect. One of them is consulting WSRR to get the endpoints which is a powerful component. Each API management has a Gateway located on the DMZ that can be exposed to external networks and does the authentication, authorization, some security functionality as filtering, checking the security aspects such as decrypting, encrypting or service transformation and other functions. The development portal is good and can be used by external developers who can develop it at their site.

One issue we have with this solution is its complexity. In addition, it doesn't handle large volumes of traffic very well. 

I've been using this solution for several months. 

The stability is good. 

Scalability is reasonable but not great. 

Customer service takes a while to respond. They also want a lot of information and this adds to the time involved in getting a response. 

The initial setup is not easy, similar to other IBM products. It's quite complex even with a system integrator and the deployment took some time. We have around 15-20 users on the development side. We plan to increase that in the future. 

All IBM products are expensive and API Connect is no exception. The license includes everything such as a per BVU charge along with other integration components plus OpenShift for microservices and DevOps and others. You can purchase a better BVU and then you can use any features or components under this license. They have the Cloud Pak for Automation package which includes BAW Business Automation. They also have something called Aspera for file transfers. 

We evaluated API Connect and Apigee. API is designed to be a comprehensive solution for building and managing API with features for designing, development, and distinct publishing APIs, as well as for managing the life cycle of API and enforcing security. Apigee on the other hand is designed primarily as an API management platform while focused on securing and scaling APIs for use by extended developers. Ultimately, the best platform will be the one suited to your specific needs and use cases. 

API Connect is a standalone platform, which means it may require additional integration with other tools in order to support the range of API developments. API Connect is designed to support the management of large numbers of APIs but may struggle to handle large volumes of traffic or very complex APIs.

It's helpful to have a suitable in-house team and to work hand-in-hand with the system integrator. You also need powerful infrastructure and hardware. If you're exposed externally, you have to apply security standards either on the Gateway or F5, or the Load Balancer. It requires the capabilities for good enterprise or solution architecture and sufficient experience on the integration side in order to have the right solution design and system architecture.

I rate this solution eight out of 10. 

API Connect is mainly used as a gateway solution to expose, secure, and manage APIs. 

Using API Connect allows us to quickly create proxy APIs and saves time on end-to-end testing, which lets us deliver quickly to clients.

API Connect's most valuable features are API management and creation.

The developer portal could be easier to customize - as it's Drupal-based, I have to hire a Drupal developer to do it for me. I feel there should be a drag-and-drop or UI-based configuration to customize the developer portal. In the next release, I would like some support for file uploads and MQ integration.

I've been using API Connect for six years.

The newer versions, from 2018 forwards, are quite stable.

API Connect is scalable because it's completely containerized.

IBM's technical support is very good.

The initial setup was straightforward, and deployment took two days.

I did the implementation myself.

I would say that if you want stability and security, you should go for API Connect. It's a very robust product that lets you easily create and manage your API. I would rate API Connect as nine out of ten.

We primarily use the solution for a bank. It's used for the operations portion of the bank. It's primarily used for the review of the personnel in your accounts et cetera. It's for many operations for the bank.

The interface is very nice. It makes the solution easy to use and navigate.

You can install it in coordinates, in general, and you can deploy it in Amazon, in Google, in the IBM cloud, or other clouds as well. You don't have to worry about having to work on a specific cloud. It makes it very flexible. This is very important.

The product is quite robust. 

The initial setup is very easy and the deployment is very quick. 

The documentation needs to be a bit better. It's very sequential, however, I don't understand what options to choose for certain tasks. I need to read all of the documentation to find what I need. It's easier to look at recommendations or to watch Youtube videos that show specific examples. 

There needs to be more in the toolkit to complement the product. We could have more features, for example, for queries to the platform. 

I've been using the solution for three years or so. It's been a while. 

The stability has been fine. We've found it to be very stable. There are no bugs or glitches. It doesn't crash and freeze. In the past versions, stability was a bit of an issue, however, in the latest version, we have found it to be much better and much more reliable. We are satisfied with it so far. 

The scalability has been good. If a company needs to expand it, it can do so.

We have an average of 1,000 people using the platform normally. On top of that, there are 10 developers that are also on it at any given time. 

Technical support could be better. They are so-so. They could be more supportive and be better at answering questions. We'd like it if they made issues easier to resolve.

There's also a general lack of documentation, which sometimes means finding answers on your own is difficult to do. 

The initial setup is not overly difficult or complex. It's very simple and straightforward. 

The deployment is quite quick. It only takes about one hour to have everything up and running. 

I'd recommend the solution to other users and organizations due to the fact that it is very, very easy to use. The product is good, however, that said, they need to pay more attention to their documentation and support. 

Overall, I would rate the solution at an eight out of ten. We have largely been satisfied with the solution and its capabilities.

We are IBM partners.

It provides a few features such as security and discoveries.

What we look for most is security. API Connect can provide that. On top of that we use it to replace the old version. The current WSR was for discovery, the web service.

Additional features probably will be easier to develop. Right now the UI is using quadruples. On the policy, they are using SSLT, but I would like them to convert that SSLT to use scripting language instead.

We just started. We are converting from the old infrastructure to the new API Connect. We started maybe a year ago, but we'll see the results maybe in six months.

I think the scalability is pretty good. The API Connect divides by different zones, different domains. So how we can scale depends on organizations. If it is big, we make it big and if it is small, we make it small. It's pretty easy to use.

We used the support quite a bit, because we have to transfer the old WSR into API Connect without rewriting everything. With that transfer or migration, it takes a lot of work, so we talk with technical support. They are pretty knowledgeable, but we still have to go through many iterations, many cycles to get all the technical information out.

Beforehand there was the older generation of API Connect. API Connect came out maybe two years ago, before that was WSR combined with data power. They are going to retire WSR. WSR is also for my VN. That became AP Connect so we had to move.

I wasn't involved in the initial setup process.

I would think customer service and trust are important when deciding which vendor to choose. IBM, Oracle, and Microsoft were on our evaluation list. We've been with IBM for many years now, so we'll stay with IBM. We work very closely with IBM on their product and they're very good support, so when we run into issues, they are there to help.

I think IBM is very innovative and maybe that will give them an edge into their industry.

We use this solution for rest-based, micro services to complete authentication. We are able to gather statistics and audit and throttle traffic. It also has a developer portal that allows users to browse their APIs and develop applications on them. It has solid features compared to some of the API services management services out there.

This solution is ready to scale and already supports our agile CICD.

The integration of cloud-based services is where we're looking for improvement in this platform.

We have been using this solution for four years. 

This is a stable solution. 

This is a scalable solution but scalability would come at a higher price. This solution supports our organization of 50,000 people.

The initial setup is reasonably straightforward.

We consciously decided to go with microservices to enable us to move quickly and to building the flexibility and capabilities in our applications. Whether the business is able to translate those investments into profits and returns is too early to tell.

I would rate this solution a seven out of ten. 

It is the go-to solution for API repository products. We use it for runtime by designing certain products, and those products are subscribed to by various consuming systems.

It has made API monetization quite easy. I can simply log onto the API dashboard and see who has used how much and whether they are using their quota or not. If they go beyond their quota, I can then give them a higher rate. Thus, it has helped us with API monetization.

We really like the runtime capabilities of IBM API Connect. The creation of products and the control of the monetization and hit rate are some of the features which we've found very valuable.

There are certain areas that need improvement. The first one is the design time setup. It has a lot of customizable fields, but we need certain standard fields to be added, such as what all of the consuming systems are. This needs to be very clearly articulated during the design time.

The second, which was a very big issue for me for adoption, is that they don't give any out-of-the-box solutions for knowing how many users have logged on during the design time and who has access to the portal for how much time. There is no capability right now to tell me the usage details and user rights.

As for additional features, design time user analytics would be great to have in the next release.

I've been using this solution for one and a half years.

It's quite stable.

Right now, we are using the design time thoroughly, but we are in the nascent stage for the runtime. So we just have a couple of systems using it, but going forward, we have plans for extensive adoption of the runtime capabilities.

We were previously using WSRR, and we switched because IBM stopped providing any updates to that product. Also, it was primarily design time only; there was no runtime capability.

The initial setup was a little bit complex because we wanted to put it in a proper Kubernetes cluster. So we had to learn Kubernetes and then do it.

It took us a month to deploy the solution.

We used IBM directly for implementation. We've been using IBM services for the past 13 years, and we are okay with their level of expertise.

I would urge others to use both design time and runtime and not just use it as a repository. I would suggest that they utilize the runtime features, which are pretty strong. First, they can secure your API ecosystem.

Second, they have very good monetizing capabilities, which allow you to design products and see who accesses those products. Usage-based and storage-based restriction capabilities are present, which are probably some of the best on the market today. So, I would really urge people to just go beyond the design time and also utilize API Connect in runtime as well.

On a scale from one to ten, I would rate  IBM API Connect at seven because it is a little bit weak on design time.