Apigee Reviews

My current job is to compare all the different API gateways and to create a report for management. We use this tool primarily to secure our API. We have a set of API from our four businesses and we're trying to apply these APIs to multiple applications. For example, third parties can leverage our APIs built to their own solutions and applications and we build applications on top of these APIs. I make the system available like a mobile app. Primarily the API management for the entire ecosystem of AP that we are building and the DGPS are providing, have varied capabilities across the organization. Apigee also acts as a proxy, everything is done within that. 

We also leverage the developer portal of Apigee as a main feature, which can be given to outside customers by third parties to build their own applications around our API. One of the standout features of Apigee is the different PolyPhaser functions that we use. For example, we use throttling, encryption/decryption and we also use external AP integration with PV.2 I'm a senior architect and big data engineer and we are customers of Apigee. 

I like the functionality of this solution. 

The cost of this solution could be improved and it would be better if it were on private cloud. 

The solution is stable. 

The solution is scalable. 

I'm not directly involved in the technical support aspect, but I've heard that the technical team is excellent. They provide support from the beginning until you completely run all your setups.

This solution is much easier to set up compared to any of the other API gateway solutions. There is extensive documentation available.

I would go with Apigee if you have the money. It will give you enough APIs for management. If you're looking simply for one functionality then I wouldn't recommend Apigee.

I would rate this solution an eight out of 10. 

It is a Google cloud solution for API management and analytics.  

I have not had the opportunity to completely explore the product's capabilities in the time that we have been using it. But I can say that the customization is really vast and it is a really good feature built into the product. I can customize different authentication methods and methods for authorization. I can also use redaction. So security is flexible to our needs and it works well.  

It is a user-friendly solution, but it would help if Google could provide a container-based solution instead of just a standalone one. With a container-based deployment and support for Terraform, it would be better for our deployments and that would be great. Right now we have to configure different areas manually. Some areas can be automated, but the deployments are not as fully automated as they could be otherwise. 

so, they currently have a software as a service offering or a standalone offering. I want to see something like a hybrid cloud deployment. I also want to see a private cloud deployment. 

We are still building out the environment. We are running four environments until we accept that it is fully tested. So we are not live yet and we will really go live and into production sometime in the first quarter of next year. But we have been using Apigee within the last 12 months for testing purposes.  

The scalability of the product is good. Our use case is right now is applied in only one environment. When we are about to go to production, we will probably do high-availability testing with a dual environment so we can come up with any potential scalability issues. But for now, we have not really touched that area in our testing.  

We do have a lot of people using Apigee already. This is the primary gateway for us to talk to external applications. I would say that services around 800- 900 applications which are using the gateways. That is also involving many teams and end-users who access those applications.  

My recommendation for installations is that the product installation, set up and delivery process could be improved. It is straightforward in the initial steps. The part which is automated by Google is very straightforward. The remaining part, we have to do manually. The remaining components have to be manually configured. If Google were to do a container offering of this solution, then adopting it would be seamless because everything would be able to be automated.  

I would say that it currently takes too long to set up and deploy and that it is not as short a time to complete the process as it should be. It is more mediocre, somewhere in the middle, and has moderate difficulty instead of being seamless and simple.  

We did not have to use an integrator, reseller, or a consultant for deployment. It was all done in house by our own teams.  

We tried Axway API gateway and we also tried MuleSoft. We found that these solutions did not fit our scenario as well as Apigee because our scenario is a very special scenario where we want to keep everything that we already have on board. In our current situation, we have big AWS (Amazon Web Services) accounts and a big AWS footprint. So we want to also be able to use AWS for Apigee hosting. That is where our environment and needs become a little bit of a custom scenario. Apigee works for us in this scenario and that is why we ultimately went with Apigee over other products.  

I would definitely recommend this product over any other products available in the market in this category. It has all the features necessary to work in anything from a basic scenario to advanced applications. So I find that everything in it is flexible and available in this one product. Because of that I highly recommend it to anyone.  

On a scale of one to ten (where one is the worst and ten is the best), I would rate Apigee around an eight out-of-ten.  

We primarily use the solution for all of our security. There are a few use cases for us where we use it to protect API to third parties.

The solution, overall, is quite good.

The product has a few restrictions I'd prefer weren't there.

We have trouble finding use cases. For example, when we google "data locator" we can't find a use case scenario at all. We can't find more than, approximately, five use cases, however, we need more.

We needed to do more than 20 configurations, and we weren't able to do that as the limit is 20 on the solution.

The solution tends to hide the limitations to keep selling the product. I can't blame them for doing it, however, it makes it difficult for those of us who eventually sign on.

The solution is expensive.

I've been dealing with the solution for close to three years at this point.

The stability of the solution is good. There aren't issues surrounding bugs or glitches. We don't find that it crashes or freezes. It's pretty reliable.

The scalability of the solution is okay. If a company needs to scale it, it should be able to do so.

Currently, we only have about ten people on our team that use it.

We haven't found the technical support to be that good, to be honest. We're not completely satisfied with the level of service.

We're currently using IBM Connect as well as Azure. Functionality-wise, there aren't too many differences. One is on-premises, however, therefore it's really difficult to compare both together. With IBM, you have to maintain a few more things. There are more administrative tasks.

The initial setup wasn't straightforward. It was complex due to the fact that Apigee didn't have any integrations and we had IBM APA Connect Resources.

There were many things we weren't told earlier. Once you clear certain items you can't change the name, for example. There were a few other items, like monitoring, which had a limited number of configurations which was an issue.

Deployment was fairly quick. It only took five minutes or so.

The solution is not a cheap product. Licensing can be quite expensive.

Our contract is around $2 million for three years.

We don't have a clear picture how the billing works. We have one service package of one size and yet we don't have a clear picture of the purchase or the status or if they will charge more due to earlier limits on services. The solution needs to make licensing more clear. Even if they charged us $10,000 or even $20,000 more but they were clear about the what and the why, we'd be okay with that. We'd just like to know.

We're just a customer. We don't have a business relationship with the company.

We are removing our IBM products and transition completely over to Apigee.

We have Azure's API as well. In next one year or two year, we are going to dissolve IBM API Connect as well as Azure CIM and move everything to Apigee.

Overall, on a scale from one to ten, I'd rate Apigee at an eight. We'd rate it higher, however, they aren't clear on their offering. We just want everything automated and easy. The cost is not the issue. The lack of information is.

I'd recommend the solution. It's a nice product and companies should go ahead with it, so long as they are okay with the pricing, as it is rather expensive. If a company is cost-consious, IBM API Connect may be better as the licensing costs are lower.

We've got quite a large technology footprint and I'm looking after the integration of our banking platform with our payment systems.

The REST API allows for faster user engagement.

The flexibility allows you to quickly run a cloud-native application architecture.

The ability to work across different management solutions in a plug and play fashion would make it easier for faster uptake.

Pricing is an area that can be improved, as it is a little on the higher side. It is more expensive when you compare to open-source products or other vendors.

I think it would be helpful if Apigee had support for voice-activated activities, rather than having to type.

More intelligence in terms of being able to learn from previous activities would be a good addition in the future.

I have been using Apigee for about two years.

Apigee is used on a daily basis in our payment systems.

It has performed relatively well from a scalability perspective.

We have about 15 users in the company. They are a mixture of engineers, architects, and administrators, with the majority being architects.

In cases where we have a problem and need support, we have an agreement in place with the vendor to help us navigate through it. They are good and respond to our issues quickly.

Apigee was our first choice for this type of product.

The initial setup is of medium complexity. End-to-end, we took about a week to get everything ready. This included the account, the proxies, the target endpoints, etc.

We received assistance from the vendor for our implementation.

Our in-house team is responsible for routine maintenance. This includes backup support, uptime support, patching, applying of certificates, etc. It is an ongoing activity and we also work with the business to continuously improve the integration, so that they are getting the value of the capability of Apigee.

My understanding is that there are costs in addition to the standard licensing fees.

My advice for anybody who is considering Apigee is to first do research and an analysis of what they want to use it for, including specific use cases. It is a good tool but it is important to have well-defined requirements to avoid a high implementation cost and rework.

The requirements have to be very well documented and understood by all parties, especially those who will be involved in implementing it. Following this approach is an important step to getting a good return on investment.

I would rate this solution an eight out of ten.

We are using Apigee as our API gateway.

The most valuable features are scalability and technical support.

The definition of the APIs should improve because you can't easily validate the inputs and outputs. Better functionality for validating inputs and outputs would be helpful.

I have been using Apigee for four years.

We are working with a SaaS model and we install the on-premises model version also.

Apigee is a very stable product.

The scalability is incredible. We make an average of 22 million API calls.

We have less than ten people who are developers.

We have plans to increase usage in the future.

The technical support is very good and we are satisfied with it. They respond very quickly and I like it.

I have used several solutions previously, such as IBM API Connect, WSO2 API Manager, and many other API solutions.

It is not suited for small companies. It's expensive.

For a bank, it would not be expensive, but to implement this solution for a smaller company such as an insurance company, it would be too expensive.

The pricing is complicated and not flexible.

The older versions are more suited for small to medium-sized companies. You can no longer pay €20,000 per year.

This is a very good API tool.

I think that this solution is very good in some use cases but not very good for some small companies. It can be complicated for licensing and pricing. This is a product that I can recommend otherwise.

I would rate this solution an eight out of ten.

We are a solution provider and this is one of the products that we implement for our clients. We also it it ourselves.

Our use case involves accessing functions on our backend systems through a portal used on mobile devices. The app on the mobile device uses the internet portal, and we have the API as a security layer to pass the functions through to the backend.

It is very easy to implement and the configuration of the API is very simple.

It is easy to upload a Swagger file and build an API.

The user interface for building APIs is very simple. Anyone with basic knowledge can build an API.

Disaster recovery capabilities are included.

Apigee is demanding on the infrastructure so the setup cost is very high for an on-premises deployment.

We have been working with Google Apigee for almost one year.

Apigee has high availability and we have not faced any problems in regards to stability.

We have not had to scale as of yet. Our license allows for 125 million messages and we have not yet reached that stage.

We have been in contact with technical support and we are fully satisfied. I would say that they go out of their way to support us. For a priority-one issue, Google commits to having it resolved within 24 hours.

There are also community blogs where you can find other people that are working with it. These are independent sources and people where we can get information about implementation as well as customization.

A new version is released every six months and if we don't upgrade in one and a half years, the old version will be deprecated or be out of support. For example, they recently upgraded the Edge UI. The old one was not integrating with Active Directory to allow for centralized control of users. However, the new one requires authentication from ADFS before implementing it, which was a feature that was previously lacking.

The entire set of documentation is available online. You can follow it step-by-step to install the application.

We have an in-house team that handles deployment and maintenance.

It is administered by two people and we have another person to handle the analytics.

The cost of the licensing is based on the number of API calls that are made. This is good because we don't pay for the number of nodes that we are installing. They also do not charge you for non-production transactions, which is extremely good.

Everything else is included as a package. For example, ZooKeeper, Cassandra, and PostgreSQL are part of the product, so we don't need to purchase any additional licenses apart from the OS.

We had evaluated Software AG at the same time as Apigee. The initial setup cost for an on-premises deployment of Software AG is less than that of Apigee. For example, if I require four cores to operate Apigee then it would be a two-core system for Software AG.

We chose Apigee because of its high availability and disaster recovery. Google Apigee uses ZooKeeper with an unstructured Cassandra database. This is different from Software AG, which uses a structured database like Oracle. Having to purchase Oracle licenses increases the cost.

My advice for anybody who is considering Apigee is that it is has a very easy and intuitive GUI to build APIs, and I can also import Swagger files. It is built on a high availability model, so if anything goes down then another node will automatically take over. We can build an active-active across the DR site.

The primary site is active, the DR site is active, and they are synchronized. It is easy to build, customize, install, and implement.

The support is also extremely good. We get immediate responses and support is available every day of the week. Google commits on the resolution time for priority-one issues as 24 hours. No other software today can commit to resolution time. I have only seen such a service with Google Apigee.

Overall, I am satisfied with this product and it is aligned to all of my needs.

I would rate this solution a ten out of ten.

The primary use case for this solution is to integrate both external applications as well as internal applications. We use some to integrate other applications, but most of them are just proxies that are for fronting the backend APIs.

We want to create one API to be used by different clients. In terms of management, even though the proxying of an API is not a lot of work, it is better to create a single API that can be reused. When the API version changes, you only have versioning for a single API, rather than in several places with the same capability.

Moving forward, if you change or update the version, the underlying functionality of the application needs to fashion the APIs correctly. This solution is created for the same capability. To prevent that, we just create the same API, and then we productize it and you are versioning a single API and not going back and versioning different APIs that do the same thing.

One of the concepts offered with this solution is called Productization. This concept allows you to bundle the APIs together and present them to clients as products, which allows you to configure the API with restricted access for different clients. An example of this would be Client A is granted access as read-only and able to do a few updates, whereas Client B would have full access to the APIs. You can configure different products for them in such a way that one of the products would have limited access, and the other would be granted full access. You are not creating another API, rather you are using the same proxy with limited access to the proxy. This is one of the features that has helped us a lot. 

We have APIs that we use internally and externally for clients outside of our network using the cloud with a SaaS solution that needs to access our API. The same API we use internally is the same API we expose externally. The level of security is different for internal applications and for external applications. To accommodate both we use the same API but add additional security features to the APIs.

The number one area this solution could be improved is by implementing support. Support is not a part of this solution.

I think that this solution is pretty stable, but when the open-source vendors upgrade their software, Apigee doesn't conform with the upgrade of the open-source vendor. They require patch releases and an upgrade for on-premises users. The component is always late.

I think it's pretty scalable. Currently, we are doing about sixteen million calls per quarter. As we are not using it on a large scale, we don't usually have latency issues whatsoever. We have a clustered environment and there is little to no downtime, even when we are running patches on the operating system. We have between twenty-five and thirty regular developers that use this platform. We have four nodes in the cluster that are serving internal traffic, and then we have another four nodes for external traffic so that way we don't really require any upgrade.

At this time there is no immediate need to scale up the environment. We have four servers with four nodes in the cluster that service the internal traffic, and we have another four gateway nodes for the external traffic.

The support is lacking. One of the main reasons it is lacking is because they have different applications bundled together. As an example, they are using Apache ZooKeeper and Drupal from different open-source vendors. We have two critical security updates that require support. A claim had been opened in May and did not receive any support.

Compared to other vendors that we deal with, I would have to rate this solution a five or less in terms of support.

We are currently looking for other alternatives because of some issues we are facing.

We believe that they do not want to continue with their on-premises version of the product, as they are not responsive to support cases.

We have MuleSoft, but we are only using their ESB, not API management. Apigee is the first solution we are using for API management.

The initial setup is not straightforward. It is very complex. They use different open-source applications in this solution. When installing this solution you have to be knowledgeable in the different applications, what the different applications do, and how they behave with each platform.

The documentation they have available is very good and available online.

Using different applications bundled together in this single product makes the maintenance and installation a challenge. 

The deployment took three months. We had many different environments including development, test, QA, and production environments. For the QA and production environments, we had both an external and an internal gateway. We did this ourselves in conjunction with the Apigee team.

Most of the maintenance is being done by two of our offshore colleagues in Chennai, India. They maintain the platform.

It's a good return on my investment. In the past, we were struggling with the way we would interface with external clients, where we would open a firewall and do many network-level configurations before we were able to open an API. Now everything goes through Apigee and we only open the first ones for Apigee. After that, all other communication goes through Apigee.

We evaluated three different products, including API management from Apigee, API management from CA, and MuleSoft. This evaluation was three years ago, and at that time the Apigee platform was more mature than other platforms.

For on-premises I would not suggest this solution. Generally speaking, the product is a good one, it is matured and the features are okay. If anyone wants to use this solution they should first consider the cloud-based version.

Because the support is lacking, we would have considered a different product. I would rate this solution a seven out of ten. If the support was better, I would have given them a nine.

We primarily use the solution as API Management, as both proxy and security.

The solution has improved our company's time to market. When we deploy a policy for a particular API, the creation of the policy and the gateway is significantly faster than what we were doing with our Layer 7 gateways. It's easier to develop the policy and to walk through the policy using the Apigee interface.

The ease of creating policies has been the most useful of the solution's features. It's a quick ramp-up time. It's easy for our support staff to implement the policies in the API management layer.

The company needs to better support webhooks. It used to support webhooks and their policies and they have since stopped. They had some issues in the product and they abandoned the support for them. It's not come back since. Webhooks are still used by some of our production partners. It would be nice to see the support for them come back. Right now, we have to pull the API instead of using a webhook to do the notification.

With Apigee, there are frequent updates, so they seem to have a very strong user base. 

There's a lot of users in Layer 7 too, but we've had some bad experience with support from the company. Stability-wise, it's hard to say. I don't think we've had any bugs associated with the gateway itself where the gateway has failed, but we've had support issues from Layer 7. 

In comparison, Google and Apigee have done a fantastic job supporting their product.

Scalability wise, I've heard from some customers that Apigee has some limitations on scalability, but we haven't experienced those as of yet.

As far as Layer 7 is concerned, it seems that the policies are very deterministic as to how the actual gateways function. Some of them have had a significant impact and we've had to scale up their clusters just to support a minimal load. Some are disappointed with the number of services that we have to engage for Layer 7, and the number of clusters we've had to create. We've had to create a pretty large cluster for supporting some applications.

The Layer 7 gateway's front end is for a high-end brand product. We have the largest loyalty program in Canada. Our PC Optimum program, for instance, uses our Layer 7 gateways. There are 14 million users that use the PC Optimum card that goes through those gateways.

The initial setup of Apigee is straightforward. Google/Apigee gives us all the information to support their private owned clouds. The interface is very straightforward to use as well. It's a lot easier than the Layer 7 product.

CA was overly complex in its configuration. CA also does significantly more as far as security and policies are concerned. It has developed a huge number of policies into their product. It's way more than what I would expect an API management product to be. It took us two months to set up the solution.

We basically took the policies from Layer 7 that we had previously created and we transformed them to policies for Apigee. That was fairly easy.

In terms of deployment, we haven't transformed totally from Layer 7 yet to Apigee. Our support is very low on Apigee right now. There's only one person that's working on Apigee currently. It's minimal. Accenture is handling the support, as they did for CA. We had about five people supporting the gateways on Layer 7.

For Apigee, we had the assistance of an integrator. The company was Accenture, and we have a good working relationship with them. They're currently supporting the platforms in many facets. The deployment was straightforward, so they didn't need to do too much.

There was no specialization or skill required for them for Apigee, but there was with Layer 7.

We looked at a couple of other vendors. We looked at offerings by Red Hat and some others. We basically looked at the market leaders.

From an enterprise point of view, our digital division had already migrated to GCP. GCP uses Apigee by default. They had selected Apigee initially. That was one factor in choosing Apigee over CA. Another factor is that it would support on-premises and it would support our Azure environment as well. The ease of use, creation of the policy, and the developer portal experience were all factors. The fact that developers could easily create the policies themselves without having to get our administration staff or engineers to actually create the policies was a big factor as well.

Right now, we are still in the process of testing the solution. We're using both on-premises and cloud versions.

CA has developed a sort-of enterprise service spot inside of their API management platform. It does interesting things with files, and it has a lot of security features that are not normally used in a majority of API calls. It's overkill. Its portal is very clunky and very difficult to set up. Its gateways and its policies are not straight forward either. It basically requires a three-day class to understand how to get in and add policies and it's not very simple to add policies into the CA Layer 7 gateway. Apigee does a way better job. 

CA is also owned by Broadcom now and when that transition happened, Broadcom did a lousy job of handing off support of that product. They basically fired everybody from CA. They left us without production support for a good part of a year. We've had CA for about 2 years and mostly we used the on-premises version, but we had a small amount on the cloud as well.

Because of these reasons, we're moving away from Layer 7 to Apigee.

In terms of advice to those considering using Apigee versus CA, I'd say they need to understand their use cases for APIs.

I would rate Apigee eight out of ten.

In comparison, I would rate CA five out of ten.