January 5, 2023 • 22 mins
This week on the API Intersection podcast, we spoke with Eric Yu, a co-founder of Rutter API, a universal API aggregator for various types of business software tasked with standardizing all APIs into a unified format. They focus on two primary buckets: Ecommerce ecosystems apps, and fintech customers. Rutter lets customers connect their accounting, commerce, payment, and subscription platforms in a single flow.
A universal API aggregator is a great solution to scale quickly, and we covered the benefits of utilizing one in our previous podcast episode. Increased security options, ease of integration, and the ability to scale quickly are just a few of the benefits of utilizing an aggregator. However, on the side of the aggregator, there are still quite a few challenges that aggregators face in today's API industry.
_____
To subscribe to the podcast, visit https://stoplight.io/podcast
--- API Intersection Podcast listeners are invited to sign up for Stoplight and save up to $650! Use code INTERSECTION10 to get 10% off a new subscription to Stoplight Platform Starter or Pro.
Offer good for annual or monthly payment option for first-time subscribers. 10% off an annual plan ($650 savings for Pro and $94.80 for Starter) or 10% off your first month ($9.99 for Starter and $39 for Pro).
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
API IntersectionPodcast listeners are invited to sign up
for Stoplight and save up to $650.
Use the code INTERSECTION10 to get 10% offa new subscription to Stoplight Platform
Starter or Pro.
Take a look at this episode's descriptionfor more details.
I'm Jason Harmonand this is API Intersection
(00:20):
where you'll get insights from experiencedAPI practitioners to learn best
practices on thingslike API design, governance,
identity, versioning and more.
(00:41):
Welcome back to API Intersection.
So we've had a couple of guests onbefore we kind of talk about, you know,
“consuming APIs from lots of differentthings is hard
and how can we make that easier,”
which I thinkwe can all sympathize with or, you know,
have some experienceof trying to integrate too many things
(01:01):
and having it all fall apart.
So I'm looking forward to sharing some ofthe learning from Eric Yu from Rutter.
Eric, tell us a little bit about yourselfand what you guys do ar Rutter.
Yeah, I'm Eric.
I'm one of the co-founders of Rutter.
We've been around for,I think two years at this point.
Basically,we are a universal API API aggregator
(01:24):
for a lot of different kinds of businesssoftware,
e-commerce platforms like Shopify,Amazon accounting systems like
Xero and QuickBooks,and then some payment systems
like Stripe and PayPal and charge fee.
And so we standardize all of those APIsinto kind of a unified format
so that people don't have to readany different kind of documentation.
(01:48):
And then we just make that one API to workwith.
Got it.
I mean, what do typical kind of customerslook like for you guys
as far as who's looking to integratewith all the different things?
Yeah, I would say for usit falls into two main buckets.
(02:09):
One is basically more focus on ecommerce.
So a lot of ecommerceecosystem apps like marketing tools
and new ways to like marketplaces, waysand places to sell stuff
and they use our ecommerce APIs to like
get products,create orders, all of those things.
(02:29):
And then the other big segmentof customers is on the fintech side
where they want to get access to a lotof this business data in e-commerce
platforms and accounting platformsto basically get like a better view
of the company in the financial health,the company to use an underwriting
or like lending or credit cards,all kinds of different use cases there.
(02:51):
Got it.
I always like to kind of learn from folksthat,
you know, kind ofhave the the moxie to go found something
like what got you to this point?
What got you thinking abouttrying to solve these problems? And
I don't know, maybe this might soundjerky, but like, you know,
why should our community of listenerstake your idea seriously?
(03:12):
Yeah. Yeah, definitely.
Yeah.
I mean,
we we've been through many ideas thatdefinitely should not be taken seriously.
So we, we started out
basically NYC doing somethingcompletely different.
It was a dev toolfor translation, actually,
like a kind of internationalization tool.
We then basically built that.
(03:35):
Realized some things weren't workingand so pivoting for a long time,
kind of one into the desert for liketwo years trying to figure things out.
And I think eventually for us, becausemy co-founder and I are both engineers,
we had been kind of buildingthese different apps
that required integrationand the other tools
and realized at some point that we weredoing the same thing over and over again.
(03:56):
We had seen what was happeningin the space with new universal APIs
like payroll ones,and of course applied this for banking
and felt that we could just try to doone for e-commerce platforms.
And that's kind of where we started.
And so we did that.
We weren't entirely surewho would use it at the beginning,
but we then kind of reached out to many,many different kind of developers
(04:16):
on the Shopify
App Store to see who was interestedin getting their app on other platforms
and found some of these customer segmentsthat I mentioned
and then went from there.
Got it.
Yeah, it's it's interesting,you know, this notion of like aggregation
platforms around API to sort of address,you know, the diversity of consistency
(04:40):
that user experienceseems like there's kind of this
pick, you know, pick a segmentand be good at it.
But the idea that you can be good at allthe things is too broad and that there's
been, you know, not a lot of big successstories that came out of that.
And I love that you mentioned Plaid.
I feel like that's that's the thingthat's kind of inspired everyone
to try to go solve this in particularsort of verticals.
(05:03):
It's interesting.
So, you know,I already started hinting at,
I guess, the things I've heard before,But I'm curious from your perspective,
like, you know,
what's hard about trying to integrate
with multiple providersin terms of consuming those APIs?
And you know, the engineeringchallenges it presents?
(05:27):
Yeah, I thinkthere's definitely a lot of challenges
when it comes integratingwith different APIs, but I would say
probably the two biggest ones for meare one dealing with.
Generally speaking, there's definitelysome APIs out there that are more tech
forward and companies that are more techforward, like Shopify is great API.
(05:47):
So those are pretty straightforward to do.
But then when you have to make them workwith APIs that are like more nightmarish,
like Amazon's API that uses like reportsto get data or, you know, or
async requests that take minutes to finishinstead of like a few seconds to finish.
That's when you run to challengesstandard or standardizing the APIs.
(06:08):
So that's, you know, a huge problem.
And then secondly,when you deal with these APIs
and fetch data like we areand kind of like sanitizing it,
you have to deal with many different kindsof rate limits
and building a system that can handlea lot of these different errors,
permission errors, rate limit errors,
you know, trending errors in these APIs.
(06:30):
That's it takes a it takes a lotto basically maintain that system.
Yeah, that's that's the bit where
I think you know we talked
to a lot on the showhere to folks that like build APIs, right.
Running some sort of program
and you know, we talk a ton about,you know, what's important
(06:51):
and it's like,you know, design and language and,
you know, some of these scaling factorsand all that.
But it's like, what are the errors?
Like, you know, how many times does thatcome up very often?
And it shouldprobably should be a lot more.
So it's interesting, though, that on onehand, you're having to sort of consolidate
what is sort of a model to representthis concept across multiple things.
(07:15):
And then on the other side ishow do you present
the flow of errorsin sort of a consistent fashion?
Seems like
two pretty different problemspaces, though.
Yeah, definitely.
I think we've spent a lot of time on onboth ones.
And I think for the first onewith the consolidation
and centralization of information,that's really just a lot of iteration.
(07:38):
Like you can try it.
You basically just start with the,
the most simple these APIand kind of go from there.
And then when you talk to different usersand they want more field
or they want to change certain things,that's kind of how you learn
eventually,kind of what the ideal output looks like.
So it just kind of a processof learning for us, I think.
On the error side.
Yeah, we spent a lot of timeworking with various errors.
(07:59):
I think some APIs, they tell us errors
where some of the messageshave been in different languages.
So like a, you know, a
Dutch error message saying that you can'taccess the store's permission.
We tried to kind of learn over timehow to handle all of those.
Yeah, the error message that tells youyou've selected the wrong language.
(08:20):
Yeah, exactly.
So, you know, it's an intriguing spotto be in that
you go, okay, I've looked at allthese different sort of data models
that these different APIs provide and,you know,
it's it's like the meta design problem ofhow do you come up with something good?
(08:41):
It's like, you know, your worst problemin that scenario
is that you end up producing somethingthat is the sum of all of its parts.
That's worse than any one of them.
So from a kind of API design perspective,how do you guys think about that?
Yeah, definitely.
I think for us, you know, I think I thinka big, big part of this is just learning.
(09:02):
And so we start with kind ofwhat is the gold standard.
So in for example, e-commerceAPIs, Google Center is Shopify,
and we canwe use that as kind of a skeleton.
And then we basically go out, we try tonot include too many fields because
it's kind of overwhelming for peopleto like, learn what all the fields mean.
But over time,we do add some based off of user feedback.
(09:24):
So we try to basically make it moreand more useful.
But as you mentioned, like you also justcan't dump everything in there.
And so the way that we've kind of
got aroundthis is we allow our users of the API
to also get direct access to some of theseunderlying APIs that we're connected to.
We give them the tokens
(09:46):
and so that allows themin certain situations
where they need to make direct calls orget something unique or specific to them,
make a direct call to the shopvia Amazon API
and do what they do, what they need to do.
So we try to make as much standardizationas possible, but then for some off
cases, you know, we allow the flexibilityof like using the API directly.
(10:08):
Yeah. Now I think it's like
when folks think about these thingsthat always like take the least common
denominator approach the leastthe least number of common things.
Don't try to do the mash them all togetherto get all the things,
because that's never going to work out.
(10:29):
So, I mean, you mentioned like ratelimiting and some of these things.
I also think about like,
you know, one of the consumption problemsfolks run into a lot
is sort of almost hardwiringtheir infrastructure to some external API.
And then when it goes down, everythingjust, you know, totally falls apart.
And so this kind of availability factorlike sort of the,
(10:52):
you know, buffer for that, likeare you guys providing anything like that?
And then I guesswhat would your sort of recommendations
on the right waysto approach those things be?
Yeah, I think
for us, we what we do is we actually takein all the data from these different APIs
and then and store itand then centralize it on our end.
So we're making that available directlyto our database, to our users.
(11:15):
So the good thing is that if an API goesdown, let's say like Shopify
or one of these other platforms,people can still fetch data from us.
We just won't be able to kind of updatethat while the other APIs down
and also post requests
won't work because we can't we can't makethose requests to external API.
So I think that's actually a tacticthat a lot of consumers of APIs use.
(11:39):
We've talked to peoplewho've told integrations with QuickBooks
and Shopify these different platforms,and it is something similar
where they store the data
to avoid downtime,but also to of what's on the rate
limits of kind of refashionthe data over and over again.
So that's a big thing that we do.
So here's aI don't know what to call a hot take,
(12:01):
but probably a contentious questionas someone in your position.
But like, you know,
I've been in software a long timeyou know, since nineties dot com bubble.
Right.
And seenthese kind of trends come and go of like
an industry standardizing on one thing.
And I look in modern era to likeand say health care
you got like the fire API spec right.
(12:22):
I mean do you see thatlike some more of these kind of verticals
might start moving toward
standardizing on things and,
and is that like what we should be doing
and or do you think folks like yourselfare leading the way toward that.
Yeah, it's yeah,I mean that's super interesting question.
(12:42):
I think from from what I've seen there.
But like whereas in other fieldsI've also noticed I think in messaging
and communication there's been kind ofthese more standard protocols.
An API is to use Messenger.
I message all of those things.
I haven't we haven't seen the same thing
develop yet in the ecommerce worldor the accounting world.
(13:04):
So I don't think there's like a a bodythat's kind of leading that effort.
And I think like from what we see,
it's it's definitely more similarto the banking world.
It's been more fragmentedand and that's kind of the body steps in.
There won't be much innovation.
And I think in the e-commerceand accounting world,
there's no like government that's wantingto coming in and help out there.
(13:27):
So for now,I think like for us, we're kind
of trying to do the workto make people's lives easier.
But if there is kind of athat kind of steps in to deliver
some additional value or standardization,I think we'd make use of that.
And then just kind oflook for other places
where there's there's not thatand try to be a universal API.
(13:48):
Yeah.
I mean, I think you're rightin this particular kind of vertical.
I mean, I will say thatlike sure, governments
can step in and regulate things
and that is certainly a source of whypeople would do these things.
Sort of portability.
Interoperability in some areascan be like a driver
that's more organic or that,
you know, companies will come togetheraround.
(14:10):
But it's hard to imagine a worldin which e-commerce
driven platforms come together and agreeon one way to do things.
They're all tryingto differentiate themselves.
So yeah, seems unlikely.
Yeah, I think sometimes peoplego, Well, it's an API
and you get the datalike let's make it all standard, but
the differentiators are expressedin that API, right?
(14:31):
So like, you know,unless they all have some homogenous,
consistent offering,then that's pretty unlikely, right?
Yeah, exactly.
Yeah.
So in sort of working
in this e-commerce space, in APIs,you know, you're dealing with some huge
platforms, right,with millions of developers involved and
(14:53):
I mean, I've, you know,
like I worked at PayPal for a while andgot a taste for what that's like, right?
And it's it's hard to know sometimeswhat you're doing right or wrong.
And I'm I'm curious from your perspective,when you look at all
these different APIs,like what do you think these API providers
could be doing differently that would make
that experience better for everyone?
(15:16):
Yeah, there's yeah, I mean, I've been
I've so many doubts about thisbecause I've seen so many.
It kind of like difficultit goes to work with,
I would say.
I would say I think generally speaking
is that we struggle to work with the mostare the ones that are
they still really haven't adoptedkind of like more modern standards
(15:38):
like restor you know and and basically, Jason,
sometimes we work with a lot of XML APIsthat, you know, if you're a new developer
with Jason and new APIis trying to integrate something that has
an external API is just like,you know, that's just something else.
So I think keeping upwith kind of the standards
(16:00):
of API is somethingthat we'd really like to see people do.
And then generally I think documentationis super important for us.
It's super important.
You know, we spend a lot of time just likemaking sure everything is up to date.
You know,
the worst thing for us as beingis looking at the documentation,
trying it outand then realizing that it's like not
what's written there and being like,Oh my God, not to figure it out.
(16:22):
Like, let me just figured out likefrom scratch how this whole API works.
So that's also a big deal.
And something we actually dosee like out there in the world.
You know, it's funny,I can't help but reflect have been,
you know,doing this API stuff for a long time that
if I'd asked this question in like 2012,I better get the same answer.
(16:44):
Yeah, and I'm tired of this openXML stuff.
This new restinglooks like it's a lot better to work with.
And can we move to Jasonbecause XML stinks to work with
and you know, quitsending me PDFs with old specs.
Yeah, I No, no.
Some things never change,
and it's hard to believe thatin, you know, 20, 22 coming into 23.
Like we're still dealing with a lot of theand small stuff.
(17:07):
It's hard to believe.
Yeah, I was honestly surprisedby some of that as well.
I think some, some companiesmaybe they just
haven't that's workingand they don't really want to update it.
But of course, that kind of the trade off,you know,
you won't see a lot of new developmentin your ecosystem.
So I think people are kind ofstill trying to adjust.
(17:30):
Yeah, for sure.
API developed.
It's not cheap, you know, I don't meanto be disrespectful to anybody.
And if you're making moneyand it works, why change it? I get it. But
it's interesting though, on
the on the docs that you point outjust simple accuracy, just like
do the docs actually reflectwhat the thing does?
Yes, it's it's remarkable.
(17:50):
And I think the advent of like,
you know, open APIand these kinds of things,
you know, giving you a way to sort ofgenerate documentation based on the spec
that you also usedto generate your implementation,
you know, seems to have been the thing
that's made that better, broadlyspeaking, you know,
(18:10):
but even then within examples and guidesand things, it could still be off.
So yeah, it's hard.
I'm curious in kind of, you know, you're
dealing with a lot of this sortof the financial component here
and not necessarilypayments specifically, but
I'm curious with,
you know, the fintech space has just beenreally frothy over the last few years
and lots of kind of API approachesto those things, like,
(18:34):
you know, what are you seeingand kind of the direction
of where all that stuff is going.
And what's interesting to you?
Yeah, I think at least wherewe're positioned kind of in the fintech
world, fintech this, you know, sobig and growing so, so quickly.
I would say there isI think like consumer fintech was
was definitely revolutionizedlike a few years ago
(18:56):
because, you know, Plaidbasically made banking
did an access to banks availableto a lot of other apps.
So that changed the game, definitely.
And I think now, you know,people are catching up.
And I think in Europethere's open banking as well.
So like the need for the is like a lota lot less.
Now I would say somethingsimilar is definitely happening in the
(19:17):
business commercial realm of things.
So when it comes to businesslending versus consumer lending
or kind of business financial software
tools versus like consumer
kind of like personal financial toolsneeds, a lot of development going.
There is there's a lot of neobanks as well
and kind of like spend management toolslike ramp and tracks and all that stuff.
(19:38):
So all of these kind of businessmanagement tools of business
financial tools requiresome level of access to business data,
whether it's accounting or ecommercedata or payments data.
And so that's where we've been basically
operatingand we see a lot of growth there.
Yeah, very interesting.
(19:58):
I guess what are some examples of a
I think you maybe named one in there,but like what are some examples of things?
Yeah, I would say
for example,I think a big one is business lending.
I think I covered as well.
There was like a big periodof what people were offering SMB loans,
P2P loans to help out businesses,and a lot of underwriting is being done.
(20:21):
And I think a lot of a lot of companieswant to underwrite faster
with with better data.
So that kind of that'swhere getting access to QuickBooks
financial statements or revenue numberslike that's where that's helpful.
I think you've got
you might have seen some new startupswhere they're able to kind of convert
your Moran to RR and these kindsof like financial products.
(20:43):
And that's what they also needto underwrite on some subscriptions, data
or financial data as well.
And then I think
the other thing that we've been seeingas we work with a company called RAMP
that provides credit cards to companiesand, you know, they all see to underwrite
how much credit to give to a companywhich also requires data.
(21:03):
So we also help out there.
Very interesting.
Eric, any other closing thoughts here
for us on API aggregatione commerce, FinTech?
You know, we covered a lot of things here.
Any other thoughts for listeners here?
Yeah, I think yeah.
(21:23):
I mean, I think we covered a lot,but generally the process of like, of,
you know, build is tough,you know, learning
all these different kindsof documentations and formats.
And so I think for us behindwhat we're doing is, is that
but also, you know, being able to scalebecause maybe, you know, like
someone would look at it and be like,I can build
(21:46):
ten APIs even if they're all differentpretty quickly.
But for us, the goal is to eventually,you know, hit 100, 200, 500 APIs.
And that's kind of the more that we have,the more value we deliver.
So a big part of our systemis just be able to scale our APIs
and kind of repeatedly generateknow scaffold ing
(22:06):
templating to allow our team to,you know, ship new integrations quickly.
So that's a big partof what we do as well.
And with that, we want to help
it cool.
Well, thanks again for joining us.
And insurance and mushroomssharing so much about what you guys do.
Yeah.
Thanks so much, Jason, for having me.
(22:29):
Thanks for listening.
If you have a question you want to ask,look in the description of whichever
platform you're viewing or listening onand there should be a link there.
So you can go submit a question
and we'll do our bestto find out the right answer for you.
API IntersectionPodcast listeners are invited to sign up
for Stoplight and save up to $650.
Use the code INTERSECTION10 to get 10% offa new subscription to Stoplight Platform
Starter or Pro.
Take a look at this episode's descriptionfor more details.
I'm Jason Harmonand this is API Intersection
(00:20):
where you'll get insights from experiencedAPI practitioners to learn best
practices on thingslike API design, governance,
identity, versioning and more.
(00:41):
Welcome back to API Intersection.
So we've had a couple of guests onbefore we kind of talk about, you know,
“consuming APIs from lots of differentthings is hard
and how can we make that easier,”
which I thinkwe can all sympathize with or, you know,
have some experienceof trying to integrate too many things
(01:01):
and having it all fall apart.
So I'm looking forward to sharing some ofthe learning from Eric Yu from Rutter.
Eric, tell us a little bit about yourselfand what you guys do ar Rutter.
Yeah, I'm Eric.
I'm one of the co-founders of Rutter.
We've been around for,I think two years at this point.
Basically,we are a universal API API aggregator
(01:24):
for a lot of different kinds of businesssoftware,
e-commerce platforms like Shopify,Amazon accounting systems like
Xero and QuickBooks,and then some payment systems
like Stripe and PayPal and charge fee.
And so we standardize all of those APIsinto kind of a unified format
so that people don't have to readany different kind of documentation.
(01:48):
And then we just make that one API to workwith.
Got it.
I mean, what do typical kind of customerslook like for you guys
as far as who's looking to integratewith all the different things?
Yeah, I would say for usit falls into two main buckets.
(02:09):
One is basically more focus on ecommerce.
So a lot of ecommerceecosystem apps like marketing tools
and new ways to like marketplaces, waysand places to sell stuff
and they use our ecommerce APIs to like
get products,create orders, all of those things.
(02:29):
And then the other big segmentof customers is on the fintech side
where they want to get access to a lotof this business data in e-commerce
platforms and accounting platformsto basically get like a better view
of the company in the financial health,the company to use an underwriting
or like lending or credit cards,all kinds of different use cases there.
(02:51):
Got it.
I always like to kind of learn from folksthat,
you know, kind ofhave the the moxie to go found something
like what got you to this point?
What got you thinking abouttrying to solve these problems? And
I don't know, maybe this might soundjerky, but like, you know,
why should our community of listenerstake your idea seriously?
(03:12):
Yeah. Yeah, definitely.
Yeah.
I mean,
we we've been through many ideas thatdefinitely should not be taken seriously.
So we, we started out
basically NYC doing somethingcompletely different.
It was a dev toolfor translation, actually,
like a kind of internationalization tool.
We then basically built that.
(03:35):
Realized some things weren't workingand so pivoting for a long time,
kind of one into the desert for liketwo years trying to figure things out.
And I think eventually for us, becausemy co-founder and I are both engineers,
we had been kind of buildingthese different apps
that required integrationand the other tools
and realized at some point that we weredoing the same thing over and over again.
(03:56):
We had seen what was happeningin the space with new universal APIs
like payroll ones,and of course applied this for banking
and felt that we could just try to doone for e-commerce platforms.
And that's kind of where we started.
And so we did that.
We weren't entirely surewho would use it at the beginning,
but we then kind of reached out to many,many different kind of developers
(04:16):
on the Shopify
App Store to see who was interestedin getting their app on other platforms
and found some of these customer segmentsthat I mentioned
and then went from there.
Got it.
Yeah, it's it's interesting,you know, this notion of like aggregation
platforms around API to sort of address,you know, the diversity of consistency
(04:40):
that user experienceseems like there's kind of this
pick, you know, pick a segmentand be good at it.
But the idea that you can be good at allthe things is too broad and that there's
been, you know, not a lot of big successstories that came out of that.
And I love that you mentioned Plaid.
I feel like that's that's the thingthat's kind of inspired everyone
to try to go solve this in particularsort of verticals.
(05:03):
It's interesting.
So, you know,I already started hinting at,
I guess, the things I've heard before,But I'm curious from your perspective,
like, you know,
what's hard about trying to integrate
with multiple providersin terms of consuming those APIs?
And you know, the engineeringchallenges it presents?
(05:27):
Yeah, I thinkthere's definitely a lot of challenges
when it comes integratingwith different APIs, but I would say
probably the two biggest ones for meare one dealing with.
Generally speaking, there's definitelysome APIs out there that are more tech
forward and companies that are more techforward, like Shopify is great API.
(05:47):
So those are pretty straightforward to do.
But then when you have to make them workwith APIs that are like more nightmarish,
like Amazon's API that uses like reportsto get data or, you know, or
async requests that take minutes to finishinstead of like a few seconds to finish.
That's when you run to challengesstandard or standardizing the APIs.
(06:08):
So that's, you know, a huge problem.
And then secondly,when you deal with these APIs
and fetch data like we areand kind of like sanitizing it,
you have to deal with many different kindsof rate limits
and building a system that can handlea lot of these different errors,
permission errors, rate limit errors,
you know, trending errors in these APIs.
(06:30):
That's it takes a it takes a lotto basically maintain that system.
Yeah, that's that's the bit where
I think you know we talked
to a lot on the showhere to folks that like build APIs, right.
Running some sort of program
and you know, we talk a ton about,you know, what's important
(06:51):
and it's like,you know, design and language and,
you know, some of these scaling factorsand all that.
But it's like, what are the errors?
Like, you know, how many times does thatcome up very often?
And it shouldprobably should be a lot more.
So it's interesting, though, that on onehand, you're having to sort of consolidate
what is sort of a model to representthis concept across multiple things.
(07:15):
And then on the other side ishow do you present
the flow of errorsin sort of a consistent fashion?
Seems like
two pretty different problemspaces, though.
Yeah, definitely.
I think we've spent a lot of time on onboth ones.
And I think for the first onewith the consolidation
and centralization of information,that's really just a lot of iteration.
(07:38):
Like you can try it.
You basically just start with the,
the most simple these APIand kind of go from there.
And then when you talk to different usersand they want more field
or they want to change certain things,that's kind of how you learn
eventually,kind of what the ideal output looks like.
So it just kind of a processof learning for us, I think.
On the error side.
Yeah, we spent a lot of timeworking with various errors.
(07:59):
I think some APIs, they tell us errors
where some of the messageshave been in different languages.
So like a, you know, a
Dutch error message saying that you can'taccess the store's permission.
We tried to kind of learn over timehow to handle all of those.
Yeah, the error message that tells youyou've selected the wrong language.
(08:20):
Yeah, exactly.
So, you know, it's an intriguing spotto be in that
you go, okay, I've looked at allthese different sort of data models
that these different APIs provide and,you know,
it's it's like the meta design problem ofhow do you come up with something good?
(08:41):
It's like, you know, your worst problemin that scenario
is that you end up producing somethingthat is the sum of all of its parts.
That's worse than any one of them.
So from a kind of API design perspective,how do you guys think about that?
Yeah, definitely.
I think for us, you know, I think I thinka big, big part of this is just learning.
(09:02):
And so we start with kind ofwhat is the gold standard.
So in for example, e-commerceAPIs, Google Center is Shopify,
and we canwe use that as kind of a skeleton.
And then we basically go out, we try tonot include too many fields because
it's kind of overwhelming for peopleto like, learn what all the fields mean.
But over time,we do add some based off of user feedback.
(09:24):
So we try to basically make it moreand more useful.
But as you mentioned, like you also justcan't dump everything in there.
And so the way that we've kind of
got aroundthis is we allow our users of the API
to also get direct access to some of theseunderlying APIs that we're connected to.
We give them the tokens
(09:46):
and so that allows themin certain situations
where they need to make direct calls orget something unique or specific to them,
make a direct call to the shopvia Amazon API
and do what they do, what they need to do.
So we try to make as much standardizationas possible, but then for some off
cases, you know, we allow the flexibilityof like using the API directly.
(10:08):
Yeah. Now I think it's like
when folks think about these thingsthat always like take the least common
denominator approach the leastthe least number of common things.
Don't try to do the mash them all togetherto get all the things,
because that's never going to work out.
(10:29):
So, I mean, you mentioned like ratelimiting and some of these things.
I also think about like,
you know, one of the consumption problemsfolks run into a lot
is sort of almost hardwiringtheir infrastructure to some external API.
And then when it goes down, everythingjust, you know, totally falls apart.
And so this kind of availability factorlike sort of the,
(10:52):
you know, buffer for that, likeare you guys providing anything like that?
And then I guesswhat would your sort of recommendations
on the right waysto approach those things be?
Yeah, I think
for us, we what we do is we actually takein all the data from these different APIs
and then and store itand then centralize it on our end.
So we're making that available directlyto our database, to our users.
(11:15):
So the good thing is that if an API goesdown, let's say like Shopify
or one of these other platforms,people can still fetch data from us.
We just won't be able to kind of updatethat while the other APIs down
and also post requests
won't work because we can't we can't makethose requests to external API.
So I think that's actually a tacticthat a lot of consumers of APIs use.
(11:39):
We've talked to peoplewho've told integrations with QuickBooks
and Shopify these different platforms,and it is something similar
where they store the data
to avoid downtime,but also to of what's on the rate
limits of kind of refashionthe data over and over again.
So that's a big thing that we do.
So here's aI don't know what to call a hot take,
(12:01):
but probably a contentious questionas someone in your position.
But like, you know,
I've been in software a long timeyou know, since nineties dot com bubble.
Right.
And seenthese kind of trends come and go of like
an industry standardizing on one thing.
And I look in modern era to likeand say health care
you got like the fire API spec right.
(12:22):
I mean do you see thatlike some more of these kind of verticals
might start moving toward
standardizing on things and,
and is that like what we should be doing
and or do you think folks like yourselfare leading the way toward that.
Yeah, it's yeah,I mean that's super interesting question.
(12:42):
I think from from what I've seen there.
But like whereas in other fieldsI've also noticed I think in messaging
and communication there's been kind ofthese more standard protocols.
An API is to use Messenger.
I message all of those things.
I haven't we haven't seen the same thing
develop yet in the ecommerce worldor the accounting world.
(13:04):
So I don't think there's like a a bodythat's kind of leading that effort.
And I think like from what we see,
it's it's definitely more similarto the banking world.
It's been more fragmentedand and that's kind of the body steps in.
There won't be much innovation.
And I think in the e-commerceand accounting world,
there's no like government that's wantingto coming in and help out there.
(13:27):
So for now,I think like for us, we're kind
of trying to do the workto make people's lives easier.
But if there is kind of athat kind of steps in to deliver
some additional value or standardization,I think we'd make use of that.
And then just kind oflook for other places
where there's there's not thatand try to be a universal API.
(13:48):
Yeah.
I mean, I think you're rightin this particular kind of vertical.
I mean, I will say thatlike sure, governments
can step in and regulate things
and that is certainly a source of whypeople would do these things.
Sort of portability.
Interoperability in some areascan be like a driver
that's more organic or that,
you know, companies will come togetheraround.
(14:10):
But it's hard to imagine a worldin which e-commerce
driven platforms come together and agreeon one way to do things.
They're all tryingto differentiate themselves.
So yeah, seems unlikely.
Yeah, I think sometimes peoplego, Well, it's an API
and you get the datalike let's make it all standard, but
the differentiators are expressedin that API, right?
(14:31):
So like, you know,unless they all have some homogenous,
consistent offering,then that's pretty unlikely, right?
Yeah, exactly.
Yeah.
So in sort of working
in this e-commerce space, in APIs,you know, you're dealing with some huge
platforms, right,with millions of developers involved and
(14:53):
I mean, I've, you know,
like I worked at PayPal for a while andgot a taste for what that's like, right?
And it's it's hard to know sometimeswhat you're doing right or wrong.
And I'm I'm curious from your perspective,when you look at all
these different APIs,like what do you think these API providers
could be doing differently that would make
that experience better for everyone?
(15:16):
Yeah, there's yeah, I mean, I've been
I've so many doubts about thisbecause I've seen so many.
It kind of like difficultit goes to work with,
I would say.
I would say I think generally speaking
is that we struggle to work with the mostare the ones that are
they still really haven't adoptedkind of like more modern standards
(15:38):
like restor you know and and basically, Jason,
sometimes we work with a lot of XML APIsthat, you know, if you're a new developer
with Jason and new APIis trying to integrate something that has
an external API is just like,you know, that's just something else.
So I think keeping upwith kind of the standards
(16:00):
of API is somethingthat we'd really like to see people do.
And then generally I think documentationis super important for us.
It's super important.
You know, we spend a lot of time just likemaking sure everything is up to date.
You know,
the worst thing for us as beingis looking at the documentation,
trying it outand then realizing that it's like not
what's written there and being like,Oh my God, not to figure it out.
(16:22):
Like, let me just figured out likefrom scratch how this whole API works.
So that's also a big deal.
And something we actually dosee like out there in the world.
You know, it's funny,I can't help but reflect have been,
you know,doing this API stuff for a long time that
if I'd asked this question in like 2012,I better get the same answer.
(16:44):
Yeah, and I'm tired of this openXML stuff.
This new restinglooks like it's a lot better to work with.
And can we move to Jasonbecause XML stinks to work with
and you know, quitsending me PDFs with old specs.
Yeah, I No, no.
Some things never change,
and it's hard to believe thatin, you know, 20, 22 coming into 23.
Like we're still dealing with a lot of theand small stuff.
(17:07):
It's hard to believe.
Yeah, I was honestly surprisedby some of that as well.
I think some, some companiesmaybe they just
haven't that's workingand they don't really want to update it.
But of course, that kind of the trade off,you know,
you won't see a lot of new developmentin your ecosystem.
So I think people are kind ofstill trying to adjust.
(17:30):
Yeah, for sure.
API developed.
It's not cheap, you know, I don't meanto be disrespectful to anybody.
And if you're making moneyand it works, why change it? I get it. But
it's interesting though, on
the on the docs that you point outjust simple accuracy, just like
do the docs actually reflectwhat the thing does?
Yes, it's it's remarkable.
(17:50):
And I think the advent of like,
you know, open APIand these kinds of things,
you know, giving you a way to sort ofgenerate documentation based on the spec
that you also usedto generate your implementation,
you know, seems to have been the thing
that's made that better, broadlyspeaking, you know,
(18:10):
but even then within examples and guidesand things, it could still be off.
So yeah, it's hard.
I'm curious in kind of, you know, you're
dealing with a lot of this sortof the financial component here
and not necessarilypayments specifically, but
I'm curious with,
you know, the fintech space has just beenreally frothy over the last few years
and lots of kind of API approachesto those things, like,
(18:34):
you know, what are you seeingand kind of the direction
of where all that stuff is going.
And what's interesting to you?
Yeah, I think at least wherewe're positioned kind of in the fintech
world, fintech this, you know, sobig and growing so, so quickly.
I would say there isI think like consumer fintech was
was definitely revolutionizedlike a few years ago
(18:56):
because, you know, Plaidbasically made banking
did an access to banks availableto a lot of other apps.
So that changed the game, definitely.
And I think now, you know,people are catching up.
And I think in Europethere's open banking as well.
So like the need for the is like a lota lot less.
Now I would say somethingsimilar is definitely happening in the
(19:17):
business commercial realm of things.
So when it comes to businesslending versus consumer lending
or kind of business financial software
tools versus like consumer
kind of like personal financial toolsneeds, a lot of development going.
There is there's a lot of neobanks as well
and kind of like spend management toolslike ramp and tracks and all that stuff.
(19:38):
So all of these kind of businessmanagement tools of business
financial tools requiresome level of access to business data,
whether it's accounting or ecommercedata or payments data.
And so that's where we've been basically
operatingand we see a lot of growth there.
Yeah, very interesting.
(19:58):
I guess what are some examples of a
I think you maybe named one in there,but like what are some examples of things?
Yeah, I would say
for example,I think a big one is business lending.
I think I covered as well.
There was like a big periodof what people were offering SMB loans,
P2P loans to help out businesses,and a lot of underwriting is being done.
(20:21):
And I think a lot of a lot of companieswant to underwrite faster
with with better data.
So that kind of that'swhere getting access to QuickBooks
financial statements or revenue numberslike that's where that's helpful.
I think you've got
you might have seen some new startupswhere they're able to kind of convert
your Moran to RR and these kindsof like financial products.
(20:43):
And that's what they also needto underwrite on some subscriptions, data
or financial data as well.
And then I think
the other thing that we've been seeingas we work with a company called RAMP
that provides credit cards to companiesand, you know, they all see to underwrite
how much credit to give to a companywhich also requires data.
(21:03):
So we also help out there.
Very interesting.
Eric, any other closing thoughts here
for us on API aggregatione commerce, FinTech?
You know, we covered a lot of things here.
Any other thoughts for listeners here?
Yeah, I think yeah.
(21:23):
I mean, I think we covered a lot,but generally the process of like, of,
you know, build is tough,you know, learning
all these different kindsof documentations and formats.
And so I think for us behindwhat we're doing is, is that
but also, you know, being able to scalebecause maybe, you know, like
someone would look at it and be like,I can build
(21:46):
ten APIs even if they're all differentpretty quickly.
But for us, the goal is to eventually,you know, hit 100, 200, 500 APIs.
And that's kind of the more that we have,the more value we deliver.
So a big part of our systemis just be able to scale our APIs
and kind of repeatedly generateknow scaffold ing
(22:06):
templating to allow our team to,you know, ship new integrations quickly.
So that's a big partof what we do as well.
And with that, we want to help
it cool.
Well, thanks again for joining us.
And insurance and mushroomssharing so much about what you guys do.
Yeah.
Thanks so much, Jason, for having me.
(22:29):
Thanks for listening.
If you have a question you want to ask,look in the description of whichever
platform you're viewing or listening onand there should be a link there.
So you can go submit a question
and we'll do our bestto find out the right answer for you.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.