IBM API Connect Reviews

The gateway is the most valuable aspect of this solution. 

It has a good interface, dashboards, and monitoring tools.

In terms of what needs improvement, some of the product documentation could be better.

I have been using IBM API for around a year.

I haven't had any issues with the stability. There are around 1,000 users using IBM API in my company. 

Their technical support is okay. 

I would rate IBM API an eight out of ten. 

I would recommend it. I'd say that you need some time to negotiate the documentation and the conflicting support that's on their website. The website will day to do one thing and in another place, you do something else. You need some time to negotiate that.

Extracting the data could be improved.

My team members sometimes find it difficult to get something out of this solution.

I have been using it for the last year.

We have no issues.

The scalability is good.

The technical support is good. Whenever we need anything, we have our IT team work with IBM to change whatever requirement is needed.

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

The initial setup was straightforward.

The pricing is too expensive with IBM. Sometimes, we prefer to go with an open source or something more lightweight.

I can recommend this solution and would rate it as an eight (out of 10).

We have done many implementations using API Connect. We work with some of the largest financial institutions in India, including life insurance companies and some of the banks. 

We have done most of them on-premise. The customers, because they are financial institutions and insurance companies, prefer to have this on their own premises and their own data centers.

It allows enterprises to expose some of their tech to outside stakeholders.

We have been implementing solutions with IBM API Connect for five to six years.

I would like to see automation of the installation. If there could be a single-click function where you could automate everything, that would be helpful. There should also be tools to automate the migratation from the older versions to the newer version. That would be another point that would bring my rating of it closer to 10 out of 10.

IBM sets the pricing, but it would be a good idea to bring down the pricing by at least 20 to 30 percent.

I would certainly recommend IBM API Connect for clients who are going with an enterprise version of implementation and when they have enough budget. Of course, if they have budget limitations, they can consider open-source solutions.

As implementers, we have a big resource pool here in India. All our associates have expertise with API Connect as well as IBM App Connect.

As of now, it is serving the needs of our customers. It is quite a proficient tool. It satisfies all of our requirements.

We have implemented this for four or five banks in Nigeria. The bulk of our clients are banks. We need determine if there are transaction capabilities from their back-end applications. If so, then we consume their APIs. For example, we have a logistics company who uses the bank's back-end API to complete their payments.

We specialize in application and cloud integration. 

We have clients deployed on-premise, on the cloud, and with hybrid cloud.

The workflow allows for different parties to work independently of each other, e.g., business people can work independently of the developers. 

If the rules are well followed and aligned, an organization can run a constant API ecosystem.

Our version supports containerized integration. I can write APIs, which can be moved into a testing environment without needing a forklift. It can check if APIs are compliant before moving them into production. 

API Connects has absolutely helped to reduce the time it takes to deliver new integrations to my clients. Integrations are a lot faster, which is a big selling point, as it reduces cost on the front-end.

The developer can connect to the back-end services and exclude APIs through API Connect. It is very robust, e.g., I can exclude web services. We can paste the code into the UI interface.

Pre-built connectors are good if you need more security, though it depends on the extent to which you use them, as they are not necessary to use.

The solution is very simple and straightforward.

There is room for improvement in the reporting and monetization. With monetization, I want to be able to provide my own pricing and platform.

I would like them to add hooks into the API. E.g., it should be able to check credit, then limit access to people who don't have credit anymore.

They need to have more training for people. 

Since 2017.

There are issues with upgrading in the cloud version. The cloud version is extremely buggy. We prefer to use the on-premise version.

It's redundant so scalability is not much of an issue.

I would rate their technical support as a five out of 10. They are very slow. IBM has been working on this for three years. 

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

The initial setup and development are straightforward. The cloud is already available, so the development is what takes time. Deploying the cloud just takes clicking. It can deployed in minutes. The on-premise deployment takes two or three hours without issues to set up. if there are issues, it could take a day to set up.

It takes one person to set up, max two, as it is straightforward. There is not a lot to do. The system admin will probably spend one to two hours on it to maintain it.

It takes us a week or two to set up 50 services in API Connect. The only thing that might take extra time is portal design because that requires us to go into the back-end.

API Connect is quite pricey.

The developer builds the API and determines what should be put together. However, the business people determine the price.

The product plan and pricing needs improvement. It is confusing to the client based on the way a business might put it together. E.g., I have to be able to pick out different APIs, then group them together. I then have to explain to the client if they subscribe to this API product all the services available. Many clients want a variety of price groups based on their API selection.

I haven't seen anyone go from on-premise to the cloud. In fact, I am seeing people go from the cloud to on-premise because the costs can quickly grow on the cloud. 

If you want to small small, start with the cloud.

The integration is quite fast compared to others. Other companies combine their API platforms, but API Connect is as straightforward as you can get it. 

Oracle doesn't understand the different personas that need to be defined. This is why API Connect is superior to it.

Microsoft is extremely cheap compared API Connect. We are reviewing their solution in comparison to API Connect.

The client needs to understand the service to use it. They need to make sure that they have the back-end infrastructure to support API Connect.

API Connect is known for its light front-end system. Therefore, it depends on what system it connects to on the back-end. It is important to know how it connects to the back-end.

We are not using Cloud Pak, as it is still too new. We are using it in the lab.

I would rate the solution as a nine (out of 10). 

We are a financial services provider. We have services that we expose for things like investments, policy management, and so on. We have put this on an API Gateway to be able to aggregate all the things that we do for different types of clients with whom we engage.

The exception and error management have been the most valuable feature.  

We take steps for how many transactions we can create. It has a dashboard that allows us to see where transactions are coming from, which clients use it more, etc. This makes it very endearing for us.

I would like to see support for non-Java based services. We struggle a bit to be able to deploy and connect our .NET services because of things like data types. We had to map a couple of things. For one solution provider, we had to move them to .NET Core before we could use it properly. I would like to see more agnostic tool service platforms rather than moving it more towards Java or open source.

Two years.

It is quite stable. We've not had any problem. It has made for a good buy because we are finding that other companies that have similar set ups go down maybe once a month.

Our transactions has been escalating. We're doing an average of about 1.2 million transactions every week now, and it's stable.

We have not tried to scale it. If we go beyond two million transactions a week, we may find more reasons to start exploring scalability.

Right now, we have three clients. The intention is to be able to go to the big investment managers and insurance managers in our sector in South Africa to be able to onboard them. If we have our way, we should have 30 clients, not three.

We don't have a dedicated support with them. However, whenever we send an email, we always get a response back, sometime immediately but maximum 48 hours. They have been very quick.

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.

The setup could be made more simpler. We have had to deploy in three instances. The first one had a huge learning curve, though the second one was easier. We find that if we move environments, it takes time to set up. This should be made simpler. We need to do move our BI environment and we have not done that yet because of the setup time. 

The first deployment took almost five days. Right now, we are averaging around a day or two, then we are up and running.

We've played around with other API managers, like Tyk, and the setup is much simpler. 

The reason why we took IBM was because of its resilience and name brand. Our clients trust the fact that we are not just going for an open source or free solution.

One of the key selling points is the easy analytics to be able to analyze what we are getting. We played around with Tyk, but we didn't see any analytics with them. E.g., we tried to connect Tyk to our Microsoft Power BI so we could use that. This feature comes standard with IBM, that's why we're sticking to it.

We have not done extensive checks on Azure because our first client that we onboarded was Google. So, we never really explored Azure that much. In the next six months, we may be exploring Azure so we can have everything in the same space.

To cut down on your implementation time, read the documentation. It's long but explanatory.

I would rate this solution as an eight (out of 10).

We help systems integrators and vendors in choosing different types of platforms for building an open API gateway for banks. We evaluate and test different types of API gateways. We follow our internal testing scenarios to make sure that the product meets requirements. This is all we do.

API Connect is a very good platform for the development of APIs.

They seem to have left out a feature for microservices and also a certification module for OIDC. So it would be a good idea for the authentication module to have OIDC certification.

I have been working with IBM API Connect for about half a year. 

As far as I know, there haven't been any issues with the stability of the solution.

There are also no issues with the scalability.

We don't have any connection with IBM.

The initial setup is pretty straightforward.

I am also familiar with Xware and WSO2 API Manager. They have a different type of development cycle and features compared to API Connect. It's on the development side that they're different. It depends on the type of application.

I would recommend API Connect to a vendor or financial institutions that are looking at using it. It's a nine out of 10. It's missing the authentication module so programming and customizing that takes a lot of time.

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.

We primarily use this solution for the regulation of open banking.

It still does not support open API 3. Another problem is the designer. I want the whole solution to be on the cloud. For the installation, I have to install locally. There are many improvements it needs if I want to implement a MockServer or sandbox. In the future, I hope it will be more intuitive for building a MockServer.

In the next version, I don't know if they've already been included it or not, but the designer and all the tools should be on the cloud. I don't want any external installation or local installation. The old designer should be less complex and more simple or intuitive for you to search as well.

I found the solution to be stable.

The solution is very scalable because it's on the cloud, adding more resources to improve redundancy or performance is simple and configurable.

I've found technical support to be very good.

The initial setup was not as straightforward. Deployment takes a few days. You don't need too many people for the deployment and maintenance of the solution. 

We were working with IBM for the implementation.

We are testing and I'm working for the Bank of Israel and we have to implement the regulation of the PSD2, the open bank, open banking, open API. We would implement it on API Connect, so it's not a production system, it's just a sandbox.

In terms of advice, I would suggest anyone to verify that the product support is the latest version and to find out the frequency of the new versions of the product itself. I think it's very important to go through a project like this before implementation.

I would rate this solution seven out of ten. I'd like it to be more cloud-based, for the open API 3 because currently all the specifications are published only on the API so you have to downgrade it and then input it into IBM.

We primarily use the solution for distribution.

The technical support and the user interface are good.

IBM is also a bit pricey. On top of that, they have bugs that need to be fixed.

The solution is very stable.

The solution is not scalable.

Technical support is okay. I had to call once for billing. We also had a connection issue. They didn't answer very quickly unfortunately.

We didn't previously use a different solution.

The initial setup isn't too hard, but it's not easy either. We didn't deploy anything. We just added a gateway.

We used a local broker to assist in the implementation.

Right now, we are evaluating other options, including Axway, Apigee, and Tyke.

In the 2018 version, the setup is less complicated, but it takes longer.

I would rate this solution eight out of 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.

Building APIs.

Still working on it.

I have found the API Management to be most valuable.

Business applications could be exposed to users.

This solution is primarily used for workflow applications. Specifically, it is used for web applications with complex workflows that have many users.

The solution helps. We have Domino servers for all our web applications.

The ability for all of our web applications to share standard functions and documents easily is valuable.

Automation for our Domino applications could be improved.

We have been using this product for banking, insurance, and government use cases. Perfromance-wise it is very good. It has been improved a lot from the beginning, from API Connect 4, 5, and now we have the latest version of it. The product is available in various forms which gives us the flexibility to propose solutions to our customers.

Any new company starting with APIs, this product is very helpful for learning how they can export their business functions and data to the outside world. It's easier for them to expose their business functions for various use cases.

This product is well integrated with other products. Its ability to interact with IBM Secure Gateway and other products is the core feature. Also, the lead time to put it into production is relatively short and that is something customers are pleased with.

In terms of stability, I think it needs some improvement when it comes to externalizing the analytics data. The analytics collected with this product are part of the product database. If we could push the analytics data to an external data source, the customers could use it for historical purposes.

It is scalable.

Technical support is very good, helpful.

The setup is pretty much straightforward.

I rate this solution a nine out of 10. It has all the core features that allow any small company to start with the API calls. There are Essential, Professional, and Enterprise versions. The product is in many forms, like docker, for example.

I recommend this product. Take a look at it.

• API management
• Securing enterprise APIs
• Metering
• Throttling
• Transformation
• Analytics
• Deployment on AWS

• Single entry point for enterprise APIs
• Basic OAuth
• Keys management
• Policy configurations are pretty easy.

• Ease of use
• Security
• GUI is pretty intuitive.
• Easy to configure security and generate API keys.

Components, like caching, should be implemented as policies, not requiring dependency on an external solution. Apigee provides caching as a policy.

For on Premise Solutions:

Out of the box policies for Gatewayscript, JWT generate and validate. Oauth support .

Since it runs on top of Datapower, all Datapower based custom policies can be utilized and exported to API connect but its not straightforward/simple process.

Export of Analytics data in CSV format.

API connect is far better, faster and sleek as compared to IBM API management.

API connect support better error handling scenario with additional policies and catch node.

We utilize API connect to proxy to backed micro services or Datapower. We also do JSON to SOAP mapping / rest to soap apis, which is a very common pattern. We use it for any lightweight rest/soap message processing , analytic gathering and API usage policy enforcement.

IBM has improved this product significantly in last 2 years but it is still not stable and require further improvements. There are several issues administering the product. Features like , taking manual back up is still not available through GUI. The API manager cmdline is only accessible using one Admin account.

IBM recently added a feature to do autoback up in recent API connect firmware releases but its not very user friendly.Also the exported backup can not be unzipped and is not readable.

IBM info-center help documentation also needs improvement. Competitive product like Apigee provide out of the box policies to run Javascript, JAVA and better/flexible logging policies.

Apigee cloud provides various test tools where APIs performance can be tested from different regions in the world. As of now, as per my understanding IBM doesn't have similar test assist tools in Bluemix cloud .

Troubleshooting any issue is very difficult as it runs on Datapower so Datapower know how is required. Also you need to log on to multiple VMs/devices including Datapower to troubleshoot if errors are not properly handled.

IBM definitely needs to improve their customer support process for their new products as it demands more attention from customers because of large number of defects, long learning curve and lack of documentation.

1.5 year

We lost the old configuration during firmware upgrade of API connect.

IBM API management did have several stability issues, where working in different tabs in browser cause issues saving the configuration changes.

Also IBM API management is very slow and its inbuilt test tool is crappy as it takes around 1.5-2 mins to test any API after configuration changes.

IBM API connect is far better but we still haven't stress/load tested apis,so wouldn't comment on it.

One example of instability, We lost the old configuration during firmware upgrade of API connect.

For IBM API managment , some times config replication in Management cluster might take as long as 2 minutes so change in one API manager might not be reflected quickly in another API manager. Also API management GUI need to refreshed in browser to see latest state.

6

4

I have used APIGEE in a different project.

IBM infocenter for IBM API management and Connect is still not very helpful.It takes lots of reading and terminology know how to correctly configure it.

Initial set up was done by IBM but new VMs are configured by us.

Not sure.

Not sure.

No.

Troubleshooting any issue can be very difficult.

In-built policies and security functions.

Integration with DataPower as its API Gateway. Due to bugs in integration, we have to look for workaround on fixing and using DataPower as gateway. 

Have been working on this for three months.

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

Setup an "always and anywhere available sandbox" for experimenting and proof of concepts, because one will need to think and experiment much to use the tool.

It gives a holistic environment for us to set up the APIs and that's the main value that it adds. It gives end to end for us.

We moved from another manager to this one and latency has improved a lot. It has improved the latency response by maybe 20-25%.

In fact, we have had a discussion with IBM and it's agreed upon that they would give us the features that we have asked for, just in three months. We have asked IBM for scalability and for some other features that we wanted. We had a dialogue with them and in the end, they have agreed to provide us with features related to API setup and security. They agreed to give it to us in three months, so we are happy.

In regards to the stability, we are new to it, so it is OK right now. We haven't put much into it yet.

The scalability we have not tested yet; we are testing it now as we speak.

We do use technical support and are in constant contact with them. They are very good.

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.

I was involved in the installation process to some extent. I am from architecture, so usually the infrastructure team would be involved.

There are several other solutions that we evaluated but it depends on the capability that we are looking at.

Initially, we started off with one solution and then, moved on to another, as we found out that it's not helping us.

We do several things before selecting a vendor. It's not in my purview, but we do the product evaluation as well. Obviously, IBM is a big vendor and we are a big shop of IBM.

Go for it!

Getting a perfect rating depends on the product and how they give us support or not. We haven't gutted it, thoroughly. It is in production, but it's not perfected. Maybe in six months or more, we'll know more about it.

The most valuable features of this solution are:

• Integration with multiple services,
• Providing security,
• Being able to monitor, and
• Enabling customers using the secure gateway.

We belong to the healthcare industry, so it is beneficial to implement the API Connect solution to provide APIs that can integrate outside and inside our organization. It also provides overall solutions, i.e., API-based solutions to all the customers that we have.

I would like to see more caching and monitoring features implemented in future releases. It also needs to be a more customizable and flexible product.

In terms of stability, we are still prototyping the product. We have the older version, which is now stable, but the current version or the new version, that we are still prototyping, is still not 100% stable.

The scalability is pretty good.

We have used technical support. I would probably give them a 7/10 rating.

I was involved a little bit with the installation process. I found it complex, as there were lots of configurations involved in setting up the infrastructure and that everyone didn't have experience with.

We looked at several other solutions, i.e., both IBM and non-IBM products. However, since we had already used IBM DataPower, we thought we could reuse the same infrastructure. API Connect has DataPower built-in to it, thus we tried to reuse some of the existing functionalities.

The most important criteria while selecting a vendor are the product's support and operations.

Our company is an early adopter of this product so I would advise, at this point, to wait and then implement the solution.

The most valuable feature of this solution is to have the APIs available across different verticals in the company. IBM API Connect provides that capability for us, so as to expose the services as APIs.

It provides the use of services at a faster delivery; that's the main, important thing. It is less cost-effective.

We are evaluating the current capabilities. We have other products such as the IBM WSRR and we are trying to see how it fits with the IBM API Connect. So, we are just trying to evaluate it right now.

It needs to improve so that we can be successful in the company, as well grow the API footprints in the company.

We are using it for the last six months, so we haven't yet gone into production. We are hoping it will be a very stable solution.

Right now, it's not heavily used. So, we intend to use it in the next year.

Initial setup was very straightforward and not complex.

We looked at other solutions, namely Apigee. However, we didn't choose them; we are not taking it.

We have a lot of other IBM products, so it is much easier for us to have one vendor instead of multiple sets of products.

Go for it.

We are using the IBM WSRR solution for service-oriented active services. The API Connect is for lightweight services and obviously for customization purposes. We work with IBM a lot, so they recommended to us to go with the IBM API Connect solution because it is the future. That is why we have chosen the API Connect.

The main criteria while selecting a vendor is support, i.e., after we go live and not just from the product. A stable support customer trust factor is also a very important factor and that is why we have a lot of IBM products.

The most valuable feature for me is the ability to distribute work among our API developers, so we don't have to do all the work as IBM API Connect administrators and IBM DataPower administrators. This simplifies the way our partners can access our API's.

Overall, it brings us closer to better API management in our organization. The next step for us would be to improve the whole solution by going to the cloud. That's what I'm looking at.

It simplifies development and allows us to do more for less money.

Based on my meetings at this conference, I'm satisfied with their roadmap, where they're going. Possible improvement is mainly around having more of the cloud oriented architecture bringing stability in adding new capabilities around security.

Stability has improved greatly with the latest releases. There were some struggles in the beginning. There were some components that were not stable. They weren't behaving consistently through environments when we moved stuff from development to demo to prime. I think core functionality is pretty stable but there are things on the outskirts that weren't so stable.

IBM DataPower is at the core and we can easily add stuff as we need or as our licensing allows. So I think that it's pretty scalable.

The technical support is good. We got some help from their experts.

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.

The setup is complex but we didn't expect any simple things at such a large scale. It's just too many moving parts - IBM API Connect consists of three main components and they all have to be synced up. There's a lot of setup and networking and then you have to adapt it to your own environment.

Microsoft, IBM and CA Layer 7. IBM had the most capabilities that were based on IBM DataPower and could fulfill all of our requirements, even though the timescale was longer than we expected it to be.

When considering a vendor we just go for an industry leader, making sure that their technology stack aligns with our technology stack. We look at their reputation and how good the support is with the other products and what kind of relationship we have with account managers from that organization.

You should consider how much value you can derive specifically from the solution with all the features that are available. For instance, the main value for us was in organizing the API's and splitting work among several development teams.

Most of the business value that we are getting out of this solution, is that it provides DevOps integration and a catalog for microservices. We are able to share those APIs instantly within the organization; even if we want to share it outside publicly, then we can have those capabilities.

There is a trend to move towards microservice-based solutions, where we have to decouple all our legacy SOA-based services, when sometimes it takes an iterative approach to come out with what you need. Instead of that, we have this microservices solution, where you can just enable the required part in quick delivery using DevOps. These are the main benefits of this product.

Mostly, I would like to see more tools that are DevOps-friendly. We would have more capability to interact with the catalog and inventories, so a more DevOps-friendly solution is needed.

Stability has still not matured. We are still growing with the industry. We will find out after some time how it is going. But, as of now, it's stable.

Right now, in terms of scalability, everything we have is on-premise. However, we have this Bluemix capability, with which we can scale as and when we need.

We have used IBM professional support/premium support. We use them for any of the solutions, such as if we need some guidance on the future roadmap as to how it's going, etc; we engage them. They are excellent. They are always not only there to help us resolve the problem, but also to be able to guide us as to how the trend is going and what we should start thinking in regards to those changes.

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.

Advice depends; if you have a preferred technology and IBM has a solution for that technology, then I'd definitely advise you to use more microservices with the API Connect and the DevOps, to provide quick returns for your business. It will be more valuable to you.

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.

I think the most valuable feature is the fact that it sort of combines IBM DataPower being a security gateway with some of the features that are in IIB and IBM App Connect, to kind of build a complete integration. Also, IBM API Connect being the API gateway is extremely valuable both for internal and external consumers of APIs. Off the top of my mind, those are the big points that I would add.

For full transparency, at this point, we brought the solution in and we've used it for a couple of internal hackathons, but we haven't actually used it for any production work yet. Like any bank, it's really forcing a transformation in the sense of the whole industry related to cloud and related to connections to the outside. We're really trying to figure out, internally, how we want to define that.

Some of the other growing pains we've had is, how do we operationalize the technology in the sense of ownership internally; to say, which different groups should actually own which component and how we control the security across that. Personally, my side of the house, which is being responsible for delivering solutions on behalf of the businesses, I'm ready and anxious to get going on it. I'm very excited about the possibilities that the technology brings.

I think that some features that would be kind of cool are around the whole idea of a subscriber being able to subscribe to a plan. Not only should that plan include the number of calls per month or per week or whatever but also, I want to subscribe to a plan with an SLA, which gets into response time of an API call. If the response time in the plan that you subscribe is like 200 milliseconds with a 99.9% guaranteed delivery, then I should be able to subscribe to that plan and then be able to go into it and actually see how close I am to adhering to that.

Internally, this makes for some very interesting conversations right around going from application to application, issuing a connection and they're saying, "Hey, well, we're going to make this many calls a month and this is what we need the response time to be." You could literally say, "Well, we're hitting the SLA." Or, "We're not hitting the SLA." Externally, I think you have the same sort of commitments and when you're negotiating contracts, especially on the larger business partner connection, with the business-to-business connection conversation as well.

Given the fact that it's not operationalized, I cannot really comment too well on the stability because we haven't really had to worry about the stability yet. I'm not really in a place to know. I've heard rumors that there are occasionally some issues related to how it maintains connections with its other pair, but I don't know enough to know.

Based on the architecture, from what I've heard, it's quite scalable. It's just, bring in more nodes and away you go. My understanding is it’s very scalable.

Personally, I have not used technical support.

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.

I was not involved in the initial setup.

I do believe that there was an RFP process that we went through as part of the selection for this tool. I do not know which other vendors were on the short list.
Usually, our vendor selection process is quite rigid around that. Everything comes into play. Of course, there's cost but then there's, how well it's going to be supported. What does the product roadmap look like? How well does it conform to our internal technology standards? How well will it play within our environment? There's a lot of stuff there.

I think if you're working with IBM and you're looking at possibly using Bluemix now or in the future, the other thing is, if you're using IIB or you're looking at Salesforce, there are a lot of synergies related to these platforms and this tool set, so it sort of makes sense to head down this road.

Personally, if you're a small startup, you might need to evaluate the entire landscape a little bit differently, but if you're a large enterprise and you already have a pretty big relationship with IBM, I think that it makes a lot of sense.

My rating reflects the fact that it's not operationalized at this point, and that's not entirely the product’s fault. I see a lot of potential, but there are still some things that need to be there.

As far as API Connect, I think it offers us more flexibility with our application and potentially would allow third parties to come in and develop for us. It also enables us to streamline our microservices journey.

The main thing is that it just makes app development a lot easier.

Stability.

It was a fairly new product so there was, so it took a year or so to really stabilize. But now I'm happy with the performance.

No problems.

It wasn't me that did it personally, but I would say good. We have a good relationship with IBM.

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

Fairly straightforward.

Yeah, I can't recall the name, but we are an IBM facility, so we just figured it made more sense for us to go with this package.

When selecting a vendor, trust is important, as well as that they deliver. Just someone you can be comfortable with.

I rated it an 8/10 because it's not fully mature yet.

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've yet to realize real value in the solution. The goals that we were trying to achieve from it were to implement microservices and a lot of the features and functionality that were part of the documentation, but we haven't achieved success with it yet.

The benefits would be that we'd have a great platform for our microservices and API management. But since we haven't had a lot of success with it yet, it's been frustrating.

I would like greater stability and greater ability to actually administer the product without needing to go to technical support. It's very proprietary and support has secret passwords that they use to get into certain functions.

IBM has limited the capability for executing typical admin commands and only provide a small list of proprietary commands. Without a secret command line password, clients are limited to what they can view and administer – even in a read-only mode.

Stability is not good.

Scalability is good.

I would rate technical support fair, at best.

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.

I was involved in the initial setup and it was somewhat complex; medium complexity.

We didn’t look at other vendors.

Certainly look at other options that are out there and absolutely go with the latest and greatest version of the product, because there have been a lot of issues and it's going through growing pains. It's not completely mature.

I like how it runs within DataPower, and adds the extra OAuth security. It gives me a common place to do security for all my API services.

The biggest benefit is the availability provided to the people that will use my services. They can go to a portal and look for services to identify which ones they'll use.

We use it for existing IIB services. We call on multiple back ends from the same service where the record layouts are different. It's difficult to describe and use them in the product.

Actually, we're in production for demo purposes, so I really can't speak to this. So far, we've had no issues.

We have used technical support and we have a good response.

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.

I was involved in portions of the initial setup. It was complex from the standpoint that there were a lot of components, but it wasn't difficult.

Make sure to understand its purpose and what it's used for and not used for.

• 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.

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.

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.

The seamless conversion between rest and soap and service catalog.

I am a consultant so I can explain how this product has improved my customer's organization: it has made it very simple to expose new services securely with a specific general policy in DataPower and also keeping track of their use (amount of calls, etc.).

Integration with Exchange Server. Also if it could be easier to configure or direct the DataPower policies that would help. I'd like to see a combo box to choose which processing rule to apply.

I've used it for a few months.

Only issue is with connecting it to Exchange Server.

No issues with stability.

No issues with scalability.

I did not require the customer service.

I did not require technical support.

It was an addition and not a substitution to anything.

It was straightforward.

Seems good so far, as it saves a lot of time. It used to take a long time to expose services, whereas now it's just a few clicks.

It's pretty simple, there's no need for any special advice actually.