Tanya Vlahovic, eBay

All right, it’s time for Breaking Changes again, and I’m really excited to have someone I’ve worked with before as part of APIs strategy and practice in the OpenAPI Initiative. She is the head of developer ecosystems and lead API architect at eBay. Today I have Tanya Vlahovic. I almost got it there, but thank you for being with me.

Thank you, Kin. Thank you for inviting me to your Breaking Changes series. I am super excited to be with you today to talk about the APIs.

Yeah, so let’s dive in with just a little bit about eBay, because I know folks are very interested in what y’all have been doing over there for a while. Why does eBay do APIs?

That’s a good question. eBay launched the Developers Program back in 2000, literally pioneered the API space. I was not there 20 years ago, so I’m not sure how the leaders back then came up with that idea at such an early stage. For sure I think it’s great they did. And now I think it’s very clear why we still do APIs. APIs bring a lot of value to our customers, buyers and sellers. It is a factor channel through which value is exchanged. For us at eBay it’s how we expand our business into new contexts and new experiences, so it’s a super important program for us.

Yeah, eBay’s been a leader or a pioneer in the space and a model that I can hold up for other folks in the space for a number of years now. So when people are using these APIs, what are they building? What types of applications and integrations do you guys see?

Marketplaces in general are complex. It’s way more than just managing inventory and enabling buyers to purchase what they need and want. Managing inventory is one of the aspects, but that also includes all sorts of listing optimizations. It’s about all the aspects of fulfillment and logistics, including after-sale activities like cancellations, returns, refunds, and so on. Then member-to-member communication, then reputation of buyers and sellers, product reviews, payments, marketing and advertising activities, and so on. We started with the sell APIs 20 years ago. We have so many large B2C sellers who come to our platform and sell at scale on eBay, sometimes on other marketplaces as well, and it’s amazing how vibrant and large our developer ecosystem is. There are third-party apps, third-party developers who manage all these aspects of the marketplace that I just mentioned. Then down the road we focused on affiliates and purchasing eBay items from third-party experiences. We have direct integrations, when businesses directly integrate with our APIs, like average B2C sellers, and in that case they work in their own interest. Then we have service providers who extend our marketplace by providing value-added services, building platforms and tools to add additional value to our sellers. For example, service providers who enable multi-channel selling, enable sellers to manage their inventory across marketplaces and channels, not just eBay. So there are third parties that just keep extending our business and providing services on top of it. And just think of all of these aspects that I just mentioned in the marketplace.

So it’s much more than just revenue. There’s a number of reasons listed in there.

Revenue is probably the biggest reason but not the only one. In the end I think it all leads to generating revenue. The Developers Program is really huge, so we give tools to our developers, when I say tools I mean APIs and everything else that goes with the APIs, like SDKs and so on, to thousands and thousands of developers around the globe to work on our platform, to extend what we do, to extend our business again into new contexts and experiences. And that is huge. Imagine tens of thousands of people working with your platform and building on top of it, and that’s a win-win model. So this is about revenue, but we also do APIs for a good cause. We do have support for charity organizations across the APIs on both buy and sell side, and we are very proud of it. Our eBay for Charity program is huge. We raised, I believe, 35 million dollars just in Q1 this year, and that is impressive. We have APIs in place to enable our developers, to enable their sellers and buyers, to support their favorite charities in their experiences. So that’s yet another example. Then we are very proud of our collaboration with National Health Services in the UK. We partnered with them, we built a portal for distributing PPE, personal protective equipment, to healthcare providers across the UK. This is 100% built on the buy APIs and they do this distribution for free, and more than 3 billion items have been delivered through this channel. So that was not done because of the revenue.

Yeah, I’m guessing the APIs and the way that sellers are connected into eBay really helped you adjust and deal with the pandemic. I’m sure buying habits really changed during all of that time.

Yes, buying habits really changed. There was an influx, and we live in a connected digital age, that is true, but that was really intensified during the pandemic, because it was not only about shopping. That became the way how people work and learn and entertain and communicate and do many other things. So we haven’t missed a beat during that period. There was an influx, but we managed to do that, and then again we used our APIs for some good things as well.

Yeah, so I’m guessing at this point, a lot of folks who are listening to the show are still trying to convince their leadership that APIs are a good idea, so I’m guessing at this point, are APIs a priority for the leadership at eBay?

Yes, absolutely. Again, we have been dealing with APIs for more than 20 years, so absolutely, we have full support from leaders and executives. And considering the scale we operate and the contribution and value that comes from our developer community, it’s a must for us to prioritize the API program and to ensure that the APIs follow the business initiatives. There are new business initiatives that are coming, so we make sure that the APIs are at that point.

How long have you been at eBay in total?

So that’s my 11th year. I joined in January 2011. I worked in the identity domain, and that’s where I was feeding near-real-time entity resolution of user accounts into customer entities. Then I joined the risk team, I was focused on risk assessment of eBay sellers, and then I think six years ago I joined the Developers Program, with the developer ecosystem. This is where I clubbed together all these things that I learned about the APIs before. Even before joining eBay I worked on APIs, and then my identity and risk knowledge and backgrounds, all of these things came very nicely together.

So what keeps you doing APIs? Are you going to stick with it, are you going to evolve into something, whatever’s next?

I don’t think we are done. At least I don’t think I am done with all of the things that I have been thinking we should do. Six years ago we decided to completely revamp the program, that was a lot of work. We started from the APIs, we defined standards and specs and established a governance process, I keep talking a lot about that. That was the first page. Then we focused on the KYD, or know your developer, process, we came up with that acronym a couple of years ago, so we try to understand more about how developers integrate with our APIs and the value that they bring to us. And then it turned slowly into SYD, or support your developer. So we are focused on SDKs now and drop-in solutions, we are revamping our webhook notifications, our async APIs, we keep coming up with new integration models. When it comes to innovation, we foster both direct and indirect innovation, we also define new integration models and partner with developers to implement them. I have been doing this for the last few years, and that’s probably the most interesting thing, to think of new ways for developers to integrate with us, and there is always something new that keeps me busy. So that’s a big space.

Yeah, you touch on a couple of things we’ll dive into a little deeper in a bit, but one thing I’ve known about you, the reason why I’ve stayed in touch and kept an eye on what you’re doing, is you’re such a prolific storyteller about what you’re building and what you’re doing. APIdays, API Specifications Conference, your blog, The New Stack, your own events. Why so much storytelling around what you’re doing? Why not just the tech of it?

I think there are a few reasons for that. I was not doing that much before I got hooked on the APIs. We are proud of the work that we have done since we decided to revamp our program, because that was a huge part especially six years ago, it’s easier now, so I sort of want to evangelize our developer program. Then I also want to share our journey with others who face similar challenges and issues that we faced, I think that’s very common in our industry. And then I also learned a lot from the stories from other relevant people in the industry, and you are one of them, so I just want to give back.

Yeah, you’ve provided a lot of stories for me over the years, and talks, as well as just me listening to what you’re telling and then writing a story about it or talking about it. So thank you for that, I appreciate it. So do you encourage your team to do this as well?

Yes, actually I do. They tell stories at eBay events for external developers, they tell stories at the internal events as well, which are important, because whatever we do on the public API side is applicable to the internal APIs and microservices and everything else. We have internal conferences at eBay where engineers in general come to talk about work they are proud of, and people from my team participate in such events. Then they write tech blog posts both internally and externally.

Nice, I like that, that’s a good way to make it really loud and reach both internally and externally. So moving into your developer ecosystem, you all have a lot of resources around it. What is the most important thing your developers depend on besides your API in your ecosystem?

Okay, so besides the APIs, they actually depend a lot on, I would say proper feature richness as well as reliability and availability, that is very important. And they depend on communication and support. I really believe that the APIs should be self-explanatory, especially all these new APIs that we introduced, and we have a pretty good governance process in place. But again, we are a global marketplace and there are so many regulatory and compliance requirements, they are just part of our life, so quite often there are changes that impact our integrations and we are trying to address all of them and support our developers. I would say communication, at least in the case of our marketplace, is really crucial, because such regulatory and compliance requirements keep coming, I sometimes think like every month. Sometimes we have to move thousands of developers, and that’s not easy.

Yeah, I can imagine that causes a lot of unforeseen challenges within your roadmap, but again, keeping it pretty interesting for you as well.

It’s not just the roadmap. We sort of adjust that, but then imagine moving thousands of developers to integrate these new things and to stay compliant. That’s a challenge. We just went through one round of that with the value-added tax in Europe. There are things that keep coming, GDPR. Okay, GDPR is beyond the marketplaces, but that’s one of the examples. And there is this extended producer responsibility that’s coming in France the beginning of next year. So there is always something new coming that developers need to pay attention to, especially in case of the global marketplace across borders.

Yeah, I just finished recording an episode on the government, right now they have the ACCESS Act going through Congress, it’s not enabled but companies over a certain size have to have APIs and allow for interoperability and accessibility. But there’s a lot of details missing, as you and I know when it comes to these types of policies. There’s actually a lot more detail you need, you have to say, well, what does interoperability mean, what does accessibility mean, what does privacy mean. So we’re having a lot of conversations about those things, and I couldn’t imagine what you have to face with not just the US but France, UK, Europe.

Exactly, and it’s interesting when engineers start to talk to lawyers. It’s always interesting, it’s hard to understand. Okay, we are interpreting the law, we have to implement that, so what does that exactly mean? Sometimes I joke that I spend more time in meetings with lawyers than with engineers, and sometimes it is true, it’s not always a joke.

I’m with you. I would say about 15% of my time is working with lawyers and trying to figure it out right now, so I feel your pain. When it comes to dealing with change and working with your developers as you do, what’s the most effective way that you communicate with them?

So we actually believe that communication is one of the colors of developer experience, so it’s very important. We use all sorts of channels that we have. Of course we update our developer portal, that’s the first thing to do, obviously. We recently added support for RSS feeds to some of the important pages to make it easier for developers to ensure that they are not going to be missing the message from us. Then we do targeted outreach, recently emails. We have a developer council, that is a monthly forum with top developers in our ecosystem, I literally meet with them once a month. Then we have partner teams and partner managers who also communicate the important developer program changes. Then there are newsletters, in-person events around the globe in the past, and now our virtual events, conferences and so on. We just try to talk, we use all sorts of channels just not to miss the opportunity to communicate how important the changes are and to make sure that our developers understand the changes that are coming in and get ready as much as possible. We received some really positive feedback recently from the developer community that we are improving this communication, and I think there are more regulatory requirements nowadays than how it was a few years ago, so we’re just trying to send a message as soon as we have the required information about what the changes are going to be on the API side.

Nice. Well, one of the ways I know that you make it easier for developers to deal with the change in what’s happening is OpenAPI. You use OpenAPI pretty extensively to document your APIs, to do many other things, and you make them actively available and easy to find for your developers, and then you tell stories around it as well. This is one of the areas that I know you from, is from the OpenAPI Initiative. Why did you join the OpenAPI?

So there is a story behind that. When we decided to leave one program in 2016 and go with RESTful APIs, we had an internal proprietary service or API descriptors spec and some internal tools to handle it. We started from there internally, and then we realized that we should help our developers to also build their clients faster and easier in order to integrate with our APIs. We decided to build our own SDK in Java around that proprietary spec, and we made it right, we somehow implemented that in Java. And then, okay, so what should we do with other stacks, should we start supporting and so on? And then I was the one who suggested the complete switch to the OpenAPI spec, and some folks internally really agreed and liked the idea and supported this. And then we joined the OpenAPI Initiative. We really support standardization around the APIs in general. The OpenAPI specification aims to standardize the way APIs are described, and that’s why we joined the OpenAPI Initiative as a member. We use every single opportunity that we have whenever we meet with our developers to call out that we have the OpenAPI documents.

Yeah, I regularly use you as an example to other API providers, because the majority of the members of the OpenAPI Initiative are service providers or tooling providers, and you fit the profile of an API provider that just really understands the value and the potential. So you’re a blueprint that I point to on a regular basis. So would you say OpenAPI is more for your internal teams, or is it more for your developers and your consumers and the tooling that gets generated for them?

So again, I’m not in charge of all of the internal APIs, but I am for the external APIs. When it comes to the external APIs, we have 100% coverage. I mentioned that we have that governance process, and one of the items on that checklist has to be OpenAPI. There are literally no exceptions since we adopted OpenAPI, I think that was probably back in 2017 or something like that. We just said that every single API has to have the OpenAPI document, and we’re very strict, this is just part of the release process, and there was no single exception over the years. When it comes to internal teams, they are using it more and more, more and more things across eBay use this OpenAPI. It’s not mandatory as it is for the external developers, but I think there is more and more, people understand that the OpenAPI spec brings value, not just from the client and consumer perspective in order to generate these clients and to integrate the APIs faster, it’s just about the API-first approach. This is the easiest way to keep iterating between producers and consumers and so on, so we use it more and more internally.

And then when it comes to external developers, I just want to tell a story. A few years ago my boss challenged me to integrate a product search API in less than 90 seconds. There was an eBay conference, and I just said, okay, let me try to do that during that conference. I started from the eBay developer portal, I went to the portal, I downloaded the OpenAPI document, I imported it into Swagger, generated a client, imported that Java client into my Eclipse, modified one of the test classes, and I literally integrated in 70-something seconds. I was able to call the search API. So imagine the pressure I was understanding, everyone was timing me, I was on the stage, and there was no chance to do anything wrong because I didn’t want to miss my 90-second window. We had so much fun with this.

Wow, that’s pretty impressive. That time to first call is super important and such a critical metric for all API providers and consumers, because that’s what matters, that you can land on the portal, get your access, whatever tokens you need, and be able to. And you did it code-wise, there’s other ways you can do it with clients and other things, but you generated code and actually made it within an IDE, which I say is even more impressive.

Yeah, it was. I admit that the API is sort of simple, that’s a search API, but it doesn’t matter, still, 90 seconds is 90 seconds.

Well, I think that’s an impressive demonstration. It’s powerful to do at shows or as a demo or conference talk, so I like that. Well, moving on from OpenAPI but staying in the same realm, you made a pretty big splash lately with your adoption of AsyncAPI. Why did you do that?

So I just mentioned that we really support standardizations around the APIs, and the AsyncAPI specification for us is very similar to the OpenAPI. The OpenAPI is to standardize how the request-response APIs are described. The AsyncAPI specification aims to standardize how the asynchronous APIs are described. Both specs are both human and machine readable, there are tools, visualizers and all sorts of things. We do expect more tools and SDKs around AsyncAPI and I hope that that’s going to come. Because we are in the process of completely revamping our webhook notifications, it was so natural for us to adopt the AsyncAPI, and then to show this to our community. Earlier this week we had again our conference, this time virtual, for our top developers, and this was one of the highlights. We used that opportunity to show the new things that we did on the platform and also to call out that we have the AsyncAPI documents published. This is again going to be a must for every single notification type that we publish, there has to be AsyncAPI coverage.

So is sync going to outpace async? What’s going to be more important moving forward, sync or asynchronous, or are they both equally important depending on the use case?

I think they are important. I don’t think the asynchronous APIs in general can replace the synchronous APIs. Just think of a user coming to search for something, there has to be a request-response API behind that. So I think they are equally important, they will just solve different things, enable organizations to scale in the right way and to optimize on their resources, to optimize on the client side.

Yeah, I get that question a lot from a lot of folks trying to understand the space, and I would point to why your storytelling is so important. I won’t mention which analyst, but there’s a handful of top analysts out there, and they pointed to your story in The New Stack about AsyncAPI being correlated with a pretty big spike in adoption and inquiry calls from folks about using AsyncAPI within the enterprise. So the reach of your storytelling is pretty significant. Thanks for doing that.

Thank you. We’ll continue doing this because we think this is the right thing to do. There’s a body of architects at eBay who are focused on the technology, on the APIs, and so on, and we are very well aligned when it comes to these concepts.

Yeah, so across all of this infrastructure, the sync, asynchronous infrastructure, you probably have to deal with a lot of legacy change. Talk to me about how you deal with change across these public APIs.

Yeah, that is a good question. We have legacy APIs that are still heavily used at eBay, and it is actually not that easy to move developers to the new stack, to the new APIs, because it makes sense from their perspective, they invested years and years of integrating with the APIs that eBay provided. We have some developers who were with us from day one, which means for 20 years they have been using our APIs and tools. So we just try to keep the contract, try to minimize the changes, try to incentivize developers to integrate with the new family of APIs. But there are use cases that we have to go and change the legacy guys as well, just because of the scale, and again I mentioned that we keep getting these regulatory compliance requirements that we have to address, so we have to make changes across people. But we also invested a lot, especially over the last probably 18 months, in cleaning up our portfolio, so we are deprecating and decommissioning APIs that are not aligned with eBay policies, that don’t bring much value to us, our buyers and sellers, that have lower traffic. And again, I mentioned SYD, support your developers, so we want to support our developers but with the right goals, and I think so far it’s going well. I think developers understand that, and that’s what we will continue.

So that’s moving things forward and dealing with the past and keeping things stable. How do you contemplate the future? How do you come up with new features, what’s that feedback loop look like that goes into your roadmap from your community?

That feedback loop is very important for us. Again, I mentioned that we are trying to have all of our APIs aligned with the business initiatives. We have so many business initiatives. We launched the Authenticity Guarantee program. eBay’s managing payments now, that was a big deal, managing payments, so we had to change plenty of our existing APIs and have the new APIs. We are pushing for that API-first approach. We just did that with two capabilities, the only way to upload videos with the platforms is via the APIs, and then we also enabled that cost-per-click model for sellers to do advertising on eBay. In such cases we partner with trusted developers, we share the contract up front, iterate, that feedback loop is very important. And I keep saying that we actually leverage both direct and indirect feedback. Directly, because we literally work with our trusted developers and go over the APIs and proposals, and then the indirect feedback comes from our insights into how developers integrate with our APIs, that’s part of the KYD idea, know your developers. We really have a decent data set about our developers, and we understand very well how they use the APIs, and we look into all sorts of metrics that we have, operational but also business, that’s very important, and then we try to measure our API strategy, to measure the outcomes of the APIs.

So I’m guessing you have a lot of data on what’s important, what matters, when it comes to commerce, global commerce. What are the biggest challenges and threats that you see across that that keep you concerned?

So we are monitoring what we have on our side, and we are also monitoring the technology landscape in general. We are trying to stay in the game and to follow the best practices and to get prepared for the challenges and to adapt accordingly. The global pandemic was an unexpected challenge, for example, and we managed to pivot pretty quick to respond in the right way, and we haven’t missed a beat on our deliverables. It was not just being reactive, but we turned into problem-solving more. I mentioned that portal that we built, and we released that within a week, by the way. I have never ever in my professional career shipped something to production within a week, but that’s what happened with that portal, because it was clear to everyone that we have to do it, and the sooner we do that the better, because we’re extremely proud of having an opportunity to help save lives. So there are challenges, but there are also ways to face them. We look into our data, both operational and business metrics, we take these numbers, go to our business people, go to our product people, talk, share, and that’s basically how we are trying to define our roadmap, because in our case developers to a great extent shape our roadmap because of the value they bring.

Yeah, that feedback loop, the API-first, the agility and flexibility you get with that, you can really adjust and go where you need to go in response to any new things. So that’s a great way of dealing with change and challenges that you’re going to face, or threats from anybody that might potentially come and change the landscape externally in any way. I like it. So what do you think, I don’t like predicting the future, but what do you think you’ll be doing, APIs with sync and async, in 10 years? Things never move as fast as we think they are, but where do you see yourself in 10 years?

Wow, 10 years is a long period. I’m also trying not to predict the future, at least not when it’s about me.

I totally give you a pass on this question.

I just take it week by week, day by day, and like you said with the challenges, just try to be educated, understand what’s happening, and deal with things in the short term but have a good strategy as well. So still I’ll try to answer your question. I hope that I will be doing something related to the APIs in 10 years. I think APIs are everywhere nowadays, and again, we live in a digital age, so it’s all about APIs, and I don’t think that that will change. So I guess I will be doing APIs or something related to APIs.

So when it comes to APIs, where do you stay in sync, in tune with what’s happening? How do you get your information?

I attend relevant conferences, I read, and there are people who I follow, you are one of them. There are API programs that I follow, all marketplace-related stuff, all relevant developer programs. That’s basically it.

Well, I think the information intake is dependent on people like me, people like you. When it comes specifically to getting women more involved in this space, that’s one of the things I’ve always been trying to do with API Strat, the API Specifications Conference, I know APIdays has a program. What sort of advice or guidance would you give to any woman or person of color to get going in the space and make their mark?

So that’s, I personally am encouraging women to share their stories, by doing this myself, that’s how I’m seeing that. I had my talks at Grace Hopper Celebration multiple times, and they were all technical topics, tech topics, which I’m proud of, so I was not talking about other things like career path. I think it comes together. Last year I had a round table session, and I represented eBay at Grace Hopper with a number of attendees, and I was really proud of it considering the audience. Every year I try to speak at at least one of the women-in-tech conferences. This year it was Women in Technology World Series, something like that. So I think it’s good to act as an example, and I’m hoping that we’ll be seeing more women in our space hopping on the stage and sharing their stories, and I really would love to see the tech topics covered.

Yeah, I’m really doing a lot of work and research as part of this show to really reach out and find those spaces where women are telling their stories about the APIs they’re working on and what they’re doing. So thank you for being that model, because it’s super important to have someone go, look who’s building that and look what she’s done with everything over the years. To kind of steer in a different direction, when it comes to eBay, what are some examples of things you’ve purchased from eBay personally?

Oh, I love this question. I have a few interesting stories. I purchased the Dyson vacuum cleaner recently, that’s an interesting story. eBay has now this certified refurbished program, and I was really focused on finding a certified refurbished vacuum cleaner, but I ended up buying a brand new one on eBay with a discount that I received from a seller, Dyson directly, and I paid less than anywhere else. I just could not resist. Then during the global pandemic, and we are still in it today, like everyone else I was buying everything online, so I purchased hair-cutting scissors, a screwdriver repair kit for eyeglasses, I had to do it myself, and then even a plant. And then I found the Lego Star Wars Millennium Falcon Ultimate Collector set, that was the largest Lego set last year at the moment, with more than I think 7,500 pieces, something like that. It was impossible to find it in Lego stores or anywhere else, and that was a birthday gift for my son, and we had a lot of fun spending days and days setting it up. And then there is one more interesting story. I was using the checkout API that my team built, and I was the first one to test the expansion to Hong Kong, so I purchased a ruler from Hong Kong. And then, what’s interesting that I sold on eBay, yeah, of course I sell things, I sell my son’s books and stuff like that, but the one that I recently sold, it was a gaming PC that my son built with help from a friend in the past. The boys were in middle school, they built that PC, and I sold it on eBay four years later, and the price was such that I could not complain at all. That was such a pleasant surprise, I had no idea what I’m going to do with that old gaming PC, and I sold it.

Yeah, I think that’s a great example of the circle you have. You’re spending money on your boy and then you’re making money back, so it’s a nice healthy circle that can exist in the eBay marketplace. I like that. So when it comes to getting started, I get a lot of folks who are like, what you do is great, I convince them that there’s APIs behind everything, and they always ask, where do you start? And I always try to have people start with something that interests them, because when you’re working with APIs and understanding what this abstract thing is, it helps to be doing it with something you’re interested in. So how would you recommend someone get started in the API space in that way? Do you recommend the eBay API? I mean, 70 seconds to get started sounds like a pretty easy way to understand what’s happening.

Yeah, so I do. I am probably subjective when it comes to eBay APIs, even RESTful APIs, but yeah, I consider our developer portal and the API reference and documentation that we have good. We invested a lot of time in polishing it, I personally spent time figuring out how to design that API reference page and the API explorer and everything else that we have. And then there are other developer programs that are good, the API portals. I personally really love what Google is doing, their Shopping Content API, and some others. In general they are so consistent when it comes to documentation, when it comes to their pages and samples and how they name things. I’m not talking about their old AdWords API from 20 years ago, I’m just talking about these new APIs. I would just suggest start from some of the portals that have good documentation, so that it’s good for people to understand how other players are putting these things together nicely.

And then I think whoever wants to do APIs, they have to follow some steps. I would say the first thing is to really understand the problem statement, what you’re solving and who are you solving for. This is what I keep telling people at eBay, people from my team. Keep asking questions, question every single requirement, just try to zoom out the question with a healthy degree of skepticism, keep iterating, understand the edge cases. And then define and post your standards but be flexible on the how part, that’s very important, give some creative freedom to engineers who are working on these things. Then follow the API-first approach, find trusted developers, at least that’s how we do that. We find trusted developers and iterate with them, do workshops. I used to travel around the globe to meet with them and do sessions, and I’m hoping that I will come back to it. Then gather feedback as often as possible, as early as possible. Make sure that the business is aligned, that’s very important. And then again, this all has challenges at the beginning, but then people just have to be patient and keep going. Then, support your developers. It’s not just about releasing the API, that’s just half work done, it has to have proper support. And then measure, measure, measure the success of your APIs. Look into data, because that’s the only way how to convince business to invest more.

Yeah, just show them the value, that forward motion and generation of value, it’s dependent on that feedback loop, you have to work with your customers and your consumers and understand what they need. Do you spend a lot of time critiquing other people’s APIs? You said Google’s are pretty good. Do you spend any time looking at Twitter’s or Facebook’s or others to see what they’re doing?

I do, that’s how I learn about the APIs. I look into all of the relevant players in the industry, so I’m pretty familiar with other APIs.

So if you could provide any advice to your former self as you were coming into the API space, is there anything that you would tell yourself or share with yourself to help you along and not make some mistakes that maybe you made?

I’m not sure that there are such things that, if we knew, would change anything that we have done so far. I would probably call out one, which I would probably feel a little bit different about if I knew this. So when we released the new APIs, at least I was under the impression that everyone would jump and integrate with them, but then again people invested years and years integrating with the legacy APIs that worked very well for them, for their use cases. So that is something that I realized later. But I don’t think that that would change the way how we decided to proceed with the new APIs, it’s just that fact helped a little bit how to come up with a strategy of how to start moving developers off of the legacy APIs. Other than that, you cannot do everything in a single shot, there is time that is needed. That’s why I mentioned we focused on the APIs first and we wanted to understand more how developers are using these APIs, but then we focused on SDKs as they add some value and simplify integration with our APIs. Because we have OpenAPI, we are not building just SDKs for covering the APIs, because that’s what OpenAPI is for. And so on, that’s how we were learning. Okay, so SDKs could help, and drop-in solutions and widgets especially on the affiliate side to improve developer productivity and reduce time to market. All these things keep coming. I doubt that you can in a single shot build all of these pieces. And then we also typically release the APIs as beta, because we want to iterate, we want to learn more. Now when I look from this perspective, I think this is how it should be. And it is very important to be consistent, and consistency is across all of the aspects including vocabulary. That’s why I like REST, because it is true that this is an architectural style, but on the other side it’s not that easy to draw the boundaries around these resources, and I think that’s a challenge that we are sometimes facing internally. That design part is really challenging, and it’s really great working on such challenges, how to have that consistent vocabulary and how to define the boundaries surrounding all these resources. So that’s what’s important, and I think we somehow managed to establish that process and to agree, and it was not easy. I keep saying, and I use the number four on purpose, when you have four architects that need to agree or have a discussion, by the end of the meeting at least you will have five suggestions, because at least one of them will change their mind. So it’s very difficult to initially agree, but then once that agreement exists, and some specs and standards are defined, because the rest is a style, it’s not a protocol, so it’s just to agree on some pattern, specs and so on, then it becomes really easier. And OpenAPI and AsyncAPI really help you in that process, to agree and know what you’re talking about and express that common vocabulary. In our case, an item should be an item across all of the APIs. They don’t call it listings in some other API, things like that. These are just some of the examples. It’s just that vocabulary, but also what are these resources and how to do this to avoid confusing developers, and also to make it easier for internal development. But sometimes it’s difficult to avoid shipping org charts, I think that’s the challenge.

I like that, shipping org charts. Domain-driven design, event modeling, thinking through your design, there’s so many benefits from it. It’s not just about the technical, it’s definitely about working through all the human aspects, the work, the architects agreeing, everyone knowing what’s happening, communicating that to developers, all of that. So it’s good to see you and your team embracing it. But does everyone love API design as much as you do, or are there still challenges getting people on board?

So eBay doesn’t have a centralized API team. There is a centralized team that covers the API, but then APIs are released by these teams. There are sometimes challenges, I think this is how architects and engineers in general work, but it’s smooth, compared to how it was like six years ago, just in establishing these things. I think that’s why I say people who are running such things just have to be patient, and I guess the things will come, because you just start proving that it brings value, that your developers are okay, that things are going in a good direction, and then that helps a lot. Because we do that feedback loop and we talk with trusted developers, we take that feedback and send it to engineers, and they say, okay, we discussed this, we argued this is your proposal, developers love that, and then they feel really good. They are really proud that they get positive feedback from developers, and again we have some developers who are really larger and bring a lot of value to us, so it always feels good to hear good feedback.

Yeah, that feedback loop is more than just feeling good, it’s feeling like you have a purpose, feeling like you’re listened to, that what you’re doing matters. There’s so much more that’s part of it. So we’re coming up on an hour, this has been fun. I just have to really shine a light on the fact that eBay is such an API pioneer, been doing it for 20 years, it’s one of the handful that I point to when I say, look at what’s changing. It’s what got me into APIs, working with the eBay API early on, even those legacy ones, and then what you’ve done I think really has transformed, and just the velocity that you and your team have. I would say I don’t notice the API releases as much as I notice the stories and the things like adopting AsyncAPI and being so vocal about it and talking about what you’re doing and being so honest and open about it. So thank you for what you do and what your team does, because I think you all tell some great stories, and like I said with the analysts comment, you make a big mark on the space. So I really appreciate you coming here and talking with me about it, and I appreciate everything you do in the space. Anything you want to leave folks with, tell them about what you’re working on, anything they should be thinking about?

First it was my pleasure to talk to you today, so thank you very much for the kind words, thank you for having me today. I think folks should just be following whatever we publish in the developer portal or on eBay’s tech blog. We’re just trying to continue revamping our APIs, delivering some cool stuff.

Well, I look forward to tuning into that. You’re one of the handful of portals I have bookmarked because I like to just visit it, because when you land on it, visually it’s full of valuable information, and your presentation of it and what you all are doing, at least once a month I come back and just take a look, and I’m not even integrating or building anything. So thanks for joining us today, I appreciate it.

Thank you.