Tradier uses the Apigee API management platform from Google to abstract the legacy complexities of capital markets so that developers can build FinTech applications in an agile, nimble, and quick fashion at minimal cost. The company embodies the evolution of what cloud technology can enable in the form of an API-first business delivered as a service.

The rise of API-powered FinTech

Historically, companies that wanted to build systems, applications, or services to interact with the stock market would have to build an entire brokerage operation from scratch. This would include data infrastructure, compliance infrastructure, and storage capabilities. It could take years and massive capital expense to accomplish everything that was required to be ready to serve customers.

Tradier provides this infrastructure as an API-based service so that the same companies can launch investor applications in as little as a few weeks. This democratized access means that FinTech innovation can come from anywhere, giving the same opportunities to create new products to everyone, from enterprise customers to startups.

“Financial markets are becoming fundamentally decentralized and unbundled,” says Dan Raju, co-founder, CEO, and chairman at Tradier. “The services that large legacy banks and brokerage firms used to offer are being supplanted by Tradier’s microservices and APIs, which power innovation.”

More than 200 companies use Tradier to develop and launch new products, or to add new features and functions that they traditionally would not have offered in existing products. With a large and diverse user base, Tradier faced the challenge of managing its partners in way that helps ensure it can grant credentials, track, monitor, and report in an efficient and equitable manner.

At the same time, the company recognized the inherent value of its partners for their power to leverage Tradier APIs to innovate. Tradier’s fundamental market disruption is the partner ecosystem, where the company is engaged along with its partners to deliver value to the entire ecosystem in the form of new products and services.

Embracing an API-powered ecosystem

Tradier has moved beyond providing great APIs toward engaging its ecosystem. If a customer wants a specific dataset, the company doesn’t automatically build a new product. Instead, Tradier looks to the ecosystem to build the product. With this approach, Tradier has taken its capabilities and multiplied them by hundreds.

“The fundamental difference between thinking about an API ecosystem versus an API product is the difference between being a participant who’s enabling innovation and not just a company delivering a set of technical capabilities,” Raju says.

Tradier takes an outside-in approach toward engaging its API ecosystem. Constantly listening to participants and helping to enable and empower them to create value is fundamental to the company’s business model. Rather than simply focusing on building new capabilities on its own, Tradier listens to what functionalities customers need and facilitates development. In many cases, the ecosystem generates the requested product organically rather than Tradier needing to do it.

“I love APIs because they allow you to empower others to create value. The concept of empowering others to create value along with you is what is the most satisfying, and the most fascinating, thing about APIs,” says Raju.

Delivering value at scale

Tradier handles between 500 million to 1 billion API calls and a billion dollars in transactions a month, and all of them run through the Apigee API management platform. Apigee’s last mile forms the single layer that manages Tradier’s infrastructure, including security, analytics, developer interactions, and execution. The company also uses Apigee to comply with an array of regulatory reporting, mandated by Tradier’s status as a FINRA (Financial Industry Regulatory Authority)-regulated entity.

“Apigee is integral to the Tradier offering. They have been great partners and have always collaborated and enabled us to innovate at a pace that helped Tradier attract developers and innovative companies. We see tremendous potential in the synergy of Apigee and Google as it brings to the market a vast extended capability set based on the Google Cloud Platform.”

Tradier is an API-centric ecosystem that delivers value to an entire set of players where the nucleus is the Apigee API management suite, which helps deliver, innovate, publish, manage, monitor, and secure the ecosystem on a day-to-day basis. Simplicity combined with product evangelism is the key to success in the API space, Raju says.

Tradier’s capabilities to innovate, iterate, and travel the journey with its customers, partners, and developers has yielded many rewards. The company’s long history of working with Apigee has enabled it to assemble a set of people and resources for creating engagement, as well as to create a winning set of APIs for delivering FinTech capabilities.

Considering the transformative future

Looking toward a future in which the financial services industry will experience ongoing disruption, Raju predicts that Tradier will continue to leverage APIs to lead the way.

“I think traditional banks are under attack. They are being replaced by a set of nimble, agile players that are offering a lot of new functionality to customers. This is forcing banks to think about how they can digitize their products through APIs so that they can provide the same functionalities as newer players.”

With companies like Tradier and others offering functionality that used to be in-house and exposing it outside, traditional brokerage firms are also being forced to rethink their model. Raju believes that this line of thinking also extends to the Blockchain.

“Exposing Blockchain-like capabilities through APIs is going to be a disruptive influence, and it will be critical for companies to think about how APIs, and more importantly Blockchain, can create value for us.”

Editor’s note: Today’s post is a Q&A with the VCCP London and VCCP CX team. VCCP London conceived of and built the Cadbury Worldwide Hide platform using Google Maps Platform as a way to get consumers ‘hiding’ eggs and engaging with loved ones during a time when they could not be physically together.

How did the team come up with the idea for the ‘Cadbury Worldwide Hide’?

VCCP London is the agency of record for Cadbury both locally in the UK and centrally with the Global team. So, when Cadbury briefed us in May for their Easter 2021 campaign, they wanted us to come up with a creative way to encourage people to hide eggs and get consumers excited about interacting with loved ones. At the time, the pandemic was constantly changing, and it was looking like we were going to continue to be in lock-down for the foreseeable future, into the Easter season.

We then came up with an idea: wouldn’t it be really cool if somehow you could still hide a real Easter egg for someone you love, but do it virtually. And then once it’s found, that real egg could be delivered to the seeker’s home. With the use of some creativity and technology, we brought this idea to life. The experience we developed allowed our users to purchase a real Cadbury Easter Egg, hide it virtually on the map in a special location, then write the recipient a personalized clue for him to find the egg. Once the seeker found the egg, they would receive a real, physical egg the hider bought for her delivered to her home.

We wanted it to be a truly meaningful one-to-one connection, to bring back some lovely memories for people, and to allow a real chocolate egg to be hidden for a loved one no matter where they were.

Why was this important to Cadbury?

Generosity is at the heart of Cadbury’s brand, and Easter is our opportunity to show that ‘there’s a glass and a half in everyone’. As we enter the second year of our campaign ‘Show you care, hide it’, we are flipping the Easter ritual on its head and showing that the generous act is in hiding an egg for someone you love.

Physical connection has been restricted by the global pandemic and that’s why this year’s Easter campaign sets out to connect people across the UK through the power of generosity.

Tell us a little bit about the technical side of the project. Which Google Maps Platform products did you use to create the user experience?

The Cadbury Worldwide Hide launched across 4 markets (UK, IE, AU, NZ) simultaneously. Integration with regional e-commerce and CRM partners brought the activation into the real world with chocolate eggs being delivered throughout the campaign as seekers found them.

Providing an engaging map experience to our users was key to the execution and by leveraging the Google Maps interface consumers already use on a daily basis, we were able to focus on our core campaign message. We built the platform using both the Maps Javascript API to render the 2D maps and the Street View API, which allowed users to hide their egg anywhere in the world for their loved one to find. We also used Place Autocomplete powered search allowing users to search for their favorite location while contextual hints kept hiders on track. Seekers were aided with a distance meter and hints system if they got stuck. Our Design and Engineering team used Google Maps Platform Cloud-based maps styling to customize the map.

To get the campaign to as many people as possible we prioritized accessibility throughout the site, from screen-reader support and relevant tab indexes through to full keyboard shortcuts within the map experience – allowing users to hide (or find!) their egg without ever using a mouse. Real user testing was done throughout the UX, design and development process to ensure best practices were being followed.

How long did it take the VCCP team to build-out the solution?

Discovery to the roll-out of the solution took about 7 months. Our Design and Engineering team started with a 4-week discovery phase in September 2020 where we developed a service blueprint that set the foundations of the project. By visualizing the entire process of a service from start to finish, listing all the activities that happened at each stage, and the different roles, actions, processes and systems involved, the blueprint allowed all stakeholders to align on the solution.

We started iterative cycles of development in November 2020, beginning with UX (prototype for user testing), UI (look and feel and customization of Google Maps using Cloud-based Maps styling), and then kicked off front end and back end development in December. We launched the Cadbury Worldwide Hide platform in early March 2021—just in time for millions of users around the world to enjoy ahead of Easter.

Did you experience any challenges as you developed the experience?

The biggest challenge was actually around adapting to change in plans in response to the desire to launch the platform across more markets than originally intended. During the development phase, we rapidly scaled up to develop the platform for Ireland, Australia and New Zealand in addition to the UK within the same timeframe.

What results were you able to achieve and how did you measure the success of the project?

One week before Easter Sunday, we had sold out of Cadbury Worldwide Hide chocolate eggs. There were over 2.26 million site visits with an average time spent on the platform of almost five minutes. Over 809k virtual eggs were hidden in total and 14.5k real Cadbury Easter eggs bought. The Cadbury Worldwide Hide platform was the number one Mondelēz International website globally, and a couple even used the platform for a marriage proposal!

Would you recommend this type of campaign and user engagement to other B-to-C brands, if so, why?

Direct to consumer capabilities are increasingly important for brands, particularly in the FMCG (Fast Moving Consumer Goods) space. Local lockdowns and restrictions on physical retail have accelerated our adoption of ecommerce. Not only have brands had to adapt quickly, but consumers are beginning to expect direct-to-consumer capabilities from their favorite brands. Cadbury recognized this behavior shift early. What the Cadbury Worldwide Hide did well was to innovate beyond the traditional DTC and ecommerce experience by gamifying the platform and enabling moments of human connection at a time when physical connection was impossible. 

What advice would you give to other agencies or brands thinking about creating user experiences with Google Maps Platform?

We learned a great deal taking on this project. Here are just a few highlights:

• Assume anything is possible.
• Our ‘Mobile First’ approach allowed consumers to access the platform from any device with consistent, engaging brand experience.
• Think big and beyond the traditional use of Google Maps and treat it as a foundation platform to build upon.
• Prototype and test early to validate your hypotheses. We created a technical proof of concept which enabled us to test using ‘real’ Google Maps and real people early in our design process.
• Don’t assume everything is accessible to everyone. You may need to build upon the ‘out the box’ functionality to ensure as many people as possible can use your solution.

For more information on Google Maps Platform, visit our website.

Imagine ordering a “ready-to-assemble” table online, only to find that the delivery package did not include the assembly instructions. You know what the end product looks like, but have little to no clue how to start assembling the individual pieces to get there. A poorly designed API tends to create a similar experience for a consumer developer. Well designed APIs make it easy for consumer developers to find, explore, access, and use them. In some cases, good quality APIs even spark new ideas and open up new use cases for consumer developers.

There are methods to improve API design — like following RESTful practices. But time and again we are seeing customers unknowingly program minor inconveniences into their APIs. To help you avoid these pitfalls, here are six of the most common mistakes we have seen developers make while creating the API — and guidance on how to get it right.

#1 Thinking inside-out vs outside-in

Being everything for everybody often means that nothing you do is the best it could be, and that is just as true for APIs. When customers turn to APIs, they are looking for specific solutions to make their work easier and more productive. If there is an API that better works to their needs, they will choose that one over yours. This is why it’s so important to know what your customers need to do their work better, and then building to fill those needs. In other words, start thinking Outside-in as opposed to Inside-Out. Specifically,

• Inside-out refers to designing APIs around internal systems or services you would like to expose.
• Outside-in refers to designing APIs around customer experiences you want to create. Read more about the Outside-in perspective in the API product mindset.

The first step to this is learning from your customers — be it internal consumer developers or external customers — and their use cases. Ask them about the apps they are building, their pain points, and what would help streamline or simplify their development. Write down their most significant use cases and create a sample API response that only gives them the exact data they need for each case. As you test this, look for overlap between payloads and adapt your designs to genericize them across common or similar use cases.

If you can’t connect with your customers — because you don’t have direct access, they don’t have time, or they just don’t know what they want — the best approach is to imagine what you would build with your APIs. Think big and think creatively. While you don’t want to design your APIs for vaporware, thinking about the big picture can make it easier to build non-breaking changes in the future. For example the image below showcases APIs offered by Google Maps. Even without diving into the documentation, looking at the names like “Autocomplete” or “Address Validation” clearly outlines the purposes and potential fit for a customer’s use case.

#2 Making your APIs too complex for users

Customers turn to APIs to bypass complicated programming challenges so they can get to the part they know how to do well. If they feel like using your API means learning a whole new system or language, then it isn’t fitting their needs and they will likely look for something else. It’s up to your team to make an API that is strong and smart enough to do what your customer wants, but also simple enough to hide how complicated the tasks your API solves for really are. For example if you know your customers are using your APIs to present information about recently open restaurants and highly rated pizzeria to their consumers, providing them with a simple API call as below would be of great help:

GET /restaurants?location=Austin&category=Pizzeria&open=true&sort=-priority,created_at

To see if your API design is simple enough, pretend you are building the whole system from scratch — or if you have a trusted customer who is willing to help, ask them to test it and report their results. If you can complete the workflow without having to stop to figure something out, then you’re good to go. On the other hand, if you catch rough edges caused by trying to code around system complexity issues, then keep trying to refactor. The API will be ready when you can say that nothing is confusing and that it either meets your customers’ needs or can easily be updated as needs change.

#3 Creating “chatty” APIs with too many calls

Multiple network calls slow down the process and creates higher connection overhead — which means higher operational costs. This is why it’s so important to minimize the number of API calls.

The key to this is outside-in design: simplify. Look for ways to reduce the number of API calls a customer must make in their application’s workflow. If your customers are building mobile applications, for example, they often need to minimize their network traffic to reduce battery drain, and requiring a couple calls instead of a dozen can make a big difference.

Rather than deciding between building distinct, data-driven microservices and streamlining API usage, consider offering both: fine-grained APIs for specific data types, and “experience APIs” (APIs that are designed to power user experiences. Here is a further theoretical discussion on Experience APIs) around common or customer-specific user interfaces. These experience APIs compose multiple smaller domains into a single endpoint; making it much simpler for your customers — especially those building user interfaces — to render their screens easily and quickly.

Another option here is to use something like GraphQL to allow for this type of customizability. Generally you should avoid building a unique endpoint for every possible screen, but common screens like home pages and user account information can make a world of difference to your API consumers.

#4 Not allowing for flexibility

Even if you’ve followed all of the steps above, you may find that there are edge cases that do not fit under your beautifully designed payloads. Maybe your customer needs more data in a single page of results than usual, or the payload has way more data than their app requires. You can’t create a one-size-fits-all solution, but you also don’t want a reputation for building APIs that are limiting. Here are 3 simple options to make your endpoints more flexible.

Filter out response properties: You can either use query parameters for sorting and pagination, or use GraphQL which provides these types of details natively. By giving customers the option to request only the properties they need, it guarantees that they won’t have to sort through tons of unnecessary data to get what they need. For example, if some of your customers only need the title, author, and bestseller ranking, give them the ability to retrieve only that data with a query string parameter.

GET /books?fields=title,author,ranking

• Ability to sort with pagination. Generally, you don’t want to guarantee the order of objects in an API response because minor changes in logic or peculiarities in your data source might change the sort order at some point. In some cases, however, your customers may want to sort by a particular field. Giving them that option, combined with a pagination option, will give them a highly efficient API when they only want the top few results. For example Spotify API utilizes a simple offset and limit parameter set to allow pagination. A sample endpoint as shown in the documentation would look like this

$ curl https://api.spotify.com/v1/artists/1vCWHaC5f2uS3yhpwWbIA6/albums?album_type=SINGLE&offset=20&limit=10

• Use mature compositions like GraphQL: Since customer data needs can differ, giving them on-the-fly composites lets them build to the combinations of data they need, rather than being restricted to a single data type or a pre-set combination of data fields. Using GraphQL can even bypass the need to build experience APIs, but when this isn’t an option, you can use query string parameter options like “expand” to create these more complex queries. Here is a sample response that demonstrates a collection of company resources with embedded properties included

"data": [
{
"CompanyUid": "27e9cf71-fca4",
"name": "ABCCo",
"status": "Active",
"_embedded": {
"organization": {
"CompanyUid": "27e9cf71-fca4",
"name": "ABCCo",
"type": "Company",
"taxId": "0123",
"city": "Portland",
"notes": ""
}
}
}
]

#5 Making design unreadable to humans

“K”eep “I”t “S”imply “S”tupid when you are designing your API. While APIs are meant for computer-to-computer interaction, the first client of an API is always a human, and the API contract is the first piece of documentation. Developers are more apt to study your payload design before they dig into your docs. Observation studies suggest that developers spend more than 51% of their time in editor and client as compared to ~18% on reference.

For example, if you skim through the payload below it takes some time to understand because instead of property names it includes an “id”. Even the property name “data” does not suggest anything meaningful aside from just being an artifact of the JSON design. A few extra bytes in the payload can save a lot of early confusion and accelerate adoption of your API. Notice how user-ids appearing on the left of the colon (in the position where other examples of JSON ideally have property names) creates confusion in reading the payload.

"{id-a}":
{ "data":
[
{
"AirportCode": "LAX",
"AirportName": "Los Angeles",
"From": "LAX",
"To": "Austin",
"departure": "2014-07-15T15:11:25+0000",
"arrival": "2014-07-15T16:31:25+0000"
}
… // More data
]
},

We think that JSON like this is more difficult to learn. If you want to eliminate any ambiguity in the words you choose to describe the data, keep the payload simple and if any of those labels could be interpreted in more than one way, adjust them to be more clear. Here is a sample response from Airlines endpoint of aviationstack API. Notice how the property names clearly explain the expected result while maintaining a simple JSON structure.

"data": [
{
"airline_name": "American Airlines",
"iata_code": "AA",
"iata_prefix_accounting": "1",
"icao_code": "AAL",
"callsign": "AMERICAN",
"type": "scheduled",
"status": "active",
"fleet_size": "963",
"fleet_average_age": "10.9",
"date_founded": "1934",
"hub_code": "DFW",
"country_name": "United States",
"country_iso2": "US"
},
[…]
]

#6 Know when you can break the RESTful rules

Being true to the RESTful basics — such as using the correct HTTP verbs, status codes, and stateless resource-based interfaces — can make your customers’ lives easier because they don’t need to learn an all new lexicon, but remember that the goal is just to help them get their job done. If you put RESTful design first over user experience, then it doesn’t really serve its purpose.

Your goal should be helping your customers be successful with your data, as quickly and easily as possible. Occasionally, that may mean breaking some “rules” of REST to offer simpler and more elegant interfaces. Just be consistent in your design choices across all of your APIs, and be very clear in your documentation about anything that might be peculiar or nonstandard.

Conclusion

Beyond these common pitfalls, we have also created a comprehensive guide packaging up our rich experience designing and managing APIs at incredible scale with Google Cloud’s API management product, Apigee.

Apigee — Google Cloud’s native API management platform — helps you build, manage, and secure APIs — for any use case, scale or environment. Get started with Apigee today or check out our documentation for additional information.