We have a partnership with IBM for some products, but for IBM API Connect, we're just end users.

I used Azure API and then Microgateway. We use IBM API Connect because the client is an existing user of API Connect for another client's project. Their organizational practices favored using the same solution, so we had to go with IBM API Connect.

I also have experience with Red Hat 3scale API gateway.

IBM API Connect is much much better. In terms of features, there are some limitations with 3scale. Additionally, the support for Red Hat 3scale is not as good. Even the documentation provided by Red Hat is not as comprehensive as IBM's strong documentation. If you're a beginner developer and referring to the IBM Knowledge Center, you can easily develop your API, but that's not the case with Red Hat. Red Hat's documentation is still not as mature as IBM's.

When comparing IBM API Connect to other solutions, there are two key observations to consider. Firstly, the toolset and framework around IBM API Connect are methodical, which sets it apart from close competitors like Mule and others. This approach can lead to noticeable improvements in efficiency. Secondly, if there is a need for customization to address a specific industry problem, IBM API Connect is a good option. It has built-in checks and balances to ensure that performance is not impacted, which may not be the case with other vendors.

We haven't worked with other solutions similar to IBM API Connect, but we're considering another alternative from Open Source, though we haven't decided which product we want to work with.

I use different API management solutions because I'm a consultant. A customer might have IBM API Connect, while another customer might have Apigee. It also depends on what the customer has. All I do is strategy and implementation, while other people just want a consultant to deliver on specific vendors. It ranges from customer spec.

I have experience with IBM API Connect.

I have no prior experience using a solution similar to IBM API Connect.

We are currently looking to change over to another vendor.

We did not previously use a different solution. Let's face it: This is a relatively new space and we’re a bank. Of course, we knew that the solution was going on.

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.

We used another product for API management. However, there were several areas of improvement related to the availability of a knowledgeable and skilled support team.

I have previously used Oracle API gateway. When comparing the two, they are both very reliable and have good APIs but IBM on-premise installation is more flexible.

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.

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.

We did not previously use something else.

We took on API Connect although it was not Number One on our shortlist as we had a large contract with IBM which includes also this product.

Previously, we were using Layer 7. The reason as to why we decided to switch solutions was because the current environment was not working for us.

We weren't using a different solution. This is a new approach. We do have alternatives that we are using, including other IBM products. But we did this one more from a sales relationship, technical sales team pitch.

When selecting a vendor, reliability and experience are most important; the fact that we had experience with them. We have a lot of IBM products and we had a lot of good relationships.

We have this monthly inter-tech meeting, where we go through as to what is going on in the market, how the industry is going, and how we can utilize that in order to start serving the business, with an expedited return on the investment. So, this API, DevOps, and microservices are the things which are happening right now.

The most important criteria while selecting a vendor are that they should be able to help us not just with solving problems, but they also need to advise us in terms of how the trends are moving and how we can be strategic partners, instead of it just being a one-time solution.

We didn't previously use a different solution.

I have used APIGEE in a different project.

We were using IBM DataPower without any additional layer. By adding this new obstruction layer with IBM API Connect, we're simplifying development and improving our interactions with our partners. It becomes more compatible to the industry standard having the API management system in place.

I previously used Epigee, Kong API, and 3scale.

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

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

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

Some of our clients tried to use a customer design. They switched to API Connect because it is more advanced.

Previously, we didn't use another solution. This is the first API management product that we have used. 

The decision to switch was made before I had left IBM and went to this company four months ago.

When selecting vendor, support and longevity are the most important criteria.

We switched to APIC for easier management of APIs and to leverage its inbuilt policies, security features, and usage of DataPower as gateway.

Previously what we used to do is deploy different endpoints for different clients that we have onboard. In the last two years, what we've been doing is using API Gateway Manager so we have only one endpoint with different uses.

It was an addition and not a substitution to anything.

I previously used the IBM Tivoli Monitoring tool before joining my company.

We were using a different solution, but we knew that this was the future, so we knew we needed to switch.