How to Explain APIs to Your Parents (Or Your Sales Team)

// 06.25.2015 // Platform API

Author’s Note: I am not a mechanic. I have never built a car. The views expressed herein do not represent the views of cars everywhere.

I have spent the last four years trying to understand APIs. Whenever they have been explained to me, they inevitably are drawn on a whiteboard like this:

And my take away has been that APIs are the bumpers around a system, which effectively means that I understand bupkis about how APIs work. So I decided to take a “Jess Do It Yourself” approach to this problem and create an explanation that makes sense to me, and hopefully makes sense to others, too. I’ve been talking to colleagues, to developers, and to marketers, and I think I’ve got it. I’ve finally found a way to talk about APIs, so that your parents (or your sales team) can understand what they are and what they do. And if I’ve gotten anything wrong, please do let me know in the comments.

Let’s start from the beginning.

Think of your product – in our case, MediaMath’s TerminalOne – as a car. You have the body, the steering wheel, the seats. These are the parts of your product that most people see and interact with, so we’ll call them the user interface (UI). In the case of T1, the UI is what you see and click on and type into.

Compact car blueprint isolated in white background. The abstract car has no real prototype
Then you open the hood, and you have the engine. The engine is the whole of all of your technical systems, all of the working pieces that power your product. These systems, like a car engine, are made up of lots of smaller working parts. The carburetor, the crankshaft, the ignition, the catalytic converter, the windshield wiper fluid, the antifreeze, and you get the idea (again, not a mechanic. I just searched “car parts” – don’t judge).

In the case of software, your “engine” is made up of many different databases, reporting engines, servers, bidders, etc. It’s these individual pieces working together to power your product’s engine that developers call “services.” And while with a car, you can’t easily access one piece of the engine and use it to power a wholly different machine, in the software world, you can – but you’ll need to build APIs first.

APIs (application program interfaces) can be thought of as the plugs and cords to individual services (credit to my colleague Jake Gardner for help with this analogy). Think of how an iPhone uses a special cable that can only transfer certain information (photos, music, etc.) between certain other products. Try plugging that same cable into your air conditioner, and nothing happens. Coolant data doesn’t travel to your phone, and photos don’t travel to your air conditioner. APIs are like those special cords. They are specialized communication protocols that different services use to talk to each other. Each API will be written to make it possible to access information unique to that service.

Different type power socket set, vector isolated icon illustration for different country plugs
Each API or “cable” also requires a unique “plug” – in this case, an API endpoint – be built in order to access the service. If your service doesn’t have an API endpoint, it doesn’t matter how many cords you’ve got, there’s nowhere to plug them in to start accessing the service’s functionality.

But think of the possibilities you could open if each service were built with these plugs and cables! Perhaps you’ve got dreams of building a temperature controlled treadmill, and you to use the air conditioner from the Mini, only you can’t purchase just that feature from the car manufacturer. This is what open API development is all about: Making it possible for people to access software feature by feature or service by service to build all new, incredibly powerful products.

Over the last couple of years at MediaMath, we’ve been hard at work building these plugs and cables for T1 services. We have clients who have innovative ideas for bidder exhaust – all the information of every bid we’ve won, lost, or passed on – so we’ve built an API to our bidder’s firehose of data. Others wanted to build a version of T1 in their native language, so we gave them access to every single service, and they built their own T1.

A great car demands great parts, and we think our carburetor, crankshaft, ignition, and catalytic converter are so great that they should stand on their own and be sold on their own, and that by selling the parts on our own, we’re letting marketers build the best possible car for their need.

We are trafficking hundreds of terabytes of data a day and millions of impressions a second. We can’t even begin to fathom every product idea that could possibly be built using this information, so instead of locking it in our silos, we want to build access channels and empower the ad tech ecosystem with it.  We can’t wait to see the super-charged products they’ll come up with.

A Picture of Jessica Edwards


Technical Brand Manager Jessica is the Technical Brand Manager at MediaMath, where she is building MediaMath’s engineering messaging and sharing it with the world. She is obsessed with translating technical stories into accessible language, and has led a similar efforts at other tech companies. She earned a BA in Anthropology and a BS in Journalism from Boston University.
1 Comment.

One response to “How to Explain APIs to Your Parents (Or Your Sales Team)”

  1. APIs are works like those special cord and they much specialized communication protocols that varies services use to talk each other, each API will written to make it possible to use unique data.

Leave a Reply

Your email address will not be published. Required fields are marked *