Womply: Helping small businesses compete through API management

Editor’s note: Today we hear from Brad Plothow and Mihir Sambhus from Womply, a software-as-a-service company that makes CRM, email marketing, and reputation management software for small businesses. The company recently developed APIs to help small businesses use data to gain a clearer picture of their markets—and how to compete in them.

Small businesses today have a lot of opportunities to expand services and improve everyday operations. With access to the right data and resources, they can take advantage of digital advertising, reviews sites, and customer insights. These can help them attract customers and foster long-term customer relationships, so they can better compete with large corporations and native e-commerce businesses.

Our mission at Womply is to help small businesses thrive in a digital world. Since 2011, we’ve offered software-as-a-service solutions for small businesses, serving more than 450,000 businesses every day with our software. This system includes a treasure trove of data about the relationship between local businesses and their customers. We started wondering if there was a way that we could open up our data platform to help small businesses gain new insights through their other applications.

To do that, we decided to create APIs, which would give developers and businesses a secure and controlled way to access our data platform. While we have a microservice architecture that we use for internal systems, we had never before created a scalable API program. When we looked into API solutions, we found that the Apigee API Management Platform had everything that we needed to bring security, speed, and self-service to our new API program.

Cultivating relationships with developers

If we want our data platform to improve local commerce for businesses and consumers, the first step is to win over developers. They’re the ones who will be building the apps, services, and integrations with our APIs, after all. It was very important to us that we create a developer portal that was scalable and extremely easy to use.

The Apigee developer portal provides simple and secure access to all of the information that developers need, from signing up for the portal, to reading documentation about how to use the APIs, to a sandbox environment for experimentation. The portal encourages self-service, so we don’t need a support team to walk developers through the development process.

We also wanted to boost the profile of our API program by announcing our developer portal at Money20/20 USA, an annual conference for fintech and finance companies. It would have taken us at least three months to build a developer portal on our own, and we would have missed this important deadline. Taking advantage of the built-in Apigee developer portal, we were ready to go live during the conference. In addition, since our team didn’t need to worry about building the portal, we could spend more time creating a bigger library of APIs and proxies for developers.

Fast time-to-market with Apigee

Apigee makes it very easy for our team to develop and release APIs. It only takes one person to launch each new API, which means that we can release more features quickly. We’ve released four APIs so far, and plan to make quite a few more available through our developer portal this year.

One of the first APIs we released is a benchmarking API, which lets businesses compare their own financial performance to average performance of comparable businesses in their geography. For example, someone running a restaurant in downtown San Francisco could compare their nightly revenue with similar restaurants in the same area. Are they struggling compared to their competition, or are they leading the pack? Are they stagnating, or improving relative to the market? Using this API, any developer can easily add benchmarking capabilities to their apps or services.

Going forward, developers could also use APIs to connect our sales transaction data to online marketing data. This would enable small businesses to attribute offline sales to online marketing and determine whether their Google ads or Facebook banners are paying off. Offline attributions are challenging, but APIs make it possible.

While we have planned a roadmap for APIs and proxies, the reality is that developers will probably surprise us with use cases that no one has even thought of yet. We have a waitlist of developers eager to sign up to our developer portal, but we’re onboarding developers slowly so that we can make sure that we’re releasing the right APIs for people’s needs.

Ready for any challenges

Monetization is another important part of our API roadmap, to increase our revenue streams. We are considering both an à la carte model, where developers can subscribe to one or two APIs, and a tiered package model, where developers get access to multiple APIs but pay different amounts depending on the number of API calls made. Because Apigee offers flexible monetization, we can implement any type of monetization system and adjust our strategy based on the analytics reports provided by the platform.

We hope that by sharing access to our data through APIs, local businesses will gain new insights and efficiencies that will help them thrive. Along the way, we’re confident that Apigee will handle any future API use cases that we want to explore.

Introducing Google Cloud’s Secret Manager

Many applications require credentials to connect to a database, API keys to invoke a service, or certificates for authentication. Managing and securing access to these secrets is often complicated by secret sprawl, poor visibility, or lack of integrations.

Secret Manager is a new Google Cloud service that provides a secure and convenient method for storing API keys, passwords, certificates, and other sensitive data. Secret Manager provides a central place and single source of truth to manage, access, and audit secrets across Google Cloud. 

Secret Manager offers many important features:

  • Global names and replication: Secrets are project-global resources. You can choose between automatic and user-managed replication policies, so you control where your secret data is stored.

  • First-class versioning: Secret data is immutable and most operations take place on secret versions. With Secret Manager, you can pin a secret to specific versions like 42 or floating aliases like latest.

  • Principles of least privilege: Only project owners have permissions to access secrets. Other roles must explicitly be granted permissions through Cloud IAM.

  • Audit logging: With Cloud Audit Logging enabled, every interaction with Secret Manager generates an audit entry. You can ingest these logs into anomaly detection systems to spot abnormal access patterns and alert on possible security breaches.  

  • Strong encryption guarantees: Data is encrypted in transit with TLS and at rest with AES-256-bit encryption keys. Support for customer-managed encryption keys (CMEK) is coming soon.

  • VPC Service Controls: Enable context-aware access to Secret Manager from hybrid environments with VPC Service Controls.

The Secret Manager beta is available to all Google Cloud customers today. To get started, check out the Secret Manager Quickstarts. Let’s take a deeper dive into some of Secret Manager’s functionality.

Global names and replication

Early customer feedback identified that regionalization is often a pain point in existing secrets management tools, even though credentials like API keys or certificates rarely differ across cloud regions. For this reason, secret names are global within their project.

While secret names are global, the secret data is regional. Some enterprises want full control over the regions in which their secrets are stored, while others do not have a preference. Secret Manager addresses both of these customer requirements and preferences with replication policies.

  • Automatic replication: The simplest replication policy is to let Google choose the regions where Secret Manager secrets should be replicated.

  • User-managed replication: If given a user-managed replication policy, Secret Manager replicates secret data into all the user-supplied locations. You don’t need to install any additional software or run additional services—Google handles data replication to your specified regions. Customers who want more control over the regions where their secret data is stored should choose this replication strategy.

First-class versioning

Versioning is a core tenet of reliable systems to support gradual rollout, emergency rollback, and auditing. Secret Manager automatically versions secret data using secret versions, and most operations—like access, destroy, disable, and enable—take place on a secret version.

Production deployments should always be pinned to a specific secret version. Updating a secret should be treated in the same way as deploying a new version of the application. Rapid iteration environments like development and staging, on the other hand, can use Secret Manager’s latest alias, which always returns the most recent version of the secret.

Integrations

In addition to the Secret Manager API and client libraries, you can also use the Cloud SDK to create secrets:

and to access secret versions:

Discovering secrets

As mentioned above, Secret Manager can store a variety of secrets. You can use Cloud DLP to help find secrets using infoType detectors for credentials and secrets. The following command will search all files in a source directory and produce a report of possible secrets to migrate to Secret Manager:

If you currently store secrets in a Cloud Storage bucket, you can configure a DLP job to scan your bucket in the Cloud Console. 

Over time, native Secret Manager integrations will become available in other Google Cloud products and services.

What about Berglas?

Berglas is an open source project for managing secrets on Google Cloud. You can continue to use Berglas as-is and, beginning with v0.5.0, you can use it to create and access secrets directly from Secret Manager using the sm:// prefix.

If you want to move your secrets from Berglas into Secret Manager, the berglas migrate command provides a one-time automated migration.

Accelerating security

Security is central to modern software development, and we’re excited to help you make your environment more secure by adding secrets management to our existing Google Cloud security product portfolio. With Secret Manager, you can easily manage, audit, and access secrets like API keys and credentials across Google Cloud. 

To learn more, check out the Secret Manager documentation and Secret Manager pricing pages.

Krungsri Consumer: Preparing for the cardless future of finance with APIs

Editor’s note:Today’s post comes from Surin Asawachaisittigul, head of open APIs at Krungsri Consumer a subsidiary of Krungsri Bank, the fifth largest bank in Thailand, and focuses on personal loan and credit card services. Using APIs, Krungsri Consumer is taking an established bank into the digital future of finance.

The finance industry is changing quickly in the digital age. Customers no longer want to pay for purchases in cash. Even credit cards are starting to lose ground as customers turn to cardless mobile payment systems.

At Krungsri Consumer, we believe that innovation is key to succeeding in a rapidly evolving financial industry. Our strategy to stay ahead of competitors and enhance customer experiences is to offer more digital services and connect to more partners. That means switching from a traditional monolithic architecture to flexible microservices generated using OpenAPI.

We knew that we needed a robust API management system to serve as a strong foundation for our microservices architecture. It also needed to be secure and easy to use. We looked at many platforms, and the Apigee API Management Platform stood out for its developer portal and strong monetization features. Apigee gives us all of the tools that we need to grow our business and keep pace with changing customer demands and new competitive pressures.

Connecting with partners twice as fast

Our developers weren’t very familiar with APIs, so we teamed up with Apigee partner Tangerine to help us develop our first APIs. Working with Apigee turned out to be very straightforward, and our developers quickly learned how to structure and build APIs through Apigee.

The security features were extremely important for us as a financial institution. Apigee makes it very easy for us to apply API security standards such as OAuth2 to secure our APIs. The add-on Apigee Sense module will further help us protect our APIs from unwanted and malicious traffic.

We started by releasing five APIs related to our points program. Customers earn points when they make purchases with their credit card under Krungsri Consumer group. Our new APIs allow partners to authenticate accounts, look up point balances, and redeem points. Customers can easily pay with points just by shopping online.

Connecting with more partners benefits our customers, as they have a wider selection of products and services that they can easily purchase online using their points. For the partners, it means more customers who shop on their website or app.

The Apigee developer portal simplifies how partners connect with us through APIs. We can store all of our documentation in the portal, so partners can quickly learn how APIs work, what APIs are available, and whether they are free or if there are associated costs. We’ve had a great response to our developer portal so far.

Most importantly, the developer portal makes it much faster to onboard partners. It could take six months to integrate with partners’ systems before Apigee. Now partners can connect with our services in weeks. Some partners are new to APIs, so they need a lot of extra support to get up and running. But even these customers are getting onboarded in less than three months—about half the time as before.

Next, we’re planning to focus on APIs related to payment services. Once these APIs are live, e-commerce partners will be able to offer full or installment payment options through all credit cards of Krungsri Consumer (Krungsri Credit Card, Central The1 Credit Card, Tesco Lotus Credit Card and Krungsri First Choice Card).

Setting the stage for monetization

As a company offering credit cards and personal loans, we have access to a great deal of unique customer data. We’re developing new business models that will turn this data into revenue streams while maintaining customer privacy. For example, one new business that we’re working on is a credit check service, using a model that our data scientists built in-house. Once complete, partners will have the option to run a credit check on a customer using our APIs.

We plan to take advantage of the monetization features in Apigee to drive revenue from these types of data services. In fact, these monetization features were one of the top reasons that we decided to work with Apigee. Apigee not only streamlines setting up API monetization, but it enables partners to subscribe to an API by themselves through the developer portal.

Apigee is opening many doors for other types of future business opportunities. We can connect with new fintech services and startups that also use APIs. We can lead the market with new cardless payment services. And we can even expand services abroad to customers outside of Thailand. With our new API ecosystem, we’re ready for any challenge that may come so that we can give customers and partners the most innovative financial experiences possible.

BPAY: Uncovering new business opportunities with APIs

Editor’s note: Today we hear from Jon White and Angela Donohoe from BPAY Group. BPAY Group is best known for BPAY, the leading electronic bill payment system in Australia, handling one-third of the market. Learn how BPAY Group is positioning the organization for the future by using APIs to streamline workflows for existing customers and new businesses.

BPAY has been a leader in the bill payment industry in Australia for 22 years and provides a secure, fast, and convenient way to connect individuals, businesses, and banks to help people stay on top of their bills.

One of the reasons that BPAY is the preferred bill payment service for so many Australians is our commitment to human-centered design. We’re continuously talking with customers and looking at ways that we can deliver better experiences, products, and services, such as peer-to-peer payments. During these conversations, we noticed some ways that our processes were causing friction for existing or potential customers.

For example, we traditionally used a batch processing system to handle requests between billing companies and banks. But that could cause headaches for some customers, as an error in even one request could cause the whole batch to be rejected. Plus, many “neobanks” (new types of digital-only banks) wanted to work with real-time transactions instead of batch processes, which take longer to complete.

We realized that APIs had the potential to solve many of the challenges impacting customers while opening the doors for future product and business development. We developed a few customer-facing APIs and tested them in closed betas. This experiment went far better than we expected, and we realized that there was a huge appetite for APIs among our biller customers.

While we had developed many APIs for internal systems, developing APIs that were easy to consume by our customers was a new challenge. We needed to move away from our home-grown API development approach and make our API environment more powerful, versatile, and easier to use. The API experts at The Singularity worked with us to develop a strong API strategy. We decided that we would need to support our new strategy with a scalable API management platform.

After a rigorous search, we landed on the Apigee API Management Platform. Apigee was the only solution that met all our technology and business requirements. With Apigee, we have a solid foundation for APIs that will help us deliver more value for all customers.

Creating a custom development environment

BPAY is a trusted brand in Australia, so it was very important to us that we maintain our reputation for excellent customer experiences. When setting up our developer portal, we started with a closed pilot and used developer feedback to make the portal as convenient and simple to use as possible. The Apigee developer portal has many built-in features to help us customize experiences, and if we run into roadblocks, the Apigee team at Google listens and helps us create the custom experience we want.

The developer portal has already proven to be extremely popular. In its first month live, we registered 104 developers in the sandbox environment and 10 developers in the production environment. That was before we even started marketing our developer portal, so we expect those numbers to rise quickly.

Breaking new ground with APIs

We’ve already released four foundational APIs, with a goal of eventually releasing dozens. Our APIs are helping us create smoother experiences for customers. We mentioned that when processing a batch of payment files, one mistake could cause the entire batch to get rejected. Our APIs now enable businesses to validate all payment information before submitting a batch file, dramatically reducing the chances of errors. They can even use our APIs to automatically generate batch files in the right format for different banks.

While APIs improve service for current customers, they also open the doors for new areas of business. Buy now, pay later (BNPL) services, which enable customers to spread out payments across weeks or months, are already popular in retail spaces. After releasing our first APIs, we connected with two BNPL billing services. These companies use our APIs to validate customers’ bill payment information and then pay the bill in full on behalf of customers. This was a completely new use case for us, one that could not have been implemented without our APIs.

The payment service NoahPay also adopted our APIs to validate payment information and let customers pay bills using funds from their WeChat accounts. This is an exciting new market for us, as it’s one of the first examples of how we can connect to international digital wallets through our new APIs. It’s also a great way to introduce users of WeChat, a messaging app used by more than 1 billion people in China, to the BPAY brand.

Planning for the future of bill pay

We have big plans for APIs in the future, and Apigee helps make these plans a reality. We plan to establish a generous freemium monetization model that will allow customers to make up to 200,000 API calls for free each month with tiered payment plans above that. This will enable us to open the doors for smaller organizations while providing optimal support for larger businesses and banks that might need to make millions of calls. Having powerful end-to-end monetization features built in to Apigee means that we can process monetized transactions with ease.

Built-in reporting functionality will also help us make sure that we’re understanding the market’s need for APIs and always providing our customers with valuable services and support.

Apigee greatly streamlines creating self-service API environments. Even as we grow our business, our internal teams will be able to continue providing excellent customer service without needing extra staff to answer questions, help with integration support, and constantly check API security. APIs are the way of the future, and Apigee prepares us meet the challenges that come along with it.

How to build globally distributed applications with Azure Cosmos DB and Pulumi

This post was co-authored by Mikhail Shilkov, Software Engineer, Pulumi.

Pulumi is reinventing how people build modern cloud applications, with a unique platform that combines deep systems and infrastructure innovation with elegant programming models and developer tools.

We live in amazing times when people and businesses on different continents can interact at the speed of light. Numerous industries and applications target users around the globe: e-commerce websites, multiplayer online games, connected IoT devices, collaborative work and leisure experiences, and many more. All of these applications demand computing and data infrastructure in proximity to the end-customers to minimize latency and keep the user experience engaging. The modern cloud makes these scenarios possible. 

Azure infrastructure

Azure Cosmos DB provides a turn-key data distribution to any number of regions, meaning that locations can be added or removed along the way while running production workloads. Azure takes care of data replication, resiliency, and efficiency while providing APIs for read and write operations with a latency of less than 10 milliseconds.

In contrast, compute services—virtual machines, container instances, Azure App Services, Azure Functions, and managed Azure Kubernetes Service—are located in a single Azure region. To make good use of the geographic redundancy of the database, users should deploy their application to each of the target regions.

 

An image showing globally distributed applications.

Globally distributed application

Application regions must stay in sync with Azure Cosmos DB regions to enjoy low-latency benefits. Operational teams must manage the pool of applications and services to provide the correct locality in addition to auto-scaling configuration, efficient networking, security, and maintainability.

To help manage the complexity, the approach of infrastructure as code comes to the rescue.

Infrastructure as code

While the Azure portal is an excellent pane-of-glass for all Azure services, it shouldn’t be used directly to provision production applications. Instead, we should strive to describe the infrastructure in terms of a program which can be executed to create all the required cloud resources.

Traditionally, this could be achieved with an automation script, e.g., a PowerShell Cmdlet or a bash script calling the Azure CLI. However, this approach is laborious and error prone. Bringing an environment from its current state to the desired is often non-trivial. A failure in the middle of the script often requires manual intervention to repair environments, leading to downtime.

Desired state configuration is another style of infrastructure definition. A user describes the desired final state of infrastructure in a declarative manner, and the tooling takes care of bringing an environment from its current state to the parity with the desired state. Such a program is more natural to evolve and track changes.

Azure Resource Manager Templates is the bespoke desired-state-configuration tool in the world of Azure. The state is described as a JSON template, listing all the resources and properties. However, large JSON templates can be quite hard to write manually. They have a high learning curve and quickly become large, complex, verbose, and repetitive. Developers find themselves missing simple programming language possibilities like iterations or custom functions.

Pulumi solves this problem by using general-purpose programming languages to describe the desired state of cloud infrastructure. Using JavaScript, TypeScript, or Python reduces the amount of code many-fold, while bringing constructs like functions and components to the DevOps toolbox.

Global applications with Pulumi

To illustrate the point, we developed a TypeScript program to provision a distributed application in Azure.

The target scenario requires quite a few resources to distribute the application across multiple Azure regions, including:

  • Provision an Azure Cosmos DB account in multiple regions
  • Deploy a copy of the application layer to each of those regions
  • Connect each application to the Azure Cosmos DB local replica
  • Add a Traffic Manager to route user requests to the nearest application endpoint

A diagram showing the flow of global application with Azure and Pulumi.

Global application with Azure and Pulumi

 

However, instead of coding this manually, we can rely on Pulumi’s CosmosApp component as described in How To Build Globally Distributed Applications with Azure Cosmos DB and Pulumi. The component creates distributed Azure Cosmos DB resources, as well as the front-end routing component while allowing pluggable compute layer implementation.

You can find the sample code in Reusable Component to Create Globally-distributed Applications with Azure Cosmos DB.

Pulumi CLI executes the code, translate it to the tree of resources to create, and deploys all of them to Azure:

A screenshot showing Pulumi's CLI executing the code.

After the command succeeds, the application is up and running in three regions of my choice.

Next steps

Infrastructure as code is instrumental in enabling modern DevOps practices in the universe of global and scalable cloud applications.

Pulumi lets you use a general-purpose programming language to define infrastructure. It brings the best tools and practices from the software development world to the domain of infrastructure management.

Try the CosmosApp (available on GitHub—TypeScript, C#) with serverless functions, containers, or virtual machines to get started with Pulumi and Azure.

Knock, knock, who’s there? It’s Guidion, bringing timely service calls with APIs

Editor’s note: Today we hear from Aditya Bhargava, Solutions Architect and agile coach at Guidion, on how the company is using the Google Cloud’s Apigee API Management Platform to transform the Dutch solar panel and communications equipment installation landscape. Read more to learn how Guidion uses APIs to deliver technical services in and around the house, bringing happiness to seven customers every minute.  

Guidion is a Dutch field service management company. We install consumer solar panels and broadband internet for our partners via a pool of about 2,000 freelance expert technicians. We provide our partners with a fully digitized, B2B cloud platform that we use to schedule and manage installations. The installation work we do isn’t the innovation—it’s way we deliver our services that’s the game changer.

Streamlining the service economy with APIs
Most people can think of more than one occasion when they needed a technical service like internet or cable television installed at their homes. This usually involves phoning the company to make the order, then waiting for a call back or an email or text message from the provider with the pre-ordained “installation window.” Often this painstaking process requires taking a day off to wait around for the technician to arrive. Customers don’t usually have a way to easily reschedule if the service window provided isn’t convenient. And they often don’t have ways to get updates on the day of the appointment about when–or if–the technician will arrive. This can obviously lead to frustration. 

Guidion has reimagined service delivery, putting our partners’ customers first with our on-demand installation platform. Once our partners notify us of an installation via our online platform, the customer is provided a link to schedule the installation at their convenience, and at a fixed appointment time that works best for them. Our technicians rely on the app to notify us of their availability, accept jobs, and if necessary, communicate directly with customers. 

Using Apigee to satisfy partner requirements
About four years ago, we migrated from our legacy system to use the Field Service Lightning and FinancialForce platforms from Salesforce to run our business. They do a great job for us, but we needed to find a way to adapt to how individual partners want to communicate with us without also migrating our legacy APIs. Since we already had existing, strong custom APIs that we didn’t want to adapt to the many partner-specific requirements, we started to look for a way to handle those kinds of translations while receiving the same API call via the same API proxy from different partners. We wanted to be able to handle the translations based on which partner is calling the API and then push the request back to Salesforce. That’s where the Apigee platform comes in. 

We were motivated to adopt an end-to-end API management platform because we didn’t want to have to develop a tool in-house to do SOAP-to-REST API translations (though we do offer REST endpoints that send requests to the same Salesforce custom APIs—partners can choose which route they take to integrate with our services). We chose Apigee to implement the SOAP endpoints, but also to enable us to do much more.

Discovering out-of-the-box Apigee functionality
With Apigee we have a standard way of having all our partners communicate with our Salesforce platform. The Apigee developer portal allows us to expose our endpoints and make partner onboarding very easy. We also we made a switch within Apigee that allows partners to make a choice about how they use our new system. We can either quickly and easily turn the request over to Salesforce to manage in their own REST API schema, or we can send it through Apigee as a pass-through endpoint which hands off to the old legacy system. 

Apigee also gives us the possibility of doing login monitoring, analytics, debugging, whitelisting, and certificate-based authentication. These are all functionalities that we got out of the box from Apigee, which we really appreciated. It meant that we didn’t have to invest any time in making or buying additional solutions.

Our partners are large enterprises that need us to adapt to their requirements, so we need to keep all of the partner variations within the Salesforce platform. If we didn’t have Apigee, it would take us twice the time to implement partner-specific requirements, not to mention create a lot of additional resource-intensive maintenance. 

Cascading benefits to the business
Another huge benefit stems from the fact that new partner onboarding is now handled by the business side rather than the technical side of Guidion. When a new partner or an existing partner needs a new service, the only thing our team members need to do is log in to Apigee as an operations administrator and fill in the key value map. Once the right information is in there, the partner is onboarded with no IT assistance required. Instead of waiting days for the IT team to get to it, the business is self-servicing partner able to react in real time to customer needs. 

In the past when we were using SOAP endpoints, integrations were considered a tough job. Not anymore. I think of Apigee as a restaurant. The menu is the Swagger documentation, then the waiter is the API that takes your order to the kitchen. The kitchen is the server that prepares your order and delivers it back to clients. Having Apigee makes our integrations as easy as eating out.

To learn more about API management on Google Cloud, visit the Apigee page.

Google Cloud named a Leader in the 2019 Gartner Magic Quadrant for Full Life Cycle API Management for the fourth consecutive time

We’re excited to share that Gartner has recognized Google Cloud (Apigee)—for the fourth time in a row—as a Leader in the Magic Quadrant for Full Life Cycle API Management. In this year’s report, Google (Apigee) is positioned highest on Gartner’s “ability to execute” axis.

Magic Quadrant full life cycle api.jpg
This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Apigee.

APIs are how businesses build and connect modern applications in hybrid and multi-cloud environments, and API management is the way those businesses can securely deliver these connected experiences to customers, partners, and employees. Google Cloud’s Apigee team is committed to building a sophisticated API platform that serves as a foundation for digital business, as well as providing the expertise and guidance to help promote our customers’ success, with offerings such as our Day Zero program, API Program Excellence e-learning series, Compass online assessment tool. So it’s gratifying that we are recognized for our efforts as a strategic partner for digital transformation and not just a provider of technology solutions. “The wealth of experience that Apigee brings from working with hundreds of customers, across industries, has been extremely helpful to PricewaterhouseCoopers,” says Trent Lund, lead partner, innovation & ventures, PricewaterhouseCoopers. “We really value the insight and sharing we get from Google Cloud’s Apigee team and the collaboration between our engineers. It goes far beyond software.”

The Gartner 2019 Magic Quadrant for Full Life Cycle Management is available for download here (requires an email address).


*Gartner “2019 Magic Quadrant for Full Life Cycle API Management” by Paolo Malinverno, Mark O’Neill, Aashish Gupta, Kimihiko Iijima, 9 October 2019.

As Google (Apigee) in Magic Quadrant for Full Life Cycle API Management (2019 – 2018)
As Apigee in Magic Quadrant for Full Life Cycle API Management 2016 
As Apigee in Magic Quadrant for Application Services Governance 2015
(As Google acquired Apigee in 2016, it was recognized by the name Apigee in 2015 and 2016 Magic Quadrants)
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

How Traveloka brings partners in for a smooth landing with APIs

Editor’s note: Today we hear from Felix Perdana, engineering manager at Traveloka, on how the company uses the Apigee API management platform to become a one-stop travel and lifestyle platform in Southeast Asia and beyond. Traveloka uses APIs to grow and consolidate its inventories while bringing customers and partners together to book flights, vehicles, hotels, and vacation packages. 

Traveloka is an Indonesian tech company currently focusing on the travel and lifestyle markets. Our customers, the majority of which come from Southeast Asia, visit the site mainly to book flights, hotels, transportation, lifestyle experiences (e.g. theme parks, movie tickets, beauty and spa treatments, and restaurant vouchers), and much more. We aim to serve more customers across the globe as part of our giant expansion plans.

In past blog posts, my colleagues have written about how Traveloka is using Google Cloud for data provisioning and stream analytics. Today, I’m sharing how we use Apigee API Management Platform from Google Cloud, a key part of my role as an engineering manager in charge of the after-sales and affiliation domain.

Extending the global footprint with Apigee
Expanding to markets globally means dealing with a lot of unique and challenging factors in each country. Thinking about different government regulations, currencies, payment systems, and customer service expectations is only the beginning. There’s a lot of potential obstacles given how differently each country’s marketplace operates, which is why we use APIs and a partner integration approach to better distribute our inventory, thus helping us to scale our business quickly in a competitive space.

When we started Traveloka, we were serious about building a product that would be better than our competitors. Better in terms of inventories, services, and also pricing. We also knew that we wanted to have the best strategies for increasing our exposure within and outside of Southeast Asia. With all the right features needed (security, high performance, monitoring, and low development and maintenance costs), Apigee helps us execute on our business plan, by making it quick and easy to work with the partners that make the Traveloka platform a success. 

Deciding between make versus buy for an API gateway
When we started, we built our own API gateway with our first version of API specifications. Before that, we looked into several API gateway products (including Apigee), did some research, some POCs, and had several meetings with vendors. However, since we were just starting to dip our toes into the API business and didn’t have enough use cases to justify the purchase, we decided to build our own system with the bare minimum requirements. 

After a while, other Traveloka products that also wanted to have their API exposed rebuilt the same thing. Problems arose when partners who had connected with our flights API wanted to add another service, like accommodation. They felt like they were working with a different company. Different standards, different security practices, different formats—it wasn’t an optimal way to work.

About a year and a half after the release, we started to understand the scale, needs, and the limitations of our own platform. We were convinced that a better solution was needed to support our business growth. We then met with Apigee team again, at the Google Cloud Summit 2018 in Jakarta.

Aside from standardizing our APIs, Apigee supports benchmarking, a fantastic developer portal, a sandbox environment, and great monitoring and analytics. Apigee gives us remarkable speed and agility. It enables us to scale quickly, which is vital to executing our business plan to offer more services in more regions. 

I also like the rate-limiting feature that lets us limit the throughput rate from one API to another. The fact that we can do this not only per URL, but also per partner, gives us a lot of flexibility. For example, if partner A has a throughput of 100 calls per second, but partner B needs 500, we can easily meet those differing needs and manage our traffic efficiently. When we evaluated API gateways, Apigee was the only one that enabled us to limit to that level of granularity. 

Our APIs are meant for B2B, not for the public. Because of the requirements, we need a high level of security. Apigee helps us in managing the security with its SSL handshake features as well as the authentication and authorization methods. 

Executing an aggressive growth plan with Apigee
Before we had Apigee, sharing APIs with partners was a laborious process. We exposed approximately 20 APIs through a shared document that listed our APIs with the types of the requests and responses they need to handle. Partners could see what was available and how they could integrate into our staging. More work was required before they could come in and try APIs in our sandbox. It used to take up to three months to deploy a new API for a partner. Now that we have the Apigee developer portal, it just takes a few days.

The developer portal enables our partners to view all of our APIs and try them out in the sandbox. The simplicity in creating and managing proxies is also a huge time saver. Right now, we have two B2B partners onboarded to the developer platform, and a few more still working manually through our old, in-house platform. We expect to transition them over and add 20 new partners to the Apigee platform this year. Because it now takes us as little as two weeks to onboard a new partner from first establishment to go live, we’re ramping up quickly. We estimate that we saved at least a year of development time by deploying the Apigee platform as opposed to building one in-house.

Rapid learning, rapid onboarding
Our developers are very happy with Apigee and feel the portal makes Traveloka look more professional. Equally important, the Apigee learning curve for developers and partners has been short. In just one week our partners know how to use all our APIs. If you compare that to the previous process of referring to a Google Doc and building their own servers to connect to our staging, it’s incredibly easy.

We look forward to exploring other ways that the Apigee platform can help Traveloka; we see strong potential to use even more features to help Traveloka grow and stay competitive.

Black Knight and the quest to conquer an ecosystem of partners, developers, and customers with Apigee

Editor’s note: Today we hear from Brad Homer, Senior API Strategy Product Manager at Black Knight Inc., on how the company uses the Apigee API Management Platform from Google Cloud to transform integrated software, data, and analytics solutions for the mortgage industry. Read on to learn how Black Knight uses APIs to facilitate and automate many of the business processes across the homeownership life cycle. 

Black Knight is a leading provider of technology, data, and analytics to the mortgage industry, catering to both large and mid-tier banks in the United States. Over the past few decades, we tended to manage customer integrations on a case-by-case basis. Whenever a bank needed to connect with a Black Knight app, we’d launch another integration project. Lather, rinse, repeat. Needless to say, this was inefficient; we knew we had to do something to centralize this process.

Building versus buying an API management platform
To start, we created some homegrown API solutions. Despite being largely successful with one of these solutions, we saw that technology advances were outpacing our capacity to update our solutions in-house. We knew we needed to move toward an API platform that would support RESTful architecture and that would fully enable mobile solutions. It also had to be extremely secure. Knowing how complicated such a platform would be to build ourselves, we decided that our developers were better off focusing on providing core solutions to Black Knight clients; engaging with an outside provider was the right way for us to advance our API strategy. 

After a lengthy proof-of-concept process, we went into production with the Apigee API Management Platform from Google Cloud in 2018. In our opinion, Apigee was the most complete, robust, technically sound and full-featured option from among all of the API management tools we evaluated. Its ease of use was the deciding factor for our developers, and the Apigee analytics capabilities provided considerable insight into the anatomy of an API call—something the other platforms we considered didn’t do as well. 

Choosing Apigee meant that we didn’t have to focus on developing and maintaining a tool or spend enormous amounts of money trying to keep up with security patching. For a large company like Black Knight, an API management tool is something we don’t want to spend a lot of time on. We know that Google Cloud devotes tremendous resources to it, and it would be difficult to replicate that in-house. 

Black Knight has more than 150 client-facing applications. Almost half of them now are built with APIs that are externally facing, and many of these apps use APIs that integrated with other Black Knight applications. Add to that the huge number of applications out there that come from clients and third-party vendors, and suddenly, we had a management challenge from an API perspective.

Driving cultural change
We came to Apigee with the goal of containing and empowering our huge ecosystem of APIs, customers, third parties, and internal users.  

Given Black Knight’s size, our developers and customers understandably each have different business goals, so getting everyone to come to a centralized platform is a great opportunity. My role is to help people consider other options so they can be open to the benefits that Apigee brings us.

Now that we’ve engaged with Apigee for over a year, we see two big benefits. First, the huge reduction in point-to-point integrations has produced tremendous efficiencies for us and our customers, who now get instant integration once they’ve been authorized for a particular API. Second, Apigee’s capacity for mobile enablement lets us satisfy our customers’ needs for secure mobile apps.  

Simplifying security
From a technical perspective, security is complicated for mobile apps. We’re often accessing sensitive information on a mobile device that can’t always be trusted. This kind of scenario requires us to implement a number of security precautions to help ensure confidential information remains protected.  

The Apigee API management platform addresses these needs in the simplest way possible. It solves complex problems related to security without having to deploy a new API proxy each time we need to support a particular mobile device upgrade. Our back-end applications remain protected because Apigee helps manage security, requests, access tokens, and authorizations. Today, our back-end applications work with Apigee to communicate with mobile devices or servers coming over the internet. 

Apigee has also enabled us to do a better job sharing a variety of APIs. The developer portal lets us stitch together APIs and get more creative about how we can innovate and build new solutions based on these collections of APIs. At this point, anybody that has a nondisclosure agreement with us can register for the developer portal. The nature of our business is such that we can’t just open up our APIs to anybody, but it’s available to our contracted third parties.

Our Apigee journey has been exciting, and we’re making great progress. I’m looking forward to what innovations we will come up with next, thanks to the way Apigee enables us to create, implement, and deliver.

To learn more about API management on Google Cloud, visit the Apigee page.

PNB: Investing in Malaysia’s future with APIs

Editor’s note: Today we hear from Muzzaffar bin Othman, CTO at Permodalan Nasional Berhad (PNB) on how the company uses Google Cloud’s Apigee API Management Platform to create digital investment channels. Read on to learn how PNB is increasing financial inclusion by expanding investment opportunities for all Malaysians.

Permodalan Nasional Berhad (PNB) is one of Malaysia’s largest investment institutions with more than RM300 billion ($71 milion) in assets under management. Through our wholly-owned company, Amanah Saham Nasional Berhad (ASNB), we manage 14 funds with a total value of RM235.74 billion ($56.34 million) as of Dec. 31, 2018. 

To expand the range of people who can invest and participate in the economy, our unit trust funds enable the public to invest as little as RM10 ($2.50) into any of our funds. With each investment, unit holders (a unit holder is an investor who holds securities of a trust) are able to participate in the local and international investment activities managed by PNB and ASNB. They also gain dividends from their investment at the end of the financial year for the funds that they invest in. 

Accelerating access to services with APIs
As chief technology officer for PNB, I lead the retail and asset management technology aspects of the business. My team and I manage the basic IT systems such as email and networks, but also the more exciting and complex IT infrastructures, including investment core systems and data analytics for the unit trust teams.  

In January 2017 (prior to joining PNB), I observed unit holders waiting in a long line just to update their account balances following a dividend announcement. Unit holders had limited options then: they were required to visit an ASNB branch or one of our agent banks to complete the transaction. When PNB hired me three months later, I was determined to create a self-service balance checker that would reduce our unit holders’ waiting time. My team first built an application on an Android tablet that communicated to our backend via APIs. Then we constructed a kiosk around this and started our first self-service kiosk. We have built 120 kiosks across Malaysia in six months.

While we made progress in creating new solutions for our unit holders, we were missing an API management framework to manage our APIs. After extensive market research, we decided on the Apigee API management platform as it was the most suitable platform to build our capabilities for developing and managing APIs. Apigee’s technical capabilities coupled with responsive support from Google Cloud were important factors. Being new to APIs, we value the quick and ready technical support made available to us.  In addition, the secure and flexible system that Apigee offers is critical to us because as a financial institution, security is of paramount importance.

In July 2017, we migrated our retail core system from mainframe base to a modern, cloud-based  infrastructure. In August of the same year, a newly developed web portal provided our unit holders access to their accounts through their mobile devices for the first time. The customer response was very encouraging and uptake has been very high since then. 

The portal uses APIs to enable our 14 million unit holders to check balances, reinvest, edit their personal information, and access account statements. For now, the portal is only available to unit holders who pre-register via an in-person onboarding process. We are currently awaiting regulatory direction on electronic Know Your Customer (eKYC) rules that will impact digital onboarding before we can enable access to new unit holders via their  mobile devices.

Creating new channels for financial inclusion
To date, our web portal and APIs have generated approximately RM2 billion (USD500 million) in annual investments. This equates to about five percent of our total yearly investments contributed via the digital platform. While this is encouraging progress, there is much more potential that we can tap into, including the collection and analysis of consumer behavior data. Moving forward, this valuable information will provide insights for us to improve customer experience and fine-tune our offerings. 

A typical bank integration typically takes six months at a high cost. Excluding the governance and compliance approval period, our key APIs can be consumed in under three months, at minimal cost. Banks that use APIs will find ours easy to work with. This simplifies our agent onboarding process. 

APIs enable us to innovate further by expanding our capabilities and reach. We are currently onboarding a few PNB agent banks and we look forward to the possibility to connect to fintech players in Malaysia, especially e-wallet solution providers. API simplify the communications between multiple systems and offer a world of possibilities for our business.

Change Healthcare: Building an API marketplace for the healthcare industry

Today we hear from Gautam M. Shah, Vice President, API and Marketplaces at Change Healthcare, one of the largest independent healthcare technology companies in the United States. Change Healthcare provides data and analytics-driven solutions and services that address the three greatest needs in healthcare today: Reducing costs, achieving better outcomes, and creating a more interconnected healthcare system. 

Healthcare is a rapidly evolving industry. There is an urgent need to bridge gaps and connect multiple data sources, transactions, data owners and data users to improve all parts of the healthcare system. At Change Healthcare, we are rethinking and transforming how we approach our products and how we use APIs to achieve this goal. Taking a user-centered, outside-in approach, we identify, develop, and productize “quanta of value” within our portfolio (“quanta,” the plural of “quantum,” refers to small but crucial pockets of value). 

We connect and integrate those quanta into our own and our partners’ products to create a broader set of more impactful solutions. This approach to creating productized APIs enables us to bridge workflows and remove data silos. We bundle productized APIs to power solutions which open new possibilities for powering exceptional patient experiences, enhancing patient outcomes, and optimizing payer and provider workflows and efficiencies. 

To support this goal, we needed a way to support a large population of API producers, engage several segments of API consumers, and rethink how we bring API products to market at scale. We aren’t just delivering code; we’re creating and managing a broad product portfolio throughout its lifecycle. We take our APIs from planning, design, and operation through evolution and to retirement. 

Operating these products requires meeting the needs of many API producers, allowing for marketing and product enablement, supporting different distribution channels and pricing, and enabling rapid product and solution creation. We also have to do all of this while prioritizing security and requiring a minimum of added platform development or customization. In short, we need an enterprise marketplace enablement platform. We chose the Apigee API Management Platform because it allows us to do all this.

Why Apigee?
Change Healthcare is building a marketplace to advance API usage across the healthcare ecosystem. This marketplace, the API & Services Connection, is a destination where our internal users, customers, partners, and the healthcare ecosystem can readily discover, interact with, and consume our broad portfolio of clinical, financial, operational, and patient experience products and solutions in a secure, simple, and scalable manner.

Using Google Cloud’s enterprise-class Apigee API Management Platform to power our marketplace allows us to support our entire organization with a standard set of tools, patterns, and processes. Using these common, and in some cases, pre-established, sets of security, performance, and operation standards frees our API producers from worrying about the mechanics of how to deploy their products, and allows them to focus on creating the best possible solutions. It also provides us with robust proxy development and management capabilities, allowing us to access and distribute existing APIs and assets, thereby eliminating the need for complex migrations.

We empower our diverse mix of API producers by leveraging the full range of Apigee capabilities to automate engagement, integrate with different development methods, support visibility of products and pricing models, and measure usage, engagement, and adoption. By taking a “self-service first” approach, we allow our API producers to operate in line with their business processes and needs of the enterprise, while at the same time giving them the tools and metrics they need to create and optimize their products. 

We also use the Apigee bundling capabilities to allow our producers to easily create and productize API bundles, which are then used to develop solutions that incorporate leading-edge technologies to solve more complex problems. 

Our customer-facing marketplace makes the most of how Apigee supports distribution of APIs to multiple marketplaces, including a fully customizable developer portal. This capability gives us the ability to build private API user communities, create experiences for multiple customer segments, and distribute our APIs across multiple storefronts. 

Apigee lets us do all this while maintaining a common enterprise platform from which to control availability, monetization, and monitoring. In this way we can distribute our API assets internally and also allow our API producers to target how they want to manage their API products externally. Producers also benefit from rich engagement and usage data to better segment and target product availability, and pricing. Apigee also supports creating a more immersive and interactive experience for API consumers, enabling us to provide technical and marketing documentation, a sandbox, and connections to our product teams and other users.

Fulfilling a bold vision
At Change Healthcare, we believe APIs are the present and the future. Today, our APIs power our products and enable us to serve the needs of the entire healthcare ecosystem. Looking forward, our APIs will power growth by enabling internal users to take advantage of valuable capabilities we’ve created, as well as make those capabilities easily available to external users. Armed with these productized APIs, our developers, customers, partners—ultimately all parts of the ecosystem—will be able to deliver new and innovative products that combine interoperable data, differentiated experiences, optimized workflows, and new technologies such as AI and blockchain.

We’re just getting started with APIs! We’ve launched the first version of the API & Services Connection developer portal, and now have a standard method of engagement with our API producers and a place to drive internal visibility and external discovery. Our partnership with Apigee works well for us because we can demonstrate that we share the same goals internally and externally, and ultimately use the same set of tools to drive transformation. As our vision becomes a reality, we look forward to engaging not only more of our internal teams, but our partners and customers as well. Together we will use APIs to break down silos in healthcare, and ultimately create a more interoperable healthcare system for patients, providers, and payers. 

Learn more about API management on Google Cloud.

From stamp machines to cloud services: The Pitney Bowes transformation

Editor’s note:James Fairweather, chief innovation officer at Pitney Bowes, has played a key role in modernizing the product offerings at this century-old global provider of innovative shipping solutions for businesses of all sizes. In today’s post, he discusses some key challenges the Pitney Bowes team overcame during its digital transformation, and some of the benefits it has enjoyed from building new digital competencies.

Pitney Bowes will celebrate its 100th birthday in April 2020. Over the past century, we’ve enjoyed great success in markets associated with shipping and mailing. Yet, as with so many established and successful enterprises, we faced slowing growth in the markets that served us so well for so long. While package growth was accelerating, the mail market was declining, creating opportunities and challenges.

To change our growth trajectory and “build a bridge” to Pitney Bowes’ second century, we needed to offer more value to our clients. We needed to move to growth markets, and that required new digital competencies. In 2015, we began a deliberate journey to transform our services, including shipping and location intelligence, for the digital world and make them available via the cloud. We learned a lot throughout this journey. In this post we’ll take a look at three things, in particular, that led to the success of this project—and will help future projects succeed, as well.

Setting expectations and realistic milestones

Organizations tend to undertake product development with a sense of optimism—and it’s often not particularly realistic. You set out thinking something will take a certain amount of time and that you will incur a specific cost, but estimates in technology and development may be optimistic, and costs almost always incrementally increase throughout the development process. 

With a digital transformation effort, there’s an additional challenge: You aren’t really heading to a well-defined destination, so the path your team takes can be even more ambiguous. Digital transformation doesn’t have an end state. It’s a process of constant evolution.

For these reasons, and more, it’s important to set informed, realistic expectations—in schedule, in budget, in project scope. It’s also critical that you identify milestones along the way, and recognize and celebrate when you reach them.

When you’re working on a massive, multi-year corporate transformation, after all, it can be hard to recognize that every little action you take each week, everything you win day-to-day, is a part of your progress, your change. So, it’s really important, as a leader, to bring consistency and execution discipline—and be able to point to the progress being made and celebrate accomplishments.

We did our best to follow this advice during our digital transformation. Late 2015 was a critical time for Pitney Bowes as we laid out the technology strategy that would get us to the next century. We were aware of the potential hazards that could arise. You set the strategy, celebrate its publication as an accomplishment… and then nothing happens. To avoid this issue, we broke our strategy out into specific tactics supported by numerous smaller, interim goals. When we started putting big, green checkmarks next to each accomplished milestone, people started realizing that we were making real progress, and were serious about our execution.

One key milestone, for example, was implementing an API management platform. This comprised several granular goals: Selecting a partner, training a subset of our 1,100 team members on the platform, and rolling out our first offering that was built on top of that capability. 

We knew that an API platform would be a key part of our digital transformation for three major reasons. First, we had acquired several companies, but their technologies were difficult to share for use cases across the organization. Every time a team needed to use our geocoding or geoprocessing capability, for example, they had to spin up a new environment. By building these capabilities as APIs across the organization, it made it easy to democratize their usage and speed up development. 

Secondly, we were running a big enterprise business system platform transformation program and wanted our product teams to be able to consume data from our back-end business systems. This meant that we needed a solid catalog of all these services, so new members of the team could easily find and use them.

Finally, we had a couple of business units that wanted to go to market with APIs. They had a business strategy that entailed selling a service or value, with a vision to build a platform or ecosystem around these capabilities. An API platform (specifically, Google Cloud’s Apigee API management platform) is a huge accelerant in enabling all three of these objectives—it’s how you do this well.

Reusability and the Commerce Cloud

The Apigee platform and team helped us build a key offering that arose from our digital transformation: the Pitney Bowes Commerce Cloud. It’s a set of cloud-based solutions and APIs that are built on our assets and connect our new cloud solutions to our enterprise business systems, such as billing and package management.

Today, we have close to 200 APIs delivered from the Commerce Cloud in the areas of location intelligence, shipping, and global ecommerce. The Commerce Cloud isn’t just a success as a customer-facing platform, however. We often talk about whether our development teams themselves have leveraged its services when developing new products. These discussions help us understand whether a product team has thought through the digital capabilities we’ve already built, assessed which capabilities fits into its roadmap, and adopted the right technology, capabilities, and practices to align with our corporate digital transformation strategy.

Internal use of these shareable services shaves up to 70% off of our design cycles, because so many decisions are already made. Commerce Cloud adoption means you’ve gotten on the path internally, lowered the friction, and are aligned with the broader company digital transformation strategy. 

Measuring success

We’re proud of what we’ve accomplished so far at Pitney Bowes. But pride only takes you so far. To determine a project’s success, you need to be able to measure it. 

We do have some encouraging external measures: our percentage of revenue from new products climbed to roughly 20% of sales in 2018, compared to 5% back in 2012. And our Shipping APIs, which enable customers to integrate U.S. Postal Service capabilities into their own solutions, has gone from a standing start to an over $100 million business in a few years.

On top of those external results, our business has transformed. We’re no longer just participating in a one-time sale of a product, software, or services; we’re participating in transactions every day that drive client outcomes. The more you can improve the quality and effectiveness of those services, the more you and your client enjoy the benefits of the commercial relationship. That’s a very big business model transformation for Pitney Bowes.

We’ve also sped up our time to market and tightened our service-level agreements. But perhaps most importantly, we’ve developed and adopted a new set of internal processes and a mindset that helps us quickly adapt to changing market conditions. Again, digital transformation isn’t a destination. It’s really a set of processes that enable us to be nimble and keep building a bridge to Pitney Bowes’ future.

For more on the Pitney Bowes transformation, check out these videos and this case study.