Gail Frederick is the vice president of eBay’s mobile and developer ecosystem and oversees the architecture team for eBay’s mobile apps. She joined eBay in 2014 after a spell at Intel, and has served as a board member for the OpenAPI Initiative since 2017. That same year, she oversaw eBay’s biggest technical change to date: remaking eBay’s public API and developer ecosystem.
This interview has been edited and condensed for clarity.
Increment: You speak about APIs in terms of decades. What has changed recently?
Gail Frederick: eBay was really early to the game—we’re celebrating the 20th anniversary of our developer program this year, and we were one of the first to allow programmatic access to our marketplace. [Other] innovative companies have been using APIs for 10 years or so. Now we’re in the age of data, and that makes APIs more necessary [than ever]. From a commercial point of view, it’s [the] companies [that] understand how to wield APIs and grant access to their systems that will win.
How does that access offer an advantage?
For eBay, it allows us to bring commerce everywhere. We have suites of APIs that cover all activities: managing your account, buying and selling, searching. That gives us [the] strategic flexibility to partner creatively and broadly, and to decide with those partners how to bring eBay to where buyers and sellers are today. That’s distributed commerce, and it’s a fundamental shift in how the internet works. It used to be you had to go to a browser and [then] go to [eBay’s] site if you wanted to transact [with us]. Now [eBay] can transact wherever our customer is, whether on a price comparison site or a mobile shopping app.
What about the loss of control? APIs aren’t funneling people in through the front door.
eBay thinks of APIs as a front door. Half of our business-to-consumer selling activity on eBay happens via API—that’s more than $20 billion annually. APIs [are] a business asset, a way to drive creative business deals. My job is to provide the full spectrum of capabilities for buying and selling and managing your business on eBay. Our developer programs have also evolved so that we no longer [provide] APIs [that allow] open access to all of eBay for everyone. Now we’re using APIs [more selectively]. We’re smart about which partners we provide access to for which parts of our business.
eBay went through a big API rewrite in 2017. What prompted it?
When I joined eBay [in 2014], I got a look at our offerings to third-party developers. I was really shocked that they were the original APIs from 2000. We [also] didn’t have a thriving developer program. We had a lot of scale because we were eBay, but we didn’t have a lot of energy. The semantics of the APIs were so old that it was turning off younger developers and slowing down integrations. Innovation was really dying in our third-party ecosystem.
We got a new CTO, Steve Fisher, [and in 2015, as the director of commerce OS,] I basically begged him to flip [the switch on a revamp] because this was a gigantic opportunity. [I told him] that if we [could] modernize our APIs, we [could] bring in a whole new class of developers and ultimately grow our business. He said, “Go for it.” Six months later, in 2016, we had these first 10 APIs. Scale adoption of the new APIs happened in 2017. Now, three years later, we have 28 families of APIs, more than 300 endpoints, and we’re very close to having modern RESTful coverage of all eBay capabilities.
What did that process look like?
eBay has a roadmap planning process, and getting on that roadmap was the first step. I worked hard with individual VPs to prove the business value of APIs [by showing that] their teams could meet and exceed annual gross merchandise volume goals by leaning in to our developer ecosystem. [We also] sometimes offered to offset resource constraints in partner teams. [Ultimately] my engineering team and teams across the company worked together to deliver the new generation of eBay APIs.
We rarely deprecate APIs [at eBay], and it’s even more unusual to decommission API endpoints. Deprecation is a documentation-only process. When we decommission an API endpoint, we have an 18-month notification policy to our developer community—many different kinds of communications precede the turnoff event. Our new APIs have new endpoints, and of course it’s much easier to turn on new capabilities.
How did you pick the 300-odd new endpoints?
In 2017, we chose the most essential parts of eBay: creating a listing, managing an order, [and] searching for listings. [The company is] in a tech renaissance—we’ve spent a lot of time modernizing our software platform, and our teams are creating new features. We’re now encouraging those teams to deliver new features via API. [What that means is] as we modernize our payments platform or change how we want sellers to describe their products, we’re making those changes on the site and in the APIs at nearly the same time. [We want] our third-party developers [to] have the same access to new differentiating capabilities.
Why is third-party access so important?
Our [third-party] developers represent about half of the consumer listings on eBay marketplaces. Documentation and support are really important [for them]. So is outreach. We have a monthly developer council—a private, NDA-protected forum of our best [third-party] developers, where we share our roadmap, provide access to early-release APIs, get feedback and buy-in, and listen and make changes. When we do release an API, we [want to] have confidence that it will be adopted.
I also created a developer conference a couple of years ago called eBay Connect, which happens once a year at our San Jose headquarters. It’s a large gathering of our top [third-party] developers, and we go in depth into our APIs’ code and how to use them. We also get eBay’s leaders onstage talking about how the technology offerings match our business goals, and why. I think of it as a bootcamp for these partners. Then we take that two-day conference on the road to the biggest regions where eBay does business—Australia, China for exports, and Europe—and we run the event again.
I love engineers because if they don’t like something, they’ll just tell you.
What do you get from those meetings?
My favorite thing is the honest feedback. I’m an engineer, and I love engineers because if they don’t like something, they’ll just tell you. That’s so valuable. My biggest [goal] is to bring developer voices [back] to eBay leadership. As a company, we may want to move in a certain direction, but we need to ask these questions when we have new APIs coming out: Why should [developers] care? How can a developer [use this to] make a more compelling offering for sellers or buyers on eBay?
You mentioned using RESTful APIs. Why that and not an alternative?
It’s simple, it’s intuitive, and there’s an awful lot of tooling around the management of RESTful APIs. Engineers can save queries and try things quickly. We wanted to create a really productive way for new developers to get started with eBay APIs.
In the past, for our SOAP APIs [which eBay first released in 2000], we produced elaborate software development kits (SDKs) and had to choose programming languages or environments we would support with APIs. When we focused on a RESTful API portfolio [starting in 2016], our obvious choice to bootstrap new developers was OpenAPI.
Can you tell us more about OpenAPI?
OpenAPI is a specification document for an API. It’s written in JSON, or it could be written in YAML. It describes all the endpoints of an API as well as request and response parameters, and it [has a lot] of metadata. So 100 percent of our RESTful APIs have OpenAPI specs. There’s a really rich set of industry tools that take an OpenAPI spec and transform it into boilerplate client code. You can get up and running trying an API in a couple of minutes. That’s magical because for developers, time is money. They don’t want to waste their time writing infrastructure. They want to spend their time on differentiating business features.
I ended up joining the board of OpenAPI, I loved it so much. The promise of OpenAPI is [that] what’s been delivered is instant, boilerplate code in whatever language you want. Whether you write in Rust or Java or PHP, you can generate client code and spend your valuable time adding features. This work also allows me to maximize my own engineering resources at eBay. I don’t produce SDKs anymore. I put my effort into docs and OpenAPI specs and articles on the portal.
What are the biggest, most common mistakes on the part of API providers?
The first is assuming your ecosystem wants the same thing you do. I spent a lot of time convincing internal eBay leaders that [outside] developers look at eBay fundamentally differently than we do. We know all the ins and outs and quirks of our almost 25-year-old platform. Developers don’t have a tolerance for those old weirdnesses. They want to integrate and move on to the next activity.
The second is authorization and security. Especially if you have an older API, [it was] probably delivered at a time when cybersecurity was less of a priority. Now it’s extremely important to understand who’s calling your APIs, why they’re using them, what they’re doing, and [whether] it’s beneficial, neutral, or challenging to your business. I just can’t stress [the importance of security] enough. [We want to be] unlocking good developers and helping them do more, [while] excluding developers [who are] doing things that aren’t in our business interest.
How do you root out those “bad” developers?
Every developer program has a registration database. If you don’t, you have unprotected endpoints. eBay has a registration database of developers, and developers use authorization tokens when they call our services. The hardest part for us was the age and the breadth of our APIs and being able to stitch [together] all the data sources of “Developer A called API B at time C and made D dollars.”
Once we did that, we had this “aha” moment of transparency. It [was] like being in The Matrix. All of a sudden, I could visualize the patterns of individual developers [and] also create these behavioral groups of developers who might be doing the same thing. Then we can add more data about the business value of that developer and find trends. Once you can see the trends, you can control them using rate limits or [give them] access to more capabilities.
What does the future of APIs look like at eBay?
The next big thing for eBay is finding efficient ways to replay actions on our marketplace. The second is enabling cross-border trade. The more capabilities we can get to ease the burdens of selling internationally, that’s where you’ll see our focus.
What about API innovation beyond eBay?
I would call out data.gov and the push to open up these incredible stockpiles of U.S. government data via API to citizen developers. It’s the people’s data. Again, we’ve spent the last decade creating these massive computing systems that have allowed us to create these massive data sets. We’ll see big leaps forward as those data sets are shared and integrated.