Subscribe
Share
Share
Embed
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
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here: stoplight.io/question/
--- 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).
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.
API Intersection
Podcast listeners are invited to sign up
for Stoplight and save up to $650.
Use the code INTERSECTION10 to get 10% off
a new subscription to Stoplight Platform
Starter or Pro.
Take a look at this episode's description
for more details.
I'm Jason Harmon
and this is API Intersection
where you'll get insights from experienced
API practitioners to learn best
practices on things
like API design, governance,
identity, versioning and more.
Welcome back to API Intersection.
So we've had a couple of guests on
before we kind of talk about, you know,
“consuming APIs from lots of different
things is hard
and how can we make that easier,”
which I think
we can all sympathize with or, you know,
have some experience
of trying to integrate too many things
and having it all fall apart.
So I'm looking forward to sharing some of
the learning from Eric Yu from Rutter.
Eric, tell us a little bit about yourself
and 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
for a lot of different kinds of business
software,
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 APIs
into kind of a unified format
so that people don't have to read
any different kind of documentation.
And then we just make that one API to work
with.
Got it.
I mean, what do typical kind of customers
look like for you guys
as far as who's looking to integrate
with all the different things?
Yeah, I would say for us
it falls into two main buckets.
One is basically more focus on ecommerce.
So a lot of ecommerce
ecosystem apps like marketing tools
and new ways to like marketplaces, ways
and places to sell stuff
and they use our ecommerce APIs to like
get products,
create orders, all of those things.
And then the other big segment
of customers is on the fintech side
where they want to get access to a lot
of this business data in e-commerce
platforms and accounting platforms
to 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.
Got it.
I always like to kind of learn from folks
that,
you know, kind of
have the the moxie to go found something
like what got you to this point?
What got you thinking about
trying to solve these problems? And
I don't know, maybe this might sound
jerky, but like, you know,
why should our community of listeners
take your idea seriously?
Yeah. Yeah, definitely.
Yeah.
I mean,
we we've been through many ideas that
definitely should not be taken seriously.
So we, we started out
basically NYC doing something
completely different.
It was a dev tool
for translation, actually,
like a kind of internationalization tool.
We then basically built that.
Realized some things weren't working
and so pivoting for a long time,
kind of one into the desert for like
two years trying to figure things out.
And I think eventually for us, because
my co-founder and I are both engineers,
we had been kind of building
these different apps
that required integration
and the other tools
and realized at some point that we were
doing the same thing over and over again.
We had seen what was happening
in the space with new universal APIs
like payroll ones,
and of course applied this for banking
and felt that we could just try to do
one for e-commerce platforms.
And that's kind of where we started.
And so we did that.
We weren't entirely sure
who would use it at the beginning,
but we then kind of reached out to many,
many different kind of developers
on the Shopify
App Store to see who was interested
in getting their app on other platforms
and found some of these customer segments
that 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
that user experience
seems like there's kind of this
pick, you know, pick a segment
and be good at it.
But the idea that you can be good at all
the things is too broad and that there's
been, you know, not a lot of big success
stories that came out of that.
And I love that you mentioned Plaid.
I feel like that's that's the thing
that's kind of inspired everyone
to try to go solve this in particular
sort of verticals.
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 providers
in terms of consuming those APIs?
And you know, the engineering
challenges it presents?
Yeah, I think
there's definitely a lot of challenges
when it comes integrating
with different APIs, but I would say
probably the two biggest ones for me
are one dealing with.
Generally speaking, there's definitely
some APIs out there that are more tech
forward and companies that are more tech
forward, like Shopify is great API.
So those are pretty straightforward to do.
But then when you have to make them work
with APIs that are like more nightmarish,
like Amazon's API that uses like reports
to get data or, you know, or
async requests that take minutes to finish
instead of like a few seconds to finish.
That's when you run to challenges
standard or standardizing the APIs.
So that's, you know, a huge problem.
And then secondly,
when you deal with these APIs
and fetch data like we are
and kind of like sanitizing it,
you have to deal with many different kinds
of rate limits
and building a system that can handle
a lot of these different errors,
permission errors, rate limit errors,
you know, trending errors in these APIs.
That's it takes a it takes a lot
to basically maintain that system.
Yeah, that's that's the bit where
I think you know we talked
to a lot on the show
here 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
and it's like,
you know, design and language and,
you know, some of these scaling factors
and all that.
But it's like, what are the errors?
Like, you know, how many times does that
come up very often?
And it should
probably should be a lot more.
So it's interesting, though, that on one
hand, you're having to sort of consolidate
what is sort of a model to represent
this concept across multiple things.
And then on the other side is
how do you present
the flow of errors
in sort of a consistent fashion?
Seems like
two pretty different problem
spaces, though.
Yeah, definitely.
I think we've spent a lot of time on on
both ones.
And I think for the first one
with the consolidation
and centralization of information,
that's really just a lot of iteration.
Like you can try it.
You basically just start with the,
the most simple these API
and kind of go from there.
And then when you talk to different users
and 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 process
of learning for us, I think.
On the error side.
Yeah, we spent a lot of time
working with various errors.
I think some APIs, they tell us errors
where some of the messages
have been in different languages.
So like a, you know, a
Dutch error message saying that you can't
access the store's permission.
We tried to kind of learn over time
how to handle all of those.
Yeah, the error message that tells you
you've selected the wrong language.
Yeah, exactly.
So, you know, it's an intriguing spot
to be in that
you go, okay, I've looked at all
these different sort of data models
that these different APIs provide and,
you know,
it's it's like the meta design problem of
how do you come up with something good?
It's like, you know, your worst problem
in that scenario
is that you end up producing something
that 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 think
a big, big part of this is just learning.
And so we start with kind of
what is the gold standard.
So in for example, e-commerce
APIs, Google Center is Shopify,
and we can
we use that as kind of a skeleton.
And then we basically go out, we try to
not include too many fields because
it's kind of overwhelming for people
to like, learn what all the fields mean.
But over time,
we do add some based off of user feedback.
So we try to basically make it more
and more useful.
But as you mentioned, like you also just
can't dump everything in there.
And so the way that we've kind of
got around
this is we allow our users of the API
to also get direct access to some of these
underlying APIs that we're connected to.
We give them the tokens
and so that allows them
in certain situations
where they need to make direct calls or
get something unique or specific to them,
make a direct call to the shop
via Amazon API
and do what they do, what they need to do.
So we try to make as much standardization
as possible, but then for some off
cases, you know, we allow the flexibility
of like using the API directly.
Yeah. Now I think it's like
when folks think about these things
that always like take the least common
denominator approach the least
the least number of common things.
Don't try to do the mash them all together
to get all the things,
because that's never going to work out.
So, I mean, you mentioned like rate
limiting and some of these things.
I also think about like,
you know, one of the consumption problems
folks run into a lot
is sort of almost hardwiring
their infrastructure to some external API.
And then when it goes down, everything
just, you know, totally falls apart.
And so this kind of availability factor
like sort of the,
you know, buffer for that, like
are you guys providing anything like that?
And then I guess
what would your sort of recommendations
on the right ways
to approach those things be?
Yeah, I think
for us, we what we do is we actually take
in all the data from these different APIs
and then and store it
and then centralize it on our end.
So we're making that available directly
to our database, to our users.
So the good thing is that if an API goes
down, 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 update
that while the other APIs down
and also post requests
won't work because we can't we can't make
those requests to external API.
So I think that's actually a tactic
that a lot of consumers of APIs use.
We've talked to people
who'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 refashion
the data over and over again.
So that's a big thing that we do.
So here's a
I don't know what to call a hot take,
but probably a contentious question
as someone in your position.
But like, you know,
I've been in software a long time
you know, since nineties dot com bubble.
Right.
And seen
these kind of trends come and go of like
an industry standardizing on one thing.
And I look in modern era to like
and say health care
you got like the fire API spec right.
I mean do you see that
like 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 yourself
are leading the way toward that.
Yeah, it's yeah,
I mean that's super interesting question.
I think from from what I've seen there.
But like whereas in other fields
I've also noticed I think in messaging
and communication there's been kind of
these 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 world
or the accounting world.
So I don't think there's like a a body
that's kind of leading that effort.
And I think like from what we see,
it's it's definitely more similar
to the banking world.
It's been more fragmented
and and that's kind of the body steps in.
There won't be much innovation.
And I think in the e-commerce
and accounting world,
there's no like government that's wanting
to coming in and help out there.
So for now,
I think like for us, we're kind
of trying to do the work
to make people's lives easier.
But if there is kind of a
that kind of steps in to deliver
some additional value or standardization,
I think we'd make use of that.
And then just kind of
look for other places
where there's there's not that
and try to be a universal API.
Yeah.
I mean, I think you're right
in this particular kind of vertical.
I mean, I will say that
like sure, governments
can step in and regulate things
and that is certainly a source of why
people would do these things.
Sort of portability.
Interoperability in some areas
can be like a driver
that's more organic or that,
you know, companies will come together
around.
But it's hard to imagine a world
in which e-commerce
driven platforms come together and agree
on one way to do things.
They're all trying
to differentiate themselves.
So yeah, seems unlikely.
Yeah, I think sometimes people
go, Well, it's an API
and you get the data
like let's make it all standard, but
the differentiators are expressed
in that API, right?
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
I mean, I've, you know,
like I worked at PayPal for a while and
got a taste for what that's like, right?
And it's it's hard to know sometimes
what 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?
Yeah, there's yeah, I mean, I've been
I've so many doubts about this
because I've seen so many.
It kind of like difficult
it goes to work with,
I would say.
I would say I think generally speaking
is that we struggle to work with the most
are the ones that are
they still really haven't adopted
kind of like more modern standards
like rest
or you know and and basically, Jason,
sometimes we work with a lot of XML APIs
that, you know, if you're a new developer
with Jason and new API
is trying to integrate something that has
an external API is just like,
you know, that's just something else.
So I think keeping up
with kind of the standards
of API is something
that we'd really like to see people do.
And then generally I think documentation
is super important for us.
It's super important.
You know, we spend a lot of time just like
making sure everything is up to date.
You know,
the worst thing for us as being
is looking at the documentation,
trying it out
and then realizing that it's like not
what's written there and being like,
Oh my God, not to figure it out.
Like, let me just figured out like
from scratch how this whole API works.
So that's also a big deal.
And something we actually do
see 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.
Yeah, and I'm tired of this open
XML stuff.
This new resting
looks like it's a lot better to work with.
And can we move to Jason
because XML stinks to work with
and you know, quit
sending me PDFs with old specs.
Yeah, I No, no.
Some things never change,
and it's hard to believe that
in, you know, 20, 22 coming into 23.
Like we're still dealing with a lot of the
and small stuff.
It's hard to believe.
Yeah, I was honestly surprised
by some of that as well.
I think some, some companies
maybe they just
haven't that's working
and 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 development
in your ecosystem.
So I think people are kind of
still trying to adjust.
Yeah, for sure.
API developed.
It's not cheap, you know, I don't mean
to be disrespectful to anybody.
And if you're making money
and it works, why change it? I get it. But
it's interesting though, on
the on the docs that you point out
just simple accuracy, just like
do the docs actually reflect
what the thing does?
Yes, it's it's remarkable.
And I think the advent of like,
you know, open API
and these kinds of things,
you know, giving you a way to sort of
generate documentation based on the spec
that you also used
to generate your implementation,
you know, seems to have been the thing
that's made that better, broadly
speaking, you know,
but even then within examples and guides
and 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 sort
of the financial component here
and not necessarily
payments specifically, but
I'm curious with,
you know, the fintech space has just been
really frothy over the last few years
and lots of kind of API approaches
to those things, like,
you know, what are you seeing
and kind of the direction
of where all that stuff is going.
And what's interesting to you?
Yeah, I think at least where
we're positioned kind of in the fintech
world, fintech this, you know, so
big and growing so, so quickly.
I would say there is
I think like consumer fintech was
was definitely revolutionized
like a few years ago
because, you know, Plaid
basically made banking
did an access to banks available
to 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 Europe
there's open banking as well.
So like the need for the is like a lot
a lot less.
Now I would say something
similar is definitely happening in the
business commercial realm of things.
So when it comes to business
lending versus consumer lending
or kind of business financial software
tools versus like consumer
kind of like personal financial tools
needs, a lot of development going.
There is there's a lot of neobanks as well
and kind of like spend management tools
like ramp and tracks and all that stuff.
So all of these kind of business
management tools of business
financial tools require
some level of access to business data,
whether it's accounting or ecommerce
data or payments data.
And so that's where we've been basically
operating
and we see a lot of growth there.
Yeah, very interesting.
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 period
of what people were offering SMB loans,
P2P loans to help out businesses,
and a lot of underwriting is being done.
And I think a lot of a lot of companies
want to underwrite faster
with with better data.
So that kind of that's
where getting access to QuickBooks
financial statements or revenue numbers
like that's where that's helpful.
I think you've got
you might have seen some new startups
where they're able to kind of convert
your Moran to RR and these kinds
of like financial products.
And that's what they also need
to underwrite on some subscriptions, data
or financial data as well.
And then I think
the other thing that we've been seeing
as we work with a company called RAMP
that provides credit cards to companies
and, you know, they all see to underwrite
how much credit to give to a company
which also requires data.
So we also help out there.
Very interesting.
Eric, any other closing thoughts here
for us on API aggregation
e commerce, FinTech?
You know, we covered a lot of things here.
Any other thoughts for listeners here?
Yeah, I think yeah.
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 kinds
of documentations and formats.
And so I think for us behind
what we're doing is, is that
but also, you know, being able to scale
because maybe, you know, like
someone would look at it and be like,
I can build
ten APIs even if they're all different
pretty 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 system
is just be able to scale our APIs
and kind of repeatedly generate
know scaffold ing
templating to allow our team to,
you know, ship new integrations quickly.
So that's a big part
of what we do as well.
And with that, we want to help
it cool.
Well, thanks again for joining us.
And insurance and mushrooms
sharing so much about what you guys do.
Yeah.
Thanks so much, Jason, for having me.
Thanks for listening.
If you have a question you want to ask,
look in the description of whichever
platform you're viewing or listening on
and there should be a link there.
So you can go submit a question
and we'll do our best
to find out the right answer for you.