Apigee Reviews

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.

Our primary use case is for building an open API platform for a financial services company, and we needed something that could do the task quickly.

The most valuable features are low-code play, quick packaging, and production.

I would like to see the support improved. I think the time frame should be shorter for responses when it comes to technical support. This is not the ideal situation you want to be in when you need support.

I have been using Apigee for the past four years.

The stability is definitely close to a ten on a scale of one to ten.

On a scale of one to ten, I would rate the scalability around an eight. We currently have around twenty users implementing the solution on a regular basis.

When it comes to customer support I would rate them a six and a half because of the response time and prioritization. This prioritization factor is most likely due to geography.

We were using API Connect from IBM before switching to Apigee for better user readiness options.

The initial setup took a few weeks.  This was primarily because of us. It took us a while because of internal approvals. The team I was working with just was not fast enough.

When it comes to the return on investment it is pretty good. There is value for money when it comes to engaging external partners and collaborators. The initial cost is one tends to recover quickly with the right business case.

Apigee is expensive and not cost-effective. On a scale of one to ten, I would rate it an eight for the high cost. The changes individuals need to make on their side are costly.

Your team should be familiar with the product before you jump into it. There is training involved for the team, and before deploying and starting to use it, the team should get adequate training. On a scale of one to ten, I would rate Apigee an eight out of ten.

It's deployed on the cloud. There are a few hundred people in my organization who use this solution. 

It's easy to use and the security features are valuable.

I have used this solution for about three years.

It's a stable solution.

It's scalable. You can onboard multiple partners.

Setup isn't very complex.

My clients pay for a license.

We also use Amazon.

I would rate this solution as eight out of ten.

I would recommend this solution to those who want to start using it, but it depends on the requirements and automation.

It is an API gateway. It provides protection to our backend services.

The solution has improved our organization by formalizing the API interfaces. Through API specification documents, we can automate our documentation of those APIs and we can make it easier for our customers to integrate as it's a standard way of defining those APIs.

Items around the mobilization of the API interface and the ability to automate validations for our APIs are the most valuable aspects.

We have looked at MuleSoft as well, which is a competitor. MuleSoft has a richer set of integrations for an iPaaS solution. There's an IP gateway that we're using Apigee for, however, it cannot be used as an iPaaS, whereas the MuleSoft solution can be used as both an API gateway and an iPaaS. We've started talking to Google about their iPaaS solution, however, it doesn't play nice yet. 

They have an external developer platform that was a little bit painful. They do have some built-in developer tools, however, you can build an external development portal. It would be nice to have a built-in bundle that was more complete.

I've used the solution for about two years. 

I'm confident in the stability of the solution. It is very reliable and has good performance.

I'm quite confident of the scalability. I did do some comparisons between MuleSoft and Apigee, and a third one whose name slips my mind at the moment.

With Apigee, we don't have to think about scaling. There are still some limits, however, you can buy up. They have 80 million transactions a year, 80 million or 800 million, however, you can buy up if you start to exceed that. On some of the other platforms, you have to post the service yourself and you have to make sure that you were managing scale. That was one thing that is an advantage on Apigee.

There are something like 60,000 users using the solution, however, our load plan around it is more so that I don't think we've fully deployed it to the extent that we plan to. It's probably a small effect of that. The number of users that are impacted by it is probably in the order of nearly 10,000.

It's not being used as much as we would like. We're still ramping up and prioritizing people to be building around. Some of our existing technology does not traverse through it. Over time, we do plan to extend it until all of our external-facing interfaces go through Apigee.

We underutilized technical support initially. We have since engaged in a better way. There's a lot of documentation out there. They were helpful through the sales process to make sure we understood things, however, once we passed that, the support was more tactical and less strategic. We needed to go to third parties to get strategic support.

I did not previously use a different solution.

The setup itself was not complicated, however, the learning curve to integrate into our platform was way too complicated. It took over a year for us, from the time we purchased it until the time that we actually were running APIs through it. The ramp-up time took too long.

I would rate the solution a three out of five. I can't blame the vendor alone. It's also due to what I did or did not do.

We did not have enough of an implementation strategy. With the setup, there are instructions set up. Going through a setup is fine, however, knowing what to do with that setup and how it fits into a grander picture has been a journey.

The amount of staff needed for deployment and maintenance depends on the organization that's trying to deploy it. We have a fairly rigorous DevOps process, so there's somebody that is needed to manage the actual deployment of it. You'd need at least one, maybe a redundant person. Then, you need one person and a redundant person to manage the DevOps integration and to be able to build a pipeline so that you can deploy it. You also need at least one person that knows how to work in the platform to build APIs. I would say you'd probably need five or six people that really understand this to be able to deploy it.

We used two resellers, two integration partners. The first one got something going and we learned from them, however, nothing ever came out of it and it got shelved for a little bit. When we went with a second integration partner they actually helped us build an API documentation server. It's got a different name. 

It's a developer portal. They helped us build a developer portal, which is still not rolled out as it did not meet our standards. We've had to do things a little bit manually. One thing that I would say is that inside of deploying an API gateway, from not knowing anything about it, there was a big learning curve that we had to go through.

Now that I know what I know, it is a competitive product. Any of the products I would have started with I would've struggled with. There's just something about that strategy that you're talking about that is a big learning curve.

We have not been able to leverage ROI that much as we have not deployed it all the way. However, the ROI is in our opportunities. When we talk to our customers and explain what we're doing with our Apigee, their confidence in our ability to scale and secure is higher. When we don't, when we go to customers and we don't talk about Apigee or our gateway strategy, then there are many more questions that come up. It greases the wheels so to speak, on that sales process, security audits, et cetera.

It was fairly expensive. I don't know what the standard pricing is. I want to say that it's something like $80,000 for 800 million requests (approximately) a year. It's basically a full-time person cost. It's not higher than the competition. Everyone is expensive. 

With Apigee, it's all-you-can-eat up to a point. For example, you can think of it as a dining hall where you can go in and eat anytime you want for up to 500 meals. After that, you need to buy up to get another 200 meals.

We also looked at MuleSoft. I evaluated multiple solutions to determine that we would go with the choice that we chose, however, did not have experience with competitive products beforehand. Our platform was not using one.

I'm just a customer.

It's a hosted solution. It's my understanding that it gets updated by Google when it needs to be.

I'd advise potential users to do as many POCs as they can on the free version, and get their feet wet with it. There's a lot they can do with the free version. You can learn a lot by just getting out there and starting.

I would rate the solution 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 have hundreds of backend services, APIs, that are running. We want to protect and do analysis with calling externally, internally, and all the statistics we want to track using Apigee. That is the reason we're using the API gateway.

We have seen product improvement. Initially, we didn't use much of the analytics part. Later on, we saw that as an improvement. The rate-limiting quotas are improved as well.

The analytics feature is quite good. We can look at all the statistics, how many requests coming in, how many requests going out, what type of failures are happening, what is the performance of the APIs on those features. The solution helps us to track whenever there is an issue that comes in.

The only concern overall, with the organization, is cost-wise. I believe there is already a plan, within our organization, for moving to Azure API Management. The main reason is one of the features is a cloud-based, pay-per-use. And then, because a lot of our services are moving towards Azure, why have another network of API gateway.

The testing feature is one additional feature that I see is in APIM and it is not here. We can build our own demo web service and test your proxy. That feature has been provided in APIM, not in Apigee.

I've been using the solution almost three years now.

Overall, the solution is good.

The scalability is good. Our load has improved drastically in the last three years. The traffic has been increased, and we still see a good performance overall.

Mostly developers from different teams use it. And there are administrative teams maintaining the overall solution within the organization.

The technical support is good. As a user, we report to the admin team and they work with the consultants if they are not able to resolve the issue.

I was not involved in the initial setup, but I've been told that the onsite setup was a little complex and there were a few restrictions as well.

We see a return on investment. As of now, it's good. But overall, cost wise, it is a little higher, comparative. 

For Apigee, I think licensing is on a monthly basis. The cost increases as the usage increases. It's higher than many competitors.

Azure APIM is the one option we evaluated.

From two or three years back using it to now, it's quite fast. The performance side is good.

It's a user-friendly product, it is. You can customize all you want, and the policies and the features they have are quite easy to use. Anyone can use it, drag and drop, and it supports a lot of other languages like JavaScript, non-JS, and all. 

I would rate the solution 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.

We primarily use the solution for API management. We use the solution with open banking, and we are managing our customer's cloud, on-premises, and Apigee environments. 

The solution is great in general. There are many categories of APIs that need to be maintained. It helps maintain and add rules to manage open banking. 

The solution is stable.

The initial setup isn't too complex.

It can expand well. Google seems to be moving into the cloud more than on-premises and the cloud makes scaling easier.

Apigee deals with APIs. However, most of our clients need more tailoring done to the solution.

Google isn't enthusiastic about supporting older versions. Google is now trying to move all of its clients to X within the cloud. However, some still want on-premises. 

I've been using the solution for about four years. I've used it for a while. 

The solution is stable. However, it depends on the release, the customer, and the sophistication of the infrastructure. 

We have had some issues with bugs in the product itself. 

The solution is scalable.

We have three banking clients on the solution. 

The amount of users depends on the customer. Some use it internally. Others expose the API to clients. Some have more than a billion APIs. Some have less. 

The technical support is not the best. It does depend on the size of the customer. Larger customers tend to get more attention. 

The ease of setup depends on the level of sophistication of the clients. It can be rather simple; however, the more complex the infrastructure, the more difficult the setup can be. 

We do both cloud and on-premises deployments. The length of deployment depends on the customer. It depends on the kind of network or the organization. It can take a few months up to a year.

We have a strong knowledge of the flow and the templates. For us, it's pretty straightforward. 

There is a team of six people that can assist with deployment and consulting with clients.

There are different models that customers can choose from. They have a subscription model. 

I'm a consultant. 

We are using a few different versions of the solution.

I'd recommend the solution to others.

It'd rate the solution eight out of ten.