Subscribe
Share
Share
Embed
In our recent podcast episode, we spoke with Tanya Vlahovic, Head of the Developer Ecosystem & Lead API Architect at eBay. As one of the first companies to heavily utilize APIs, eBay's success story is one that fascinates many in the API community. We sat down with Tanya to learn more about the secrets to their success, advice for those who are beginning to build an API program, and how to arm yourself with the right tools to scale.
We sat down with Tanya to learn more about the secrets to their success, advice for those who are beginning to build an API program, and how to arm yourself with the right tools to scale.
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/
Building a successful API requires more than just coding.
It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.
In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.
Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.
They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.
They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.
Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.
The only other question I always forget to ask is do you have sort of hard stop? Do we need to be Super mindful on time? Okay, perfect.
No, I'm flexible.
I just added some buffer around this, so.
We generally do the same.
Alright, cool.
Yeah.
Let me make sure.
One last check.
Sure.
My junk out of the way.
Sorry I didn't clean up like I usually do.
So trying to be like, make sure nothing looks terrible.
Okay.
Alright.
Thanks again for joining API intersection.
Kind of my old weird blast from the past.
For me.
We have interesting guests.
Tanya Vlahovic.
Yes.
I had to look at notes and thank you for helping me from Ebay, a distinguished architect there.
We did cohabitate a bit, but I will say up front, I don't think we ever interacted when we're there.
So definitely lots for me to learn.
I don't have any inside tips here today.
Joining me as most often, Adam Devender.
Okay.
Adam, you want to tell us a little bit about yourself and then Tony, you can kind of give us your story.
Yeah.
Thanks, Jason.
I work at every developer where we work with API companies to engage developers.
And Ebay is like one of the very first API companies.
Okay.
So I'm excited to hear Tonya's story and lessons learned from 20 plus years of API.
So Welcome.
Thank you, Justin, for pronouncing my last name.
Very well.
Thank you, Adam.
Hello, everyone.
I'm really excited to be here with you today and talking about Ebay journey when it comes to the APIs.
I'm a distinguished architect or senior director at Ebay.
I lead a Developer ecosystem organization or Ebay Developers program.
We enable to partic around the globe to integrate with our platform with our marketplace using our APIs.
Cool.
Joined Ebay in 2,011.
Wow.
Initially, I work with the identity domain, and this is what I was responsible for, the near realtime entity resolution marketplace accounts into customer entities.
Then I joined the risk team that I was focused on the risk assessment of ebay sellers.
And then finally, in late 2,015, I joined the Developer Ecosystem organization.
And back then, Ebay API's portfolio was mostly Soap and XML RPC API.
So we decided it's time to revamp our APIs and our developers program.
Okay.
And that's how it all started.
I was there at the right time, I guess.
Alright.
Well, that probably explains why we weren't talking too much because I was working on rest stuff at PayPal at the time and it did seem at the time like there were plans for that.
But now I know that's how it came together and you were part of it.
Yeah.
That's cool.
Six.
So what does developer ecosystem mean? That's an organizational term here.
Yeah.
So the Developer Ecosystem organization is focused on the third party developer.
So we day care of Ebay public APIs and a Bay.
There is no centralized API team, but there is a centralized API governance team.
And this is what I'm running.
Okay.
Yes.
So this is just the entire API, which includes API decomposition, name, state, definition, and so on.
And we also provide a technical support, take care of the public API documentation on the developer sports or things like that.
But teams from all over Ebay contribute with the API portfolio and release Air capabalities publicly to external developers.
Okay.
So that sounds like that internal APIs get externalized as part of this.
Maybe I was stealing your questionnaire at him.
Okay, cool.
that's okay.
Exactly.
So I think I typically compare this to the Iceberg.
So whatever is above the waterline is the public API portfolio, which is powered by the massive set of the internal microservices.
Drink.
Sorry for those not watching on video.
I just did my drink any time someone says tip of the iceberg with APIs, you got to drink, right? It's such a heavily used metaphor.
Yes.
Yeah.
Anyway, I think it's a very good metaphor.
Yeah.
It it really explains very well how the things are sort of structured.
Yeah.
Yeah.
This is definitely one of my favorite topics.
And again, my responsibility was to take care of the public API.
So in general, everything that applies to the public API should apply to the internal private APIs.
Okay.
But sometimes it's challenging.
Right.
So at Ebay, we strongly believe in API governance.
Okay.
We have a large API portfolio, and that portfolio they mention is what really matters.
So APIs are powerful and used together.
So it's iterative to have a consistent API here.
I include the crosscutting concerns, vocabulary, consistency.
Got.
So standards and patterns really help in that whole governance process.
They define what is constant across the APIs.
They define the security policies.
For example, in security is a very important aspect of any successful developers program.
And then again, these are restful APIs, and Invest is not really a protocol.
It's an architecture style.
So people have to sort of agree and align on what works the best for their organizations.
It sounds simple, but it comes with challenging.
So for us agreeing on the standards and partners as well, really difficult.
So it is challenging to have architects.
Aline, and I think this is a common case and a common problem, I would say, in the industry.
And there are all these people who sort of, like, think that standards and patterns impact innovation, slow down, teams set some constraints and so on.
So we invested a lot in, sort of, like, trying to come up with that set of standards.
The.
And, you know, typical organizations with a good developers program actually create a vision for the API.
And that vision includes the technical vision.
And that's where standards and patterns really play an important role, but they are insufficient if we are missing the process.
As such, a governance process ensures that the API should fit that technical version, and the process should be transparent, as much objective as possible and manageable.
And it should be perceived as an enabler rather than a gate.
And it's all about making the right choices for the organization.
Okay.
But again, ideally, it should be a across the entire stack to whatever is above the water lines, whatever is below the water line.
But sometimes it's difficult to convince so many teams to sort of follow all of these standards and patterns.
So we sort of try to focus more on the what part, on the how part.
And then again, the quality of these internal microservices private APIs directly impact the quality of the public APIs.
And this is something that we are trying to sort of create the awareness of that fact.
But for sure, whatever goes out, that's where we are most checked.
Wow.
I hope I answered the question.
What a beautiful summary.
And I will say I always have to put together a blog post after these things and you just made the job really easy.
We're just going to transcribe that paragraph.
That's a beautiful summary of the job.
The thankless job of working in a governance function.
Yeah.
So I'm curious how big is the overall kind of engineering team versus the size of your kind of governing group? Okay.
Okay.
So when it comes to the government group again, so as I said, we have a centralized governance team, and we just decided to pull in representatives from all of the relevant teams.
Bye.
Yup.
Again, when we started this journey to rerun the program five years ago, as I said, we ran into many challenges.
So it was tough to internally align once we established all of these standards.
And Patterson, once we prove that what we're doing makes sense.
And once we started receiving a positive feeder from the developer community, it became much easier.
So now we have a really small process, I would say.
I see.
And everyone is sort of like agreeing and is aligned to sort of follow this.
So we have a centralized governor's body with architects from various product teams, and I believe that touch on is good to have representatives from all of the relevant teams.
So that body is relatively small, I would say, like less than 10 people, but teams across Eber, it is their APIs.
And we have a huge API portfolio.
See.
We have hundreds of API's that portfolio.
Again, I mean, there is no centralized API team.
I mean, product teams release, release their capabilities externally, make them available to developers.
And it takes time to onboard new teams to this process, but we figure out how to work together.
Okay.
So we literally work together.
We design these APIs together, we organize training, we go through standards, address consonants, ask the questions, incorporate their valuable feedback.
Okay.
And when such teams come back again with new APIs, it's typically smooth.
They know what the expectations are.
They understand what we are asking for.
They understand the value of having a consistent API portfolio receive feedback from the developer community.
So we keep sharing that feedback, so they feel proud when they get positive feedback from the developer community.
So I think it was very challenging five years ago, but not anymore.
But then again, we invested a lot just getting aligned internally and just convincing people that they should be following that.
Okay.
Making sure that the engineering teams are following standards is not fun at all.
But again, you know, nothing is set in stone.
So the process keeps evolving.
It's important to learn and and iterate and find what works best for for organizations.
So just, you know, with some learn and evolve.
Yeah.
I think that message, though, that like people that have gone through that discipline learn that you make them look cool.
And I think for those may be subject to these governing functions who are listening.
I think that's always been to take away from me having served in that role in a few companies, that if that's well understood up front.
Like if you go this alone and you don't really kind of Grock what the rules are it's going to be clunky and rough and you're going to get rocks thrown at, you know, the risks of not doing this stuff are too great.
cool.
And if you listen to the help that's being offered, rather than looking at it as kind of gates to pass through, you're going to look cool.
Yeah, that is true.
And so what we also sort of emphasize is that team should be innovating.
Right.
So we strongly believe that delivering a successful API is only possible when the teams are in power to innovate.
And in my organization, for example, the nurture able in this culture, when I say blames culture is beyond just DevOps.
So we encourage our team members to innovate on behalf of our customers.
So flexibility enjoy our key to people feeling safe, to take risks and to try something new.
for example.
And there are so many examples that engineers came up with some ideas, and we ended up releasing SDKs with all sorts of things just to help developers further.
And that's basically what you also do.
And it's very important, actually, to to connect and to communicate with the developers.
We pay attention to that a lot.
And we emphasize on that whenever we work continuing APIs, we've partnered with usted developers that works very well for us, but I'm not sure whether this is applicable to every single company.
Sometimes I keep getting questions how you can figure out who are your trusted developers and so on.
Okay.
In our case, we know we have developers who have been with us for 20 years.
Yeah.
Right.
This is a very mature developers program.
So that is basically what we sort of do work with our trusted developers.
We work together on the APIs.
We also believe that developers shape strategies and road maps, and we release our API is data.
Okay.
First, we go with that feedback group.
Apis are for developers, so they should meet developers needs.
And of course, whenever we receive such feedback, to share with the engineering teams with the API owners, and people want to do what's the right thing to do.
So I don't want to solve the customers problem, and it's either our customers are buyers, sellers, but also developers.
Bye.
Yeah, for sure.
And I'm up do it.
So I want to pin you down, though, on the team size thing.
So you said there's about 10 people that are doing this kind of sounds like sort of a Council sort of format, but you work full time on this.
No.
Again, so people just volunteer their time and participate.
Ebay is a company.
Right.
So we have many of such forms, internal forums, and architects from various domains participate in all sorts of design discussions, reviews and things like that.
sure.
Bye.
Bye.
So this is yet another forum that is focused on the public APIs when it comes to the size of the teams who contribute to the API portfolio.
I don't know.
So as I said, the base is a big company.
There are so many domains.
Almost every single one has public APIs.
Sure.
Yeah.
It depends.
Right.
I mean, how much the engineering for these teams put depends on the initiatives at and so on.
So we really strive to make sure that our API support all of the business initiatives to Bay because, you know, the program is really strategic to us.
So our developers really, really bring value to buyers and sellers.
To us, the success is our mutual interest.
So it really, really work closely with the developers because they expand our business into new context.
They create fantastic experiences for that.
Use this in the end, that our buyers and sellers.
And then team wise, though, I would guess that the ecosystem team is more than just you.
That what you were talking about with the group of 10 or so is governance.
Yes.
Right.
Yes.
So I think I mentioned it, but let me elaborate more.
So we provide developer technical support to our developers.
We also alter the API documentation.
I have architect in my organization who again, participate in all of these forums and my organizational the By APIs.
And I think we talked a lot publicly about these By APIs.
They generated a lot of value to less than four years since we launched them and started on boarding partners.
We generated more than 5,000,000,000 dollars gross merchandise bought or GMV.
So that was really a big success.
So, Yes, that's that's what we are focused on.
But then again, you know, our APIs have to follow and be aligned with the Ebay initiatives.
And we have business initiatives all the time.
Yeah.
So we're pretty pretty busy.
No, it's notable to me.
So this is our episode, I think.
And a couple of things that you said in there, I think, have been true with everyone in these kind of governing functions.
One is partner with.
Don't be kind of bizarre of things.
I think small, centralized governance that evolves into being decentralized.
And we prioritize those efforts around governance to be in line with kind of the business deliverables rather than some independent focus.
So you kind of mentioned in there like, I'm not sure if everybody else does it this way.
Everybody that we've talked to and that's been focused on successful programs.
This has been true.
So I think those are certainly the norm, I guess, the norm of success anyways.
I hope so.
Yeah.
I hope so.
So that's those two elements of success, I would say Yes.
Yeah.
We actually collaborate with, you know, people who are involved in the governance processes in different organizations.
So we sort of like different companies.
So we are trying to sort of follow the practices.
Yeah.
I think that's part of what the show is about is learning.
How does all this work inside all these companies that have successful API programs and are their consistency and patterns? So sometimes I have to enumerate them as we start seeing them emerge.
And maybe we could look kind of at an example of someone there's a new API that coming to Ebay.
Yeah.
So they reach out to us as as soon as they know that they have to expose some capabilities internally.
So if you are building something for the very first time, even internally, then we collaborate on the internal APIs as well.
So they reach out at the early stage, and I think that's that's the best.
And we just make sure that before jumping into the design, they understand very well the problem statement and what they're trying to solve.
I keep asking my teams to, you know, work on the requirements with a healthy degree of skepticism.
It's okay to ask questions.
It's okay to challenge requirements.
It's okay to Zoom out and to try to see the bigger picture because in case of the API, so once you release them, they will stay for a long time.
Any breaking changes impact negatively business typically, right, at least in case of ebay, that's always the case.
So it's very important to sort of Zoom out and have to pick a picture to see the bigger picture, and to understand how that contract will keep evolving and growing with the business, because business will change for sure.
And then a Bay, we have a design process that we called interface design method or ID.
And I I think that process also works very well.
So this is to create some sort of like a blueprint for the API.
The starting point is to define the use cases, which means actors and all sorts of actions that they can take also to define constraints.
So the next step is to derive entities and entity relationships from these use cases.
And then typically, no, we are talking about trustful API.
So it's all about announcing works.
So the nouns are then identified from the entities and verbs from the actions.
And finally, we define a resource representation.
So when we convince teams to follow that it becomes really easy and simple to sort of lay it out, then what we, as the governance team ensure is that the naming convention is going to be consistent, that an item is always an item and item and item, regardless of us, the API, and so on.
And of course, all of these things that are that are part of the rest protocol is just make sure to use the right Http status codes and how to proceed with errors or warnings and things like that.
So we again spend so many years learning.
So we sort of try to make it as much straightforward as possible.
Bye.
So that's something that we answer to have as part of this whole governance process.
That has to be that blueprint.
And in addition to what the upcoming release is, we try to convince people teams to sort of think in which direction their API will evolve, because most likely it will.
So we try to put all sorts of placeholders for eventual extensions because we keep seeing that.
So just the more they can think I had, the better.
And that's what we are trying to emphasize.
Yeah.
So when you mentioned this Blueprint, I noticed that you represent Ebay with the Linux Foundation and the Open API project.
That is what comes at the end.
So we start from the use cases first, which is not really.
I mean, as I said, the use cases first and the entities that entity relationship diagram, and then you derive nouns and words and so on and work on the detail of resource representation.
And that is where the Open API pack.
Yes.
And Yes, I actually you love that.
You ask that question.
So we are a member of the business.
Gallons boarded the Open API initiative of the Lines Foundation.
So we are not that particular away when it comes to tools.
So again, the governance process is important.
It doesn't matter what is the underlying stack for that particular API.
The API must be consistent and must fit well into this portfolio.
So we are not that particular when it comes to tools as long as the standards are followed.
Again, the focus is on the word part and not of the how part and the outcome is really what matters.
But we do encourage and it's not really encouraged.
We insist on leveraging the Open API tax.
Hold on.
So for all of our reps, we have the documents based on the Open API spec published, and I think we were the first in industry to publish the documents, the Open API documents based on the three dots back.
And so it's easier to understand the API.
It's also easier to integrate with our API.
And starting with the Open API documents, there are so many tools that we are all aware of, like flagging on the generated clients in and Simplify integration with the APIs.
And we are sort of like promoting that a lot.
And we recently adopted the Async API spec as well.
So that stack and that initiative aims to standardize the Asynchronous APIs are described.
We use it for our Async APIs.
We use it for our event notifications.
And it's again, a human readable and machine readable spec similar to the Open API.
It's compatible with the Open API.
It supports very well both publishers and subscribers side.
And there are some cool visualizers for engineers to understand the contract.
So we really encourage API providers to adopt both Open API and also the Async API back end to join the community and support these initiatives.
Yeah.
I clearly near and dear topic.
Right.
I was part of the kind of founding group with Linux Foundation to get that off the ground.
Don't do that these days.
I don't know, maybe again at some point.
But stop it.
Obviously, we're built pretty heavily on top of it, too, so I couldn't agree more.
There was a lot of interesting bits in your process stuff.
And the thing that a listener who isn't doing all of this might think is that sounds like a lot of time for you as a reviewer or anyone else involved in doing this review and collaboration, that it's a lot of time of manually looking through all this stuff.
So the try it in the past, but it's not there yet.
So we try to do some automation.
But then again, it's difficult to automate review of the underlying model.
So you can automate something, right? You can automate naming convention, you can automate the error handling to some extent, or verifying that the right http, status calls are documented in the contract and so on.
But to really make sure that the model is okay.
And I think that's the most difficult thing.
So typically, team start like, okay, I have a response.
I will put whatever I want in that request at whatever I want I need.
We'll be part of that response.
But that's not the right modeling, and that's what they love about rest, because it's all about these resources.
It's just how they're going to structure them.
And just to make sure that there are boundaries not to keep, like, doing the similar things across the API's and so on.
So it's not that easy to sort of like automated.
I think there are companies that are trying to do that.
I think Apigee is trying something, but again, it's it's not there yet, I would say so we spend time, but it's more like to understand the problem statement and that the modeling is proper and everything else is sort of relatively easy.
Yeah.
I feel like I commonly have to remind people that when we say API design, that it's a design job, and the process of designing things requires empathy and rationalization and all the same things we see in other design disciplines.
This is just an emergent one that's different.
So are you doing some level of automation on some of those more deterministic things, like conventions or at this point.
So we tried something with it, made some progress in the past, but we just put it on hold.
So it's pretty much, I would say, like manual.
But again, we are not that busy.
We're not releasing APIs literally every day.
Yeah.
Wow.
So it's not like, Wow, this is like huge.
Again, we have a huge portfolio.
We have hundreds of API's, but it's not like that.
We just keep releasing them every day.
So it's okay.
Yeah.
And that design takes time, and sometimes it is challenging to find that balance between the agile methodology and the need to do a proper design.
And I think that's what people are struggling.
It's okay to keep iterating when it comes to the public APIs, as long as the changes are backward compatible when they are not.
Yeah.
That's a problem, because no one is happy to run two versions in file.
And then again, to move consumers from the old version to the new one.
It again depends on the on the developers program, on how it is structured and who the partners are, and what is the impact of the rating things on the business.
So in our case, it's a little bit tricky because there are developers who lasted years integrating without APIs and moving them to the different APIs or so.
Bye bye.
It's not always that easy because it's it's not something that we can we can drive.
We can help with all sorts of SDKs and Widgets and drop in solutions and all sorts of things.
But then again, they need to invest.
You work on their side.
So that's why we really have to be very cautious.
And that's where we spend time.
It is probably the in some cases, more work on our side.
But as long as it is less work on these thousands of developers.
But still, you know, letters.
Yeah.
Okay.
We just, you know, compare the contract.
Right.
So that's how we figure out whether we know what the backwork incompatible changes side.
If you drop a method, if you just stop supporting some fields and so on, that's a backward incompatible change.
So, Yeah, just compare the two contracts and figure out where is the difference.
Got it.
Yeah.
I wonder.
Then I wonder about you mentioned when you first joined the API team that you had a huge process of of bringing older APIs into more modern technologies.
I know there are a lot of listeners who are going through something similar right now.
What was your approach there? How do you choose which APIs to do first? And I guess you can't have backwards compatibility when you're changing an entire interface, but you do want to have sort of feature parity.
Right.
so we just started based on the APIs that are heavily used that bring more value to us.
So what we actually do very well at Ebay.
So we have something which we call kid or no, your developer.
I came up with the train a couple of years ago.
So that's the process when we try to understand exactly how our developers leverage our APIs, how they integrate without APIs.
for.
So we actually created a huge data set of developers and that integration without API.
So we can understand very well and literally calculate the value of every single developer applications.
And all of our APIs calculate the value and the value that they bring to Ebay that they bring to us.
Right.
And that is something that really helps.
So in our case, I talked about feedback, right.
And how important that feedback lupus and the direct that is indirect feedback.
So direct feedback is when we collaborate with our third party developers, and then they share their feedback with us, especially when they are launching new capabilities, when they are piloting something with them on the other side, at indirect feedback is equally important.
Okay.
We keep looking into our data, and that is one of the main drivers to tell us in which way to go.
And what are the APIs that are the most important for what we need to figure out a fix to provide new capabilities and so on.
So this is where we can identify workarounds and all sorts of things.
So every workaround tells a lot.
It tells that most likely there is something missing in the portfolio.
Okay.
So that is basically what helps us.
So we keep looking into data, and we have a massive data set of is and how they use our API.
There are operational metrics that are business metrics.
So operational metrics are.
Okay, right.
They tell us whether our platform is stable, the scale we operate, and and all sorts of things.
But then the business metrics are really important because that's what can help us figure out how to grow our revenue.
It sounds like a topic.
We hear a lot about thinking about your APIs as products, and it sounds like there's some of that going on.
Yes.
Absolutely.
Absolutely.
So we actually consider our APIs to be products, and they are actually first class product for us by again, our customers are by ourselves and developers.
So we have a really large and powerful ecosystem of third party applications that add value to us and to our bias and sellers.
So we truly believe in that be to our business to developer model.
And we see our API as building blocks that developers just put together in a unique way.
And there are all sorts of different integrations.
Developers use our APIs to managers, sellers, businesses, scale to provide logistic services, provide bookkeeping services.
I mean, marketing, you name it.
So every single concept of a marketplace is supported on the third party side as well.
And imagine having thousands of developers working with your APIs and bringing value to Ebay.
Okay.
So I think that's awesome.
And through our developers on the buy side who surface our inventory into their experiences, drive traffic to or enable check out in their own experiences and their shoppers to purchase our items.
So we just allow the parties to sort of take all of these building blocks and combine them in a unique way and create great experiences.
Allow.
And we designed these APIs leads and maintain them, such as that they provide their customers.
Developers a good experience.
And nowadays it's all about connecting users and data, and that's how many companies generate revenue.
Yup.
And I think the global pandemic identify that even more.
So that's the way we work, the way we learn shop, entertain the way we do almost everything nowadays.
Right.
So it's just about finding ways to interact with customers more frequently, more efficiently, more safely.
Right.
Because of the global pandemic and behind all this is are the API's, right.
We are just trying to get the most out of it, like probably so many other countries.
for sure.
It seems like everybody these days is getting their platform thinking cap on.
Okay.
Yes.
I mean, it again fortunate that you started that back in 2,000, but then I mean, everything can be improved, and that's what we keep you doing.
Yeah.
Yeah.
I'm already said you guys are API OG.
So.
I'm curious if I'm asking for privileged information or you don't know that's fine.
You can tell me.
So I'm actually not going to talk about the proportion, but let me just give you a couple of attacks.
I just mentioned it.
The Buy APS generated more than 5,000,000,000 dollars in GMB in less than four years since 2,017 when they started to onboard our first partner till end of last year.
And then I can also say that in Q one, this year third part is created 1,000,000,000 listings via the API's.
Wow.
1,000,000,000.
1,000,000,000 listings, Pinky and mouth.
So we have 1,000,000,000 1,000,000,000 listings.
Yes.
Exactly.
Yeah, that's true.
I'm an unrepentant ebay junkie, so I can attest to that.
and then they actually revised or modified 1 5,000,000,000 listings in Q one.
Wow.
So I think that's just to illustrate the scale.
Yeah.
Pretty business critical.
Yeah.
And those are listings through apps that developers outside of Ebay have built.
Right.
Yes.
So that doesn't include any internal API calls.
Yes.
That's an amazing scale, for sure.
Yeah.
it is.
Yeah.
As I said, we are busy and pretty busy team.
I mean, obviously, I think we're touching on the edges of the other side of platform as I think about it.
The former that we've been talking about being this kind of component, izing your architecture and how to connect to other things.
But the other side is marketplaces and kind of how marketplaces grow and kind of how we structure those things.
I'm curious.
You mentioned that, like aligning your API strategy on business terms.
I would imagine that kind of marketplace dynamics and how you think about incentivizing suppliers and buyers must be connected to that.
So we collaborate closely.
Right.
So we just let me give you an example.
So we enabled video on email listings recently.
So that is an example of an ebay initiative.
So we just followed the API first approach here, and I just did everything that we should do when it comes to the APIs.
First, we again partner with the trusted developers and so on.
And as of now, the only way to upload EPS to be platform is we had the APIs.
So that's an example then.
You know, there was a lot of success with authenticity guaranteed with sneakers on ebay and luxury watches and things like that.
and watches? Yeah, I love that.
So that's again.
Yeah.
That's again supported via the API.
So that's basically what I meant when I said that.
We are trying actually to make sure that whatever critical new business initiatives we have that the APIs will support that then ebays managing payments.
Right.
So there was a lot of work to make sure that our APIs will enable third parties to do that.
Bye.
I think I just mentioned 1,000,000,000 listings created and queue on this year we had the APIs, which means that they have to have all of the tools that are needed to manage their sellers business at scale in the right way.
Hello.
Yup.
So those are examples.
Right.
So then there's popular certified refurbished program, a TB, which is against fully supported in the API.
Yeah.
So that's that's what we are trying to do.
Now that you mentioned, it has been a lot of change in ebay experience over the last year, both for buyers and sellers.
I know, like in my various hobbies with the mess you can see behind me if you're on video, there's a lot of ebay interaction there, and I guess you've had the shift to seller payments not on PayPal anymore and direct.
So that must have been a huge shift.
Yeah.
That was go ahead.
My curiosity is this seeming acceleration and kind of change.
I'm curious how much of that is sort of attributable to this more API focus strategy.
I'm actually not quite sure that I know that answer to that question, but for sure, because of the value that the third part is bring to us, it's enough to support all of this via the API.
So managing payments.
That was a big shift.
Right.
So we had to deliver a huge settle stuff, finances and payments related APIs to enable our developers to to continue doing what they used to do with, you know, and integrating with PayPal API and so on.
Yeah, I don't know.
I like to ask some of these questions because I think for some people who are trying to get these things off the ground, the struggle is can I explain the business value of what we're doing? And I think your description is really interesting is that the opportunities that this connectivity and this consistency offers gives you flexibility to make bigger business baths.
But the work of doing that API stuff, actually, you don't necessarily need to know all the business initiatives you're just kind of partnering with.
I think I mentioned that we have matches.
It a set of and that we calculate the value the third parties bring to us, and that is what we use to decide how to handle our API.
get on, I suppose.
Yeah.
So I suppose the supplier focus would be the thing there.
Yeah.
I mean, it's interesting coming from kind of Expedia group and my experience there, it's very similar in that.
You know, the API volume tends to come from the supply side of a market place.
So I suppose it kind of seems like a somewhat consistent thing in marketplace stuff.
And I know, looking at that industry as a whole around kind of travel, that was generally true in almost every segment.
So, Yeah, I guess if you're working in a marketplace, look at supply side for value message, maybe that's true.
Cool.
Alright.
So it's like a lot of stuff.
And I have to go back to my one consistent question, I think on almost every episode now.
And it's always the most fun and sorry if you square, but.
So take off your Ebay cap for a moment and put yourself in the seat of someone just getting started.
Okay.
They've got a random array of API things happening and they want to gain this consistency and this focus and improvement and experience and build their B to D skills and all this stuff.
if I am on the API provider side or the API consumer side, I'm not sure that got the question on the plan.
Provider.
So basically you're building your API program from scratch and perhaps in a not billion transaction kind of environment, maybe something smaller trying to scale up.
Okay.
Okay.
Partner with the architect from your organization, from various teams.
Again, it depends on how structure the organization is.
Partner with business as well to understand the vision for the program, because again, there is a technical vision that is a business vision.
Right.
And then I guess I would again focus on the technical vision.
So try to explain what the benefits are of having a consistent portfolio and then just be patient.
Spend months trying to get aligned and come up with some concepts and standards and practices.
Again, keep iterating, keep changing, keep listening to the field back, keep evolving, but try to sort of have a team of people who will support it.
Again, it's painful at the beginning.
It's difficult.
I keep saying if you have four architects in the room by the end of the discussion, there will be at least five suggestions because at least one will change their mind before the meeting.
Bye.
And that happens.
We all went through this.
Probably not.
Every single aspect is something that I don't know.
Everyone agrees with, but at least if there is a consensus, if people in general agree and agree to, to disagree, but still to follow.
I mean, that's how it should work.
So it's just a matter of time.
It's okay to listen to feedback.
It's okay to partner again with developers who can help to shape this all and just, you know, be patient, look into what's going on.
And just to try to follow the standards in the system that it's like, I don't know that open API an API, and so on.
Give developers tools, give developers, you know, be transparent.
Right.
So we didn't talk about the developer experience, but that's something which is Super important.
So I don't know how people should know that when they want actually build a program right from the scratch.
So I typically say that there are five pillars of the developer experience, and I don't know if that's that everyone in the industry sees this is five or so, but I would just go over my list.
So the first thing about the building blocks, right.
And this is where this includes API's feeds, event notifications, SDKs, dropping solutions for Widgets.
So basically all sorts of tools that you give to developers, the API Explorer, and so on.
So again, I talked about the APIs.
They have to be intuitive and easy to understand and consume.
They are for human developers.
And that customer satisfaction is one of the really important metrics to measure the success of the API program and then also focus on the SDKs.
We do that at Bay.
And they are not just simple wrappers around the APIs.
They help to integrate into streamline integration.
And in our case, we open source them.
And we do that for various reasons, to give transparency to our developers into what's going on with our APIs and our platform and also developing contribution from them.
And then the documentation is the second pillar.
So that documentation.
Again, I am really a huge fan of the Open API and things like that.
And I think that the API contract should be intuitive and easy to understand.
So developers are not supposed to study the documentation in to understand how to integrate with the APIs, but documentation is important to tell a story.
So that's how I'm seeing that.
Then the third pillar support.
So it has to be the developer technical support.
It is good to have forums, and I think this is obvious.
I mean, need so I don't need to talk more about that.
And that that communication and connection.
Right.
So before the pandemic, we used to traverse the globe to meet with all of the strategic developers whenever we're launching new integrations that are important to us.
So it's good to spend a couple of days in workshops and sessions, boarding and things like that.
So it's important to communicate program vision, program updates, metrics to some extent, whatever can communicated externally.
And that helps to improve the quality of the developer ecosystem and the portfolio of the third party applications.
And and that communication needs to be both in both directions.
So that feedback loop is Super important.
That direct feedback.
And I would say then the fifth pillar is growth.
Right.
Because once you release your APIs are not done.
bye bye.
Right.
So that's why I keep calling out that care ID process that you have understand who are your top developers, who are not figure out who you can help and work with to sort of enable them to grow their business, because, I mean, their success is your success.
In our case, they contribute a lot to Ebay.
So it's very important for us to help them to be successful.
Okay.
Nice.
That's basically how I would what I would actually consider you high to sort of like grants from the scratch somewhere else.
Well, you definitely have high standards as the starting point.
Yeah.
That's just the experience.
Yeah.
I feel you.
Right.
Again, I said I would be patient.
Right.
So patience is important, but there has to be a vision and go.
Right.
So you cannot get this all from the day one.
I mean, again, we put so much effort into our program and we are not done yet.
Yeah.
So we keep improving every year and so on.
And I'm sure the answer to this is within those five pillars.
Okay.
I mean, you know, they have to have some sort of cave to sort of to measure the value that the API brings and the developer brings and then just figure out who should go to talk to, right.
I mean, it really depends on the use case and on the type of business the organization is doing, and so on.
well, it sounds like you're saying that sort of, you know, pre pandemic era, obviously like setting up an event where you actually invite folks to come and really interact with them in person.
You know, like I would say pizza and beer go a long way in learning things in product.
Exactly.
Yeah.
So talk to who shows up.
Just.
So I mean, you know, in our case again, this is a mature program, but we meet with top developers once a month.
there we go.
I meet with them once a month.
I think the for me, that's a product management staple that I think ports well into this kind of environment is I have your close group of kind of.
What I call an early access group is like, share those early thoughts.
Show where you're going with things be a little more open and transparent than with just the average folks and figure out what their needs are and listen a lot.
Yeah.
Exactly.
So, you know, assuming that API is a first class product for the organization, if they are, then you have to treat them as first class products and to talk to your customers.
Well, pro tip, anybody that sits and listens through 45 minutes of this wants to accomplish that.
Okay.
That's why they're listening.
So we have our heart for it.
Cool.
The ebay developer community is really great community.
So it has been such an awesome partnership over the years, and I'm hoping that we are going to continue this.
So this summer, we are again running our virtual conference last year.
It was virtual before that.
Yeah.
It was always in person.
We used to have such events around the globe.
It's a little bit different, but we still managed to connect with them.
Yeah.
So I hope I'm going to see them virtually meet with them on July 12 th when they are running our second webinar this summer.
And so when it comes to my message in general, beyond the developer community, I strongly believe that API's, how to, you know, generate revenue.
It's about connecting users and data.
So it's it's just the continuous amplification, which is great.
There we go.
Nice.
Key word of the day.
April vacation.
Perfection continues.
Nice.
Well, Tony, it's really a pleasure getting to know you a little bit and understand the Ebay story.
I think the Ebay developer community is in pretty good hands with you here, I think.
Be interesting to see how things unfold.
So thanks again.
okay.
And Adam, thanks again for co hosting.
Also often.
Absolutely.
Great to hear the stories.
Thank you both.
It was great driving video today.
Alright.
So that stop our recording.