Apigee Reviews

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.

I use Apigee to design the proxy and rebuild the pilot, which becomes the API developer's design. This saves time and money for the customer and Rapid7 and 8 by simplifying the process of synchronizing and obtaining actual IDs. 

Apigee is the tool we use to test the API.

Apigee provides good documentation.

The pricing is reasonable.

Apigee's certification is beneficial.

I like the customized tools included with Aigee such as CI/CD.

Apigee integrates well with Kubernetes, Atos, Jira, Microsoft Teams, as well as ServiceNow.

I'm not a fan of the developer portal. It should be simplified. There is an excessive amount of customization required. 

When compared to Azure, Azure is more user-friendly to customers.

Monitoring could be improved. Google Cloud provided better monitoring than Apigee. 

I still prefer monitoring in Azure or Anypoint MuleSoft.

It also requires additional tools to assist in the deployment of Apigee.

I would like to see the monitoring, dashboards, and reports improve.

I have been using Apigee for five years.

I am working with version 8.

Apigee is a stable solution.

Apigee is a scalable solution.

Technical support is very good.

They resolve issues quickly.

I have experience with many different platforms such as Mulesoft and Microsoft API Management.

In Azure, I use Azure DevOps and with Mulesoft I use Jira.

In my previous location, I partnered with Microsoft using Azure in API Management.

The initial setup was straightforward, however, when compared to MuleSoft, MuleSoft was easier.

QMance, C1/CD, GitHub, GitLab, and Jenkins were among the applications we used to manage Apigee deployment.

We completed the deployment ourselves.

The north direction used in SolarWinds and MuleSoft is the same as the north direction used in Azure and Azure DevOps for solution and system deployment.

From my perspective, Azure and Azure DevOps are the appropriate solution and system deployment tools.

I like the deployment and customization in Apigee.

The deployment process is a  scheduled tool on the file. In my opinion, testing the tool is important during the development process. However, in Azure, I haven't seen any tool testing. Therefore, I need to test the tools for the testing and deployment process. In IT, I require sales tools to test the APIs.

it is necessary to have two forms for testing, and I see the testing tool in MuleSoft, but in Azure, I haven't seen any testing tool. I need to test the tools for the testing and deployment process.

In IT, I need the sales tools to test the APIs.

Licensing fees are paid on a monthly basis.

The prices are comparable. It is comparable to MuleSoft, WhiteCloud, and other similar applications.

Apigee X improves the connection series by solving a different problem for me. It refers to service connections.

Apigee is something I would suggest to others. It has good documentation, is simple to install, has great support, and is a good testing tool.

I would rate Apigee a seven out of ten.

The solution is used for exposing the APIs mainly.

The organization has benefited from the development of fast, new APIs and new integration points.

The usability is one of the best aspects of the product. It's broadly used in different functional areas. There is no specific one. It's used broadly almost in all the contexts that we have.

It's easy to set up.

Technical support is helpful and responsive.

The stability is great.

We started using the solution not so long time, however, it still started from scratch. So far, we have no improvements to note.

The solution could add even more functionalities. 

I've been using the solution for two and a half years. 

The solution is stable and reliable. There are no bugs or glitches. It doesn't crash or freeze.

We have 20 to 30 people using the solution. 

We've used technical support in the past and they were pretty helpful and responsive. 

We previously used Mashery. We switched as Apigee was working better.

It's easy to set up the solution. It's a SaaS. The deployment can be handled by just one person. It's very simple. 

We did not use an integrator, reseller, or consultant for the deployment.

I'm not sure if we've seen an ROI.

The licensing cost is quite in line with the other solutions. It depends on which perspective you see it. It could be affordable or expensive. It depends on the company. For the big companies maybe it's more affordable, for the smallest ones probably not.

There are packages that you can buy or add-ons that you can add, depending on the usage, depending on what you have to do with it.

We did look at other options, however, this solution was more fitting for the purpose that we had.

We're a customer and an end-user.

I'd advise potential new users to understand if there is a fit as a product like this is pretty much covering the same functionalities as others on the market. There are not so many huge differences. It depends on what you have to do and what your capabilities are and what your vision is. 

If you need more freedom, you can use other things like Kong or other products. Usually, all those products, at least the big players on the market, have the same functionalities. At that point, it's just a matter of questioning if the product is fitting the needs and the purpose that the company has or not. 

New users need to question what they want to achieve and how they want to achieve it, how they're structured if they're working on the cloud or if they're working on-premise. They have to make some questions about the needs, the wishes, and the setup that they want to have.

I'd rate the solution an eight out of ten.

I work for a medium to big size IT consultancy firm in Mexico, and I am in the innovation and interoperability division. Our main work here is to develop projects on interoperability platforms and KPI management, et cetera, and transition from a legacy system to micro-services. In the last year, I have worked on a project on migrating a very big telecom firm from several API gateways and API exposures to Apigee. They're centralizing all their API gateways into Apigee.

We are hoping to lay out the plan for migrating the first sprint of about 200 APIs starting in January. Originally, the plan was to start in December, but the project is so big that it was suffering from delays.

We are going to start doing the actual proxies and migration in January next year. The project consists of about 10-month long sprints. We are going to use all of next year on this first phase. During the course of the next year, we are going to lay out the plan for the next phases. At this point, the total number of APIs to be migrated to Apigee is not clear, but we're thinking that it's about 300, 400 APIs that are going to be migrated.

The solution is deployed on-premise. They're thinking that in the second phase, they're going to go hybrid to have some of the features in the public cloud and some in the proprietary. 

We are integrators.

I think the most valuable features are the security features. Of course, the user access control is the same as the security. The other very important issue is the sandboxing capability of Apigee.

The caching capabilities are somewhat limited. This is more on the developer-oriented capabilities.

At this point, we aren't sure of what else could be improved since we are migrating some pieces of code that are really legacy and really difficult to model as a standard REST API. We are not sure in which areas Apigee is going to fall short. I think that next year we will have a more clear picture of some issues that we are going to find that could be addressed by a new feature, or by enhancing some existing feature in the next versions of the tool.

I have been using Apigee for one year.

Right now, in the development area of Apigee, we have about 20 developers, architects, et cetera. We are in the process of training because our expected growth drives us to have about 100 developers by the end of next year. I think that by the end of Q1, next year, we're going to double our capacity. By mid-year, we have to have 20 more, and so on, until the end of the year. We are planning to have about 100 trained developers, or configuration experts, in Apigee.

All the infrastructure, the enablement, is being done by another company. They are in charge of all the dimensions and actually creating all the infrastructure to host the platform. I have never installed Apigee as a proprietary cloud. I have been working either on the pure cloud environment or hybrid environment. I didn't phase the deployment of the tool, just the configuration.

In Latin America, Apigee is expensive. It's not for small businesses; it's more for big businesses. That's why I was trying to compare, for example, WSO2 against other API management tools. We are trying to create an inside practice in our company to also recommend WSO2 for a mid-size or small-size company where maybe the Apigee pricing for them is too heavy.

Apigee prices are targeting medium to large companies in Mexico. In Latin America, it's basically the same.

I would rate this solution 9 out of 10. 

I think the correct roadmap should be first an approach to Google to create a partnership. Then create a team of developers and an architect, and then start adding more resources as the demand grows.

We use it for access. for example, if a third-party needs access, they can get it via Apigee.

It's good for development. 

We like that the solution offers easy integration. 

It has a good UI and is user-friendly.

The solution scales well.

It's stable. 

The solution is pretty expensive. 

I've been using the solution for around one year. I haven't used it for that long just yet.

The solution is stable and reliable. the performance is good. There are no bugs or glitches. It doesn't crash or freeze. 

The solution is quite scalable. We can expand it if we need to.

We do not have plans to increase usage at this time.

Support from Google has been good. We've had several people help us, and they have been responsive. 

Positive

The solution is mildly complex in terms of the setup process. However, it isn't too bad. 

We have five people that handle maintenance tasks. We have one manager and two developers that can support the product.

We received training from Google, which ensures we are able to deploy it properly.

The solution is expensive. You can do some negotiation which might help mitigate some costs.

We did not evaluate other products before choosing this solution. 

I'd recommend the solution to others. It is costly but good. 

I'd rate the solution eight out of ten.

I use Apigee as it is an API gateway.

The live tracking API feature of the product is Apigee's most valuable component.

I don't see any problems in Apigee where improvements are required.

Apigee is not a solution compatible with public clouds, making it one of its shortcomings where improvements are required.

In the future releases of Apigee, I would like it to offer more cloud compatibility features.

I have been using Apigee for four to five years.

It is a stable solution.

It is a scalable solution.

Apigee's technical support is okay. My company did not have any issues with Apigee's technical support.

I rate the technical support an eight out of ten.

Positive

I haven't used any other solution before Apigee. My company chose to work with Apigee since it offered an enterprise edition, making it an easy-to-maintain solution with live tracking API features.

The product's initial setup phase was not difficult.

The solution is deployed on an on-premises model.

Apigee is a very good product since my company hasn't faced too many issues with it. The tool allows users to look into the performance metrics, dashboards, and proxy performance, which are some of the positives. On the negative side, Apigee is not a cloud-compatible tool because it serves as an API gateway and a lot of systems are connected to it, which was a bottleneck for our company to deal with since we wanted to move to the cloud.

I rate the overall product an eight out of ten.

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.  

Our primary use case for Apigee is as an API management tool. Our client has a fast platform and they want to go to the next level when it comes to customization. As they are looking to go beyond minimalistic customization, they need multiple versions of servers and several APIs. This was a challenge we solved with Apigee.

The features I found most valuable are how the APIs are published, the whole process of finalizing the API, and then controlling it.

I'd like this solution to improve on releasing new features; I'd like it to be more frequent.

In my opinion, I think that they should start thinking about improving the solution so that they can compete with open source. You get the support in the paid version, but open source features are being introduced much faster than Apigee's. New open source features come out every week. 

I have been working with the Apigee solution for about eight months. 

My impression is that the stability of this solution is good. It's easy to use and stable. The releases take a long time. They do proper testing and introductions. But, when it comes to open source, they keep giving you more features.

I would rate the technical support of this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best.

Positive

My impression is that the initial setup is seamless. The deployment was done pretty quickly. Our model of deployment is the cloud, more specifically, AWS.

I think that the deployment and maintenance are done by a team of DevOps of six people.

Apigee as a management tool is essential and critical. There is no question when it comes to ROI because this is a mandatory spend from either a policy perspective or an invoicing perspective. When it comes to smaller companies, the pricing might be a bit of a concern.

The smaller companies have a more innovative pricing model, which is why I recommend Apigee when it comes to price. We have a monthly license. I usually work on onboarding the solution for a client for about six months and then I hand it over to them.

We currently have only one customer with Apigee.

I would rate this solution as a whole an eight, on a scale from one to 10, with one being the worst and 10 being the best.