Subscribe
Share
Share
Embed
This week on the API Intersection podcast, we spoke with Gil Feig, Co-Founder of Merge, a company focused on building unified APIs that users can embed into their products and offer integrations to their customers. Merge offers one API to integrate with all HR, payroll, directory, recruiting, accounting, ticketing, and CRM platforms. During his enterprise engineering days, Gil noticed a constant need for companies to integrate their software with other platforms via APIs, so he sought to solve that problem via a concept called unified APIs.
We spoke with Gil to understand the significant benefits of a unified API approach and some of the downsides to help educate the community on if this approach is the right fit for your own API strategy.
_____
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). Valid until December 31, 2022
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 I would say we're going to do a little
something different today
because that's what I always
end up taking. But I don't know.
I think we're going to do something
we've done before,
but it is different than building APIs.
And I think it's it's
like kind of looking at
how do you consume lots of apps
that are real similar and make it easier.
That is this kind of API
aggregation space, so to speak,
and some things
maybe we can learn from it.
So I'm happy to have Gil Feig here
today from Merge,
one of the co-founders who was kind enough
to take his time spent with us.
So thank you for joining Gil.
Yeah, thank you so much for having me.
And my lovely cohost Anna here, as always.
Thanks for having me.
All right.
So, Gil.
Merge, I guess, you know, give us the
the elevator pitch here.
What do you guys do so the listeners
understand we're coming from?
Yeah, absolutely.
You mentioned the notion of an aggregator.
And I guess that's
that's a good way to describe us.
Essentially,
what we do is build unified APIs.
So, for example, you are a B2B company,
you need to offer integrations
with, say, h.r.
Platforms to your customers.
Merge integrates with 30, 40, 50 h.r.
Platforms, unifies them
all into a single format and then provides
one API that our customers consume.
We started with h.r.
Payroll and at a rapid tracking systems
have expanded to a lot of other verticals
such as CRM, ticketing,
accounting and planning on tackling
all B2B verticals over time.
Got it.
So I guess that means you
your customers are trying to build
companies and have lots of these things
available for themselves
or is it for their customers?
It is for their customers.
So we build APIs that that they use
to to embed
within their products
to offer integrations to their customers.
So let's say a sales ops platform
that needs to integrate with Salesforce,
but they also because their customers
may not use Salesforce, they might use
HubSpot or some other CRM, they don't want
to build all of those differences.
I'm integration.
So instead our customer integrates
once with us and then their customers,
no matter which CRM they're using, can
choose to integrate with their platform.
Got it. Okay.
Integrate all the things.
All the things.
You never know what your customer
is going to be on and you're
looking at 50, 60 or more platforms.
And that's where we come in.
So it's funny, you know,
I always think back to like,
you know, because I'm old,
I hide the gray hair pretty well.
But I think back to like, you know, late
nineties, early 2000, seeing, you know,
some of these products coming out saying,
you know,
we're going to have this, you know,
one definition for how to do this,
you know, universal,
commoditized thing in a given space.
And it just sounded so dreamy.
And I feel like now there's there's
lots of this stuff all over the place.
And sometimes scratch my head and go,
like, why is it still like this?
Why do we still not have one way
of doing things?
So I'm curious to get your take from,
you know, doing this for a job,
you know,
trying to build a company around the idea.
Why is it still this way? Yeah.
I mean, I think first of all, obviously
merge exists because it is that way.
But you know, when you look back,
there's there's a lot of reasons.
I think one is companies
release things over time.
So you have a company that built an API
20 years ago when
not only the sort of notion of how APIs
themselves were built were different,
but the industries themselves,
the requirements of payroll and laws
have changed.
You have is 2% shareholder now
mattering in tax law
and that's now a field
that exists in newer h.r.
And payroll systems.
So there's a lot of things that that cause
all these companies to evolve,
but because of that, they kind of all
end up being pretty different.
You also have different philosophies
on APIs in general companies
that want to keep data in-house
and not expose it.
So they only expose very limited data
or expose it in some, you know, very,
very difficult
to integrate with way versus other
platforms are all about open ecosystem.
We think we can be Salesforce
by letting everyone build on top of us
and becoming that core system of record.
So yeah, I can keep going.
There's a million reasons,
but you ultimately end up with with almost
no companies
that tend to do very similar things,
but it's almost like they speak
completely different languages.
Yeah,
developers tend to find themselves
like on different camps, right?
Some of them like to build from scratch.
Some of them like to pick and choose
from the best open source tools
or the best APIs that are out there.
Who are you talking to?
Who are you selling to when you're
trying to describe how a unified API
will benefit a developer?
Yeah, it's a great question.
So we mainly sell to,
you know, chief product officer, CTOs,
you know, head of product or, you know,
someone, some engineering leader.
We do occasionally
also do bottoms up to an engineer
who's researching
how do I pull employees from Workday?
And then they land
upon an article from us about that
and they end up diving in and realizing,
Hey, we don't need
just Workday, we need all these platforms,
but ultimately, it's it's
a similar problem of a company, you know,
especially in B2B, which we target
when they go out, when they set out and
say, hey, we need to build integrations.
They're not going out and saying,
you know,
we need to build workday integration
because we have a customer on work day.
They're saying
we need to build our integrations
because some of our customers
are in Workday and some are on pay vlocity
and some are on bamboo
and gusto and namely in rippling.
And you know, it's just so many of them.
And so they start seeing this problem
and realizing
like this is going to be a never ending.
And so they make that choice.
You know, do we choose merge
or do we choose to build these one by one?
I mean not just merge,
but do we choose a unified API?
They exist for a lot of different
verticals, right?
So in e-commerce, you have you have rudder
and you know, there's just so many there.
And so then, you know, they're kind of
looking at the problem deciding and they
ultimately do first like a technical deep
that's you will have an engineer dove in
so often conversations do involve both
the PM who recognizes the benefits of it
and then the engineer
who recognizes the benefits but also
doesn't necessarily trust you right off
the bat, wants to make sure it can do
everything they need and wants to dove in
and actually deeply understand it.
I mean, do you ever feel like
when you look at some of these industry
verticals,
like why haven't they just come together
and defined one thing?
I know you asked it,
but I just can't get off of it
when I think about your space, like.
And would that have been and I know you're
totally not objective, right?
Like you're
trying to build a company around this gap.
Do you think, like,
the world would be a better place
if some of these verticals
would just align on one standard
for some of these things?
I think maybe so.
But it also
begs the question, like whenever you do
something like that, it's an investment.
You have to make a lot of changes
on your end.
And ultimately,
what's what's the benefit to our company
of agreeing to a standard
of our data transfer?
I mean, maybe they can have more companies
integrate with them.
But ultimately,
there's also that fear of, you know,
hey, our data is now going
to get ripped out of our platform
and just ported somewhere else
because it's much easier to do that
for all speaking the same language.
So I think, yeah, there would be benefits
mainly for the consumer,
but I don't think as many
for the actual businesses themselves.
Yeah, no.
And I'm being coy too
and baiting here in the sense
that I think, you know,
I feel like our listeners
are probably asking themselves
this when they look at this kind of stuff.
But, you know, older, wiser,
Jason looks at it and says like, yeah,
you're looking at product differentiation.
Everybody wants to have a different flavor
and a different look.
But I guess when I put yourself
in your chair of how to design for 40,
50 different things,
like when you put those all together,
you either have like a least
or greatest common denominator.
Do you end up with the sprawling landscape
of too many things,
or do you end up with it
being so lean that it's,
you know, questionable usefulness?
And how do you balance that?
Yeah, it is a great question.
I think I think, for one,
we recognize that we have to go deep.
It was an evolution for us as a company.
But when we started out, we were like,
basically what we do
is we make a massive spreadsheet
of all the platforms,
all the models down to a field level.
So, you know, you're
talking employee, then your first name,
last name, date of birth, everything.
And then we go through and we check,
you know, is this platform supporting it?
Is it minimally supported,
that sort of thing?
And then we look for for dominance.
And if it seems like everybody supports
something, it's going to be included.
If it seems like something's
not very supported.
But the main platforms, the ones
with a huge market share, support it.
We tend to include that as well, you know.
But what do we do
if if something like Gastos is 2%
shareholder field on
the employee is not commonly supported
in that case,
we do have a big decision to make
because if we if we list that as a field
that supported
our developers, you know, customers
are going to come in and build on that.
They're going to assume that that field
is going to come through.
They're going to build a product
that relies on that field coming in.
And then we've really misled them
when when their customers
start connecting their platforms
and realizing,
hey, it is actually only supported
for one platform.
So in general,
we try to go as deep as possible.
But we are we are nuanced about it.
We don't cover things that we really think
have zero
or virtually zero industry support.
And then we do have
some sort of alternative methods.
Anything you can do by building directly,
you are able to do with with Merge
and some other unified APIs
through other methods of directly
accessing the underlying data.
But but overall, yeah,
when it comes to being unified,
it is a big decision,
a big tradeoff you have to make.
I mean, I guess the curiosity as you
probably see a lot,
you know, all the different styles
and flavors of of API designs,
you know,
when you guys kind of sat down to look at
what's the what's our style versus
all these myriad of options
out there, like how did you decide
what should look like for you?
Yeah.
So I think we a lot of us
came from backgrounds of building APIs,
of course, and that's sort of
what led us to to start marriage.
But we obviously yeah.
Big decision there.
I think there were some that we rolled out
like we weren't
going to build a set of API, we weren't
going to build, you know, some older ones.
But you know, there were a few options
like we could have done RBC,
we could have done rest Graph Tool.
We were considering a few different ones
there.
I think RBC, it just wasn't it wasn't
widely supported enough
or widely understood enough.
We're building something that we wanted
the most possible developers
to be able to understand.
We know everyone's aware of GraphQL,
and we know that it is up and coming
and it is
what a lot of people think is the future.
But again,
it just wasn't something that we viewed
as as being widely understood enough,
something that would just get people up
and running as quickly as possible.
So we decided to go with rest.
Obviously, we built a lot of our back
and infrastructure in a way
that it would be easy for us to either
convert our API or launch a new version
that is graph to always,
if we decide to do that in the future
or really we're kind of like what we do
with the underlying API is we integrate
with we we analyze a lot of things
like adoption to understand
what's going to be the most successful
for our customers.
Yeah, it's
I feel like it's boring choice,
but it's true.
Like I look at these things
about once a year, we kind of go look and,
you know, think about like
what are the predominant pattern
for sort of externalized APIs,
you know, not necessarily microservices
or internal stuff
and, you know, for better or worse, it's
the state of things.
It's like GRC
wasn't really built for that.
And GraphQL
just there's risky stuff in there
and it's tricky to make it scale.
So. Exactly. And we thought about that.
You know, to me, it's
almost like electric cars, right?
And they're new and cool and everybody
wants one or did want one for a long time.
And it was only recently that,
you know, you had enough charging stations
and the infrastructure to support them.
And I feel like
finally it's a good choice.
And I know that graph.
You all's going to get there.
It's just not quite there yet.
Yeah, yeah, fair enough.
But even within sort of
the, you know, and I don't know, I'm
going to get like shot in social media
if I just say rest with certainty,
you know, this HTTP style API,
there's a lot of space for flavor
within that.
You know? Did
you know when you guys were doing
that early coding
as I'm sure you're involved in, you know,
how did you think about,
you know,
what your kind of models were for?
You know,
what could look like, right?
Like, yep, yeah.
It makes sense.
I think I think for us, one big thing
was any notion of of 1 to 1, right?
So let's say an
employee can have a job title
and that doesn't change.
It's going to be that forever.
That would just live on the employee.
So we follow this notion of, you know,
making our models as wide as possible,
reduce joints, reduce the number of
of additional requests you need to make.
But in in situations of one too many,
which is really common for us.
So unfortunately, job titles do change
and people want that history, right?
So that's where the employee now
has employments
that represent for for a period of time
they were a manager
and then they were a senior manager
and people want that historical data.
So we, we don't want to make someone
they'll have to make one API request to us
for the employee and then make ten more
for each of their employments
or for one
for the list of employments, for example.
So we've really, really loved the idea of
this is in the standard respect
by the expand parameter.
That's a big one we use.
So anything we return back IDs or you
you can ask us to expand it
as a query premium and instead of an
ID you're going to get back a full object
that that's something
that actually has been really tough with.
I know that you guys are pretty
deep in open API.
If open API doesn't
have great support for this yet.
And while you can represent an open API,
most of the things that that are,
you know, like SDK generators and docs
generate, they tend to struggle
a bit more with with types that change
depending on your for your prime.
So yeah, that's, that's
one of the decisions I would say we chose.
Yeah.
And then some,
some ordering based ones, page size
based ones, a lot of different ones there.
But, but our goal again was
when we built integrations with all these
different APIs, what did we find to be the
the easiest for us,
the easiest to understand
and also basically enable
what what enabled us to build
really efficient APIs that didn't require
X and the API requests
to fetch and records for example.
Yeah,
excuse me, I'm a big fan of that kind of
expand pattern that you get what you need
and then if you need more,
you just kind of ask for it.
Feel like
kind of solves
for a lot of what people sort
of through a GraphQL at everything for
but you know it can be
a tricky engineering problem
to actually make that work well.
But it sounds like kind of
I wanted to call it another thing that you
you did here, which is saying that
rather than an employee
as kind of the now in the resource
and rather saying that, you know,
either you then have to go get history,
it's like employments,
it's like by just plural izing,
a verb can make it a noun
and a collection of things, right?
So it's kind of funny how the linguistics
of playing in kind of API design
and keeping things as sort of a collection
of stuff you can filter on is just
I think
it's easy to overlook how straightforward
it is when you do it that way.
Yeah, and that's that's very true.
And we're,
we're really obsessive about that.
We actually released
one of our more recent APIs into a Aveda
and realized that unfortunately
we had not plural as one item
that needed to be plural as obviously
the consequences of that are quite grave.
When you have a lot of customers
who are beta onboarded,
you have all your SDK is built out,
your documentation, you,
you know, even even your back end changing
the names of the tables in the database,
all of that. It was it was a huge mess.
And so we have, I would say, pretty strict
processes around naming everything.
Now we're we're really on top of making
sure that things are crystal clear.
Do you put any sort of like automation
or anything around that that helps
you prevent those things we do?
So we added a lending rule
after it happened by you know,
I think I think it unfortunately
is one of those postmortem situations
where it won't happen again.
But it happened once. Sure. Yeah.
I think anybody that's building
APIs has had one of those design slips
and have to take it back. It stinks, but
I think, you know,
if you solve it with automation,
it certainly helps prevent the possibility
of human mistakes in the future.
So is that sort of like code
limiting level stuff that you're doing?
Yeah, so we do co-lending level stuff.
We use a few different ones.
So we have we have a normal lender.
I think we use we're on iPhones,
we use Black as our winter.
We also have been using some grep recently
which gives us more complex
rules, the ability to also detect
security issues, those sorts of things.
Got it.
Sorry, I'm intrigued by this one.
So anytime someone says they can control
the use of language with lynching,
I'm like, Tell me more.
So is it just that you're looking for
like plural language
or like singular language
as being kind of the thing to warn on?
Yeah.
So essentially we use in our we use
the Django built in our M for our models.
And what it does is essentially
it'll look to see does this model have
a 1 to 1 relationship with another model
or does it have a many to one?
And if there's a many to one,
it needs to be plural.
There's also instances
where the model itself
is not a plural name because that's
just a model in our database.
But the way it's exposed to our SDK.
So the way that our open API spec gets
generated
in there, like the endpoint name
or other things do need to be plural.
ISE So there's a few different instances
of where we have to do this.
But yeah, it is analyzing that.
It's going a bit deeper than just like
is it a model formalizing or doing
very cool.
Yeah, anytime
people like catch automation, stuff
around language, I'm always happy
because it's the hard thing.
Yeah, for sure.
And we actually are working more deeply
on, on,
you know, starting to link our open
API spec which I know, I know
Spectral is a good example
that you guys have.
It's something that we've been
eyeing and definitely are looking to add
probably in the next quarter.
And don't worry, I wasn't fishing
for a plug there and curiosity.
But yeah, it seems like everybody's
playing with Spectral these days.
It's super cool.
Yeah, very cool.
So you're filling a pretty
needful gap, right,
in a lot of verticals right now.
But what do you think
the landscape looks like?
You know, three, five years from now?
What is this going to evolve into and
especially for those verticals you use or.
Yeah, so I think what's interesting
is API
companies have changed a lot over time.
And so, you know, you go way back,
you've MuleSoft bridging on prem to cloud
and you have after that
you have sort of like uipath
like workflow automation type things.
Then you have embedded workflow automation
which would be like we're Cotto and Dre
embedded, whereas actually
the end user can onboard
and then these companies are going in
on the back end and dragging and dropping
connections, almost like Zapier in a way.
And now you're seeing more of these
unified APIs,
which are the notion based based on this
premise that that embedding,
you know, sort of like these
these workflow builders is not enough.
And companies these days actually
need to build integrations with a ton
of platforms that do the same thing.
And there's just a lot of grunt work
around building those connections again
and again and having to go in and drag
and drop and drag and drop.
And a lot of people have actually moved
away from workflow automation
and move back towards coding in-house
because it's
not solving much of the problem.
And so I think that's
one of the big reasons
you're seeing a lot of unified APIs
popping up.
For reference, the
the most well known unified API is plaid
where they're bringing together,
you know, 50,000.
Don't don't quote me on that
but 50,000 banks all in one you know, use
actually you go into Robin Hood
or you go into any any app
that connects your bank account, it
pops up and asks you to select your bank.
That that's what it is.
They were really, I would say, the
the originators or the first one
to go mainstream with it.
And the value is just so clear
that people started
seeing this problem and other verticals
and started tackling it everywhere.
So I mean, I'm seeing them
for the most random industries now.
But yeah, when it comes to B2B
and B2C transparently,
you're just you're just seeing,
I think, unified APIs are the future
for solving this problem in specific
that the embedded integration problem.
Yeah I guess deeper and deeper
kind of vertical specialties
seems to be the trend.
Yeah.
When you look at when you look more
recently, you know, you're going on these,
these companies, these websites
and they have, they have sometimes
150, 200 integrations and there's no way
they're building them all in-house.
And, you know, they need to offer it
to acquire customers because, again,
you know,
like I mentioned earlier, they don't know
which platform their customer is using.
But what they do know
is they need to offer all of them
so that they can serve every customer.
And so that's the value
of the unified API.
It's don't go build 200 integrations, it's
maybe build five
and then you're done building. Yep.
You know, the payment space,
which I spent some time
in, always makes me itchy around
like security and compliance.
But the only thing that makes me it's year
is when we talk about like h.r.
Data and all this very personal data.
So feel free to tell me,
you know, none of your business.
But I'm curious because
i'm sure there's plenty of listeners
dealing with this kind of data.
And I assume you have to cache
all this stuff is like
how in you're still fairly
small as a company if I'm not mistaken.
Like how are you tackling some of these
like really hard sort of security
compliance issues around some of the data
that you're using and not have it eat up
all of your operational budget?
Yeah, it's a fantastic question
and one that I answer almost every day.
So having to dove in there.
But yeah, before we ever launch,
you know, me and my co-founder
both came from Enterprise Software
before this, we knew it.
We had been through it.
I did security reviews probably,
probably,
probably daily for the past
couple of years before starting Merge.
And so before we ever launch,
before we even onboarded a customer,
we had already gotten our staff
to type two.
So we worked on that while we were still
building out the product that met.
That meant building a pretty robust
security program from the beginning.
We're about to get ISO,
we're about to get hit by,
you know,
we just need to keep getting them.
We're GDPR compliant.
These sorts of things are critical.
So, you know, we're really on top of it.
And that's basically
we have a lot of options for our customers
to also store their data separately.
So we offer a single tenant.
We're working pretty closely on an on prem
offering over the next
probably six months to a year.
So basically whatever customers
need, we're there to do it.
We're now we're now able to work with
some of the largest companies with really,
really intense security programs.
And it's because we focus on it heavily.
So it's phishing to see
if there is any like tips
on interesting platforms
that you're using to do all that stuff.
Or is the answer
just as simple as we're good at it?
Which if so, then perhaps for you.
But I was hoping to cheat
and steal something from you.
Yeah.
So we, we really love Java.
That's a soft to automation platform
as well as other
I guess these days, compliance
automation platform.
We use them to help
get all of our certifications,
but also candidly, they've just made us
a more secure organization.
They're constantly monitoring us,
you know, while occasionally get a paying,
hey, looks like you don't have
a load balancer and you're required
to have that for availability forever.
We'll look.
Oh, it's some new test server
that one of our engineers spun up,
but at least we know we're on top of it.
We would have we would always be alerted
if something like that happened.
And then the other pieces
is, you know, it's it's
not it's
not just building a robust program
and it's not just
getting those certifications,
but it's also being able to sell
your customers on you, having that helping
their their security team
who hasn't been involved in the deal,
doesn't really understand
what you're doing,
making sure that
that they're comfortable with you as well.
And one of the cool things about Dorada
is they also offer
a new product that they just released,
and we're pretty early in it.
It's called the Trust Center.
And what it does
is it actually exposes the monitoring
that they're doing on a page for us.
So we have an trust on merchant tabs
if anyone wants to just kind of see
what a trust center looks like.
But it lists out,
you know, here are all of our security
certifications, here's
our company policies.
Here are things like databases,
encrypted arrest.
You hear all this
and it's live monitoring it.
So if if that was ever disabled, that
would turn red on that page right there.
And then the other cool pieces
as a lot of times, you know,
you have to send out
these security certifications to customers
and they need you know,
you have to get it to in place.
There's a lot of tracking as you grow.
You start having these requests every day.
It's very difficult to keep track of.
And so with draw with the trust center,
we also now have these people coming
in, clicking requests, request, request,
and we'll get an email that says,
you know, X
customer has requested access to these
these internal policies that you have to
to these certifications.
We just click approve or we send them a,
you know, an NDA and then approve
and then boom, they have access to it.
So I would say that
has been huge on our journey
and there are of course
other players in that space as well.
Yeah, yeah.
That, that whole kind of trust
center space seems like it's exploded.
We were really fans of safe space,
so stoplights kind of security posture
page or, you know, trust center
kind of thing is is driven from that.
But I feel like we've seen
everybody's popped up something with that
in the last year or two.
Yeah and safe is
we know that team as well they're great
you know really really sharp team.
I believe they're also working
with John on some things.
So yeah, but both of those companies
are definitely great.
Yeah, cool. All right.
Well,
I guess, you know,
as you think about, you know,
this business of calling all the APIs
and doing all the things
for folks out there who,
you know, maybe aren't
are doing similar things
in their day to day.
Right. And maybe they don't need merge.
They're doing some of this stuff,
like any words of wisdom on,
you know, kind of the things
to watch out for the gotchas
in that that kind of development work.
Yeah, I think, I think there's a lot here.
I think not a lot to plug merger
I think but always
be thinking about the future here
and you know
your company
is going to come to you and say, hey,
we have a customer that needs a work day
integration.
Your first question should be,
is it just workday?
Or We're going to have to build others
in the future.
Whether or not you want to use a unified
API, be thinking about your architecture
and how you can do things,
you know, even internally.
That's sort
of where the idea of Merge came
was because internally
at our past companies
we had to build our own unified
APIs, right?
And just from different data sources,
translate them to a language
that we needed internally to use and
and could be processed
by the rest of our system.
So I think always be thinking
about the future.
Another big one is just authentication
and thinking about permissions,
realizing that your customers
are not just going to give you access
to every single piece of data
that exists within the API.
And so being able to handle,
you know, what happens
if data comes down and is missing,
you know, half the things we need
or what happens if data comes out
that they've just formatted
a completely different from
from how we did it
and then I think other ones
are really a lot of the sustainability
and the management
and you know, not necessarily
just updating to a changing API,
but you have a customer that on boards
they pay your support team.
Hey, the, the, you know personal
email for this employee is missing
what's going on next thing you know
you've created a nightmare for engineering
because engineering now needs
to support the support team on everything.
So building visibility for your support
teams, tracking dashboards,
all of those things are another
really critical thing to think about.
Very nice.
Oh, cool.
I really want to thank you
for being so open and transparent
about how you guys do things
and, you know,
certainly wish you all the best of luck.
It seems like you're growing like crazy
and must be doing something right.
Thank you so much.
And yeah, I really appreciate the time
and best of luck.
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.