APIs You Won't Hate


Creators and Guests

Host
Mike Bifulco
Cofounder and host of APIs You Won't Hate. Blogs at https://mikebifulco.com Into 🚴‍♀️, espresso ☕, looking after 🌍. ex @Stripe @Google @Microsoft
JP
Guest
James Perkins
Co Founder / CEO of @unkeydevYoutuber: https://t.co/6CYT6beJot Theo's favorite pair programmer

What is APIs You Won't Hate?

A no-nonsense (well, some-nonsense) podcast about API design & development, new features in the world of HTTP, service-orientated architecture, microservices, and probably bikes.

. Mike Bifulco: Hey friends, Mike from NPI.

As you won't hate here
chiming in from the future.

I messed up during this interview there's
about five minutes of this interview

at the very beginning where I am using
the microphone on my earbuds to record.

And you can really tell.

So I apologize for that in advance.

But I promise I did my best
to make it better using all

the tools available at my.

Disposal using AI and audacity
and things like that to make

the audio a little nicer.

It's as good as it can be roughly
given the skills that I have, but

I just figured I'd let you know.

The entire interview is not as
miserable sounding on my end.

As it seems at the beginning.

So zip ahead if you need to, but
otherwise enjoy the interview and thanks

for watching the indoor listening.

riverside_mike_bifulco_raw-synced-video-cfr_podcast_recording w_0027:
Welcome back to another

episode of APIs you won't Hate.

My name is Mike Bico.

I'm one of the co-founders
of APIs You Won't hate.

And I'm excited to sit down
today for an interview.

Stand up today for an interview,
whatever, hop on the internet for an

interview with my my old pal James
Perkins to talk about what he's building.

And James, it's really nice
to have you on the show today.

I'm, I'm interested to hear about
UN Key and your story there.

Thanks a ton for joining us.

How are you doing?

riverside_james_raw-synced-video-cfr_podcast_recording w_0028:
Yeah, I'm good.

Thanks for having me.

It's been a while since we've talked.

Yeah, I'm, I'm happy to be here.

Happy to chat about UN key and what
we're building and how we're trying

to make APIs suck a lot less than
they, they do most of the time.

riverside_mike_bifulco_raw-synced-video-cfr_podcast_recording w_0027:
Oh, you found yourself in the right

place then I think for that discussion.

James, you and I have sort of a
serendipitous internet relationship.

I feel like every time I turn
a corner online you're poking

your head around saying, hi.

I, I don't remember exactly where
we met, but I know we crossed

paths a bit while I was at Stripe.

I.

Doing developer relations there
and later while you were doing

developer relations and now you're
starting and building a product.

So I, I'd love maybe if you
start just giving us, like,

the lowdown on your career.

How did you find your way
to what you're doing now?

And then let's talk a little bit about.

riverside_james_raw-synced-video-cfr_podcast_recording w_0028:
Yeah, for sure.

So I've been around a really long time.

I think if my co-founder listens to this,
I'm really sorry, but I have to do this.

So I've been around for 16 years.

I started way back doing Java development
for a few different companies.

First one was like a really small stage
startup that did online registration.

So in America, if you buy a car
and you get from the dealership.

And they give you like a temp tag
in the dealership or the actual

tags depending on where you live.

That software was built by
me and a, and a few people.

And then I moved on to things
like gambling and the lottery.

Did that for a while, did digital banking,
then I moved on to FinTech startups.

Tina CMS was my real break into
where people really know me.

That's when I started doing
developer relations and doing all

the sorts of YouTubes and podcasts
and all the other things that

I've done throughout my career.

And then the real thing that everyone
really knows me for was Clark which is

where I've met a lot of different people
across, across different industries.

I think that's how we actually met.

riverside_mike_bifulco_raw-synced-video-cfr_podcast_recording w_0027:
I think it may be, yeah.

riverside_james_raw-synced-video-cfr_podcast_recording w_0028:
I think you were working on a project

with Clark and you had questions
and then I think, you know, bouncing

around and then, you know, you moved
on to, to what you're doing now.

And we chatted a bit about that.

But yeah, that's most of my career.

And then I left Clark in September
which is when the funding for Key was

basically almost finished at that point.

We, we got a few checks in,
but we were still finishing up.

And then that was when I went full time.

riverside_mike_bifulco_raw-synced-video-cfr_podcast_recording w_0027:
Yeah.

Got it.

Wow.

Well, quite the career.

You've, you've touched many industries.

You know, like, like I guess a lot
of successful developers tend to do

getting your fingers deep in all sorts
of problems and getting your hands

dirty with all, all sorts of industries.

I guess that brings us to sort of
present day and maybe September

of 2023, when, when un key sort of
raised you round, but also started

making the presence online known.

Why don't you tell us about UN key?

What's the story there?

riverside_james_raw-synced-video-cfr_podcast_recording w_0028:
Yeah, so on Key is essentially a.

API management platform that we're kind of
redefining what API management is and how

it's built and how we're using it today.

So if you think about API management
platforms today, you're talking things

like Kong or Tyke or even, you know,
Google's offering or AWS is offering

through gateways and things like that.

And when we were building APIs,
just in general, my co-founder

just built a bunch of APIs.

I've done it throughout my career.

We found that it was hard.

To protect that API,
however that might be.

Whether it was through giving people
API keys 'cause you want them to be

able to interact with it or rate limit
that API endpoint for some reason, or

it was just a bunch of things that you
don't think about until you've already

built the API and then it's like, oh,
I need to do this and this and this,

and there was no easy way to do that.

It was all or nothing.

It was, you need the entire gateway to
do a one API key for a user, or you need

to, you know, do some sort of ridiculous
amount of work to make it globally

distributed or whatever it might be.

Or you build it in-house, which is where
we find some people are still doing.

So we kind of had this idea
originally to be a blog post for

Clark and UPS Dash because my
co-founder used to work at UPS Dash.

We were like, Hey, we could just
build a blog post around globally

distributed API keys that would like
used Clark, and then used up dash.

And then basically you link them together
and then you give them an API key and

then you can kind of work with it.

And after about 10 minutes of talking,
I was like, no, this is just a business

idea that I think there's actually
a business idea that we could build.

And then the rest is really history.

We, for the first commit was in June.

The beginning of June, we launched at
the end of June, and then everything

else has been a rocket ship since then.

Lots of users, lots of feedback,
lots of different iterations, lots of

improvements, lots of new features,
you know, all the stuff you kind of do

when you're in a small stage startup.

And then we raised our fund, which
was the weirdest thing I've ever done.

Worked in all these startups,
never seen the other side, and

now I understand how that works.

Yeah, it was really, really crazy and
it was just like you know, let's try us

out and see what happens, kind of thing.

And here we are today.

Mike Bifulco: So the rocket ship metaphor
is definitely something that sounds apt

given the path you've taken to get here.

And I am also living on the the,
the raising money side of the

founder story for the first time.

So I can definitely relate to that.

If you're listening to
this and you haven't.

Raised money for, for a project
of your own at some point.

It definitely changes the way you think
about things and requires a pro, a

project, a problem, an audience that
can hit a certain level of scale.

And so hopefully the rocket ship that
you've now strapped yourself to is headed

in a direction where that scale is really
important really important and also

James: Right.

Yep.

Mike Bifulco: What I'm really
curious about there then is like,

this is a pretty big problem space.

Like building API management is
not a, a you know, a small rock

in project manager parlance.

What was the first cut at this?

Like, what, what was the first
thing you built to prove that you

had something that people would

James: Yeah, so the first thing,
so we decided to go in reverse.

So with all these companies, basically
doing all or nothing, it was do a gateway

and then you can have these features.

We decided that the best idea was
to give people what they actually

wanted, which was just API keys.

If you're a small startup, a small
business, medium sized business, maybe

even a large business, you probably
don't need a gateway because you can

probably handle most of the infra.

If you're using serverless, for example,
like you can scale your infra pretty well

without having to worry too much about
the other features that Gateway brings.

So the first iteration
was API Keys that had.

Per key analytics.

So anytime a key was used, you
had the analytical data that you

needed to figure out, you know,
was it a successful request?

Was it rate limited?

Was it use, succeeded?

Like a few things, but
you could do it per key.

So you could really deep, deep dive into
your analytics as you were building.

And that was the first iteration.

So we had rate limiting keys
that expired by a certain day.

And then we had key, the keys
you could attach data to.

So owner id, metadata was all an option
that you could just attach to a key and we

would return that data if you needed it.

And it was, you could create
a key, you could delete a

key and you could verify key.

And that was it.

That was the first iteration.

It had a dashboard that had very
rudimentary analytical data on it.

And that, that was basically V
zero that we shipped in June.

Then we slowly iterated on things that
we thought people needed at the time.

Mike Bifulco: Yeah.

I can imagine just from that first set
of features quite a bit of value, right?

Possible or at least promise
of value possible for folks.

From everything from just proving that
like, hey, someone is using my API, this

person is using my API over and over is
a good signal for lots of teams building

API products, but also preventing abuse
or things like that and, and looking

at where costs are being driven up.

That's super cool.

How did you, well, I, I guess
you are, someone who's been on

the internet for a long time.

I'm curious like how you found
your first audience for this.

How were you

James: Yeah, so we, both of
us are quite known on Twitter

for different various things.

Like my co-founder is very well known
for like open source projects and

building a lot of stuff, and I'm very
much known for like the YouTube stuff

and Clark and a few other things.

So when we launched the
product, we did a single tweet.

A single video, which were
spaced out like a day apart.

And that really like gave us the I
that actually solidified when we did

the launch in June, that solidified
the fact that we were gonna raise

money because we were getting signals
from other founders that we knew in

the industry saying like, Hey, this is
actually something that people need.

Because the original project
was just a side project.

It was just something we
wanted to build together.

We weren't even charging
people at the time.

It was all open source.

It was just like a fun project for
us to build over like a few weeks.

And when we did the tweet, it
did like 150,000 impressions.

It brought us like 700 users.

Some of those users were just, you
know, people checking out the platform.

Some of them were actual people
that wanted to try the platform.

And then, yeah, just a bunch of
feedback came through that about

like, Hey, this is a cool idea.

This is really something we need.

No one's really done globally distributed
API keys before, like, how does that work?

And it was very much like, oh,
here's the open source project.

You can go and look and
see how we're building it.

And then that brought in some
of our first real users and real

contributions at that point.

Mike Bifulco: I can imagine those
things adding up pretty quickly to

be the signals you would wanna see.

Had you been entertaining the idea of
building this into something larger?

Were you just hoping to get the open

James: No.

Yeah, we were basically like,
cool, this is a cool side project

that we can work on together.

Andreas and I had never met outside
of the internet, like Discord and

stuff like that, and we were both
very happy with the roles that we had.

Like I was super happy at Clark,
he was super happy at Up Stash.

So we used this as more of
an opportunity of just like

working together, collaborating,
building something, having fun.

And even when we were being approached
by VCs, we have a discord message

that we both have the image of,
that we occasionally just randomly

share in our slack now, which is
just us saying like, no, I'm good.

Part-times fine.

Like, I'd rather do this part-time.

I'm happy with my job.

And yeah, we like, we like to remind
ourselves of that occasionally.

Mike Bifulco: It seems like,

uh, the universe had
different plans for you.

Signals like that are hard to ignore.

Certainly.

And I guess, so at this
point, that was last June.

This would be, we're we're recording in
early May, I guess you'd call it of 2024.

So it's been almost a year.

I'm, I'd imagine you've had several
chapters of existence since then.

So tell me, tell me how things sort of
fared since then and where you're at

James: so we're definitely a lot
different than where we were.

The core product still
lies a lot in API keys.

Except from now we have a lot more
features and we're expanding into more of

the API management platform in general.

So we can talk about keys first
and then we can talk about some

of the other stuff we've done.

So the keys, now we, with the
feedback that we've got through

customers and just generalized
people, we've added other features.

For example, now you can do keys with
rate limiting that are cost based.

So.

If you've got like a specific endpoint
that you need to rate, limit cost-wise,

because maybe it's an expensive resource
that maybe it's an AI project and you

are giving keys out, you can, you can
actually say, Hey, this is gonna cost

three instead of the usual one for a
rate limit so that you can kind of push

around and, and make sure that like
your expensive resources aren't being

abused as much as like a cheap resource
where you're just looking something up.

We also have keys that now have.

Usage base.

So you can just say this key has 100 uses.

After that a hundred uses, you
can no longer use it anymore.

Basically, the only way that it
can be reused is if the developer

then goes and does an update.

So it works really well for token
based usage or you know, a monthly

subscription that you get a hundred
uses of anything like that where you

really just wanna limit the amount
that someone can use A key, and then

we've introduced audit logging and
we've introduced better analytics.

So like it's more rich
in your analytical data.

We've added API endpoints so that you
can pull the analytical data yourself

and then build your drone dashboards
or build whatever you need there.

And that's kind of how we're
fit in, in, into the key space.

So that's still the core.

Real core part of UN key, and it'll always
be core regardless if we, you know, once

we get into gateways and things like that,
it'll still be core part of our products.

And then we introduced standalone
rate limiting this year.

So if you've ever had like A-T-R-P-C
route or something like that, that you

just want to rate limit, but you don't
really need public API Keys or something

like that, you can do that with UN key
and it will just be globally distributed.

So it'll be really, really fast.

And you can choose how you want to use it.

So we have two options, which
is synchronous requests.

So that obviously you have to wait for us
to actually respond and say, Hey, yeah,

they're good, or they're bad, or you can
use our asynchronous version, which you

just give up a small amount of accuracy.

So our anchor accuracy is
like 98%, even with Async.

That will just be like, yep,
I, we, we believe this is good.

We assume that this is good based
upon like the data that we have.

So you can have a really, really
fast rate limiting system and

that's fully globally distributed.

It has things like overrides, so if you've
got a specific user or maybe an IP address

that they need higher limits because maybe
you have a deal in place or maybe you

know it's an internal user or whatever
it might be, you can manually override.

In our dashboard and say like,
Hey, if this user comes through,

they have higher limits.

Don't use the usual ones.

And you don't have to
make any code changes.

We'll just say, okay, yep,
this person is coming through.

Cool.

All right, let's give them these limits
instead and let's check against those.

So basically it gives you this
really big amount of flexibility

around how you wanna rate limit.

And those are the big main features that
we've added, like since the beginning.

We've had lots of iterations behind
the scenes of different code base and

like we've changed the way that we
do keys and what providers we use.

And we were originally on servers
and now we're all serverless.

Like we did a bunch of stuff
to like really optimize how

fast we could we could get it.

And yeah, we're really happy
with where we're sat right now.

Mike Bifulco: Certainly, it's a very
interesting set of features because you've

added a few things that very quickly
give any product that takes advantage

of it, like a much more polished feel.

And from, from my perspective,
they're pretty hard to build.

Those are things that
you would probably need.

If I was going to build that for scratch
for an API product, it would take.

Dozens of hours of engineering
time and probably revisits every

so often when I un uncover a bug.

And, and is the kind of thing that
in a world where a AI based products

are becoming more and more valuable
those features are super important.

Like being able to have a customer that
gets advanced access or faster access

is something that's really massive.

That's, that's a, a, a
great set of features.

And I, I like that it's like
fairly minimal, but provides,

I mean, immeasurable value to,
to teams that really need it.

That's

James: Y Yeah.

Our whole focus was really around like
how as a, as a developer, if I get

this product, do I need everything
or do I need specific things?

Right.

And the, the, the problem usually
lies that you get everything,

even though you don't want it.

Then you're like, oh man, I'm
paying for stuff I'm not even using.

Or man, I have to implement this
because of the way that it works.

We are, we are really focusing on like,
Hey, here's a package for rate limiting.

Just use it.

Here's a package that gives you the
entire API use that, and then issue

keys, create keys, do whatever you want.

We want people to have the option to
pick the features they want versus being

forced to use features they don't need.

Mike Bifulco: It makes a ton of sense
and it lets people bite off a, a size

of the product that they want to use
and that makes sense for their business.

And hopefully one of the things I
like about businesses like this is

that as you are, your customers are
successful, you become more successful,

you know, as they get more use or more.

People driving their
product and revenue up.

Then you're, you're benefiting as
well, invariably because they're using

more of on key and everyone wins.

That's, that's aligning incentives,
which is always a good sign too.

I'm, I'm curious to hear a little
bit about your first customers or

maybe your first year of customers.

Like what are the use cases
that stand out to you?

How did you find your, find
your way into people's hearts

as a, a product that they should

James: Yeah, for sure.

I'd love our first ever customer was
a crypto trading platform, which is

like odd and also kind of interesting.

So they were a crypto trading platform.

The name is Premier.

They were building an API and
we launched pricing right as

they were doing their API.

So we're like, Hey, we're
actually gonna charge for this.

Here's the pricing.

If you know, we'll, we'll happily
talk if you're doing big volumes,

thinking like, no one's gonna
do big volumes on this platform.

No one's ever heard of
them before kind of thing.

And they've been our biggest
customer since basically day one.

They do millions of requests a month.

They're pretty popular.

They drive a lot of like, resources
and we see them, you know, spike

when crypto spikes and they
dip down when crypto dips down.

So we're like, we can see when runs are
happening 'cause like our usage will

spike and then it will dip back down.

Mike Bifulco: Sure.

James: they were an interesting
first customer and also just an

interesting customer in general.

Like thinking about how web free is
all decentralized and then using a

centralized system for your API keys
was something that we were still

struggling to wrap our head around a bit.

But yeah, they've always been,
they've been super happy with the

platform since basically July.

And then a lot of AI customers
coming in where they're building,

you know, those AI products that
need either API keys or, or something

to kind of help them drive forward.

And it's been interesting to see
there that a large majority of our

actual customer base that are paying
customers are in the AI space.

So it's usually ai.

And then we have a few Web3 customers,
one of them being the crypto trading

platform and a couple others.

And then we have others like
cal.com uses UN key to power their

rate limiting behind the scenes.

Which is, they're, they're
a newer, newer customer.

They were fairly recent.

And then we've just had some side projects
where they've come in and been like, I

was building an A API and it would've
taken me six months to do this work, but

with you guys, it took me like a week.

And most of that was just like
me spinning up API endpoints and

then introducing on Key into that.

And that, that's basically
been our customer base.

And then people check us out fairly
regularly, like two, 300 people a

month come in and check us out and,
and play around with the platform

and, and see kind of what we're doing.

But yeah, that's been
most of our customer base.

And then we have some other open
source friends that also use us for

their a their API endpoints too.

Mike Bifulco: that's something maybe
that we've glazed over a little bit

here is that you, you have a pretty
interesting open source story as

well that this is not a, you know,
fully private closed source product.

So tell me a little bit about
that, the, the nature of open

source and un key and sort of your

James: Yeah, so un key is a
hundred percent open source.

Every part of our platform is
there, including our landing pages.

The API, there's no trade secrets
that are hidden somewhere.

Everything is available for someone
to go and look at and learn from.

The open source nature of
un Anki was from day one.

We made the decision that if we were
gonna build something, we wanted to

build it with open source in mind.

And people are seeing more and more
people kind of build on open source,

like build successful products.

I mean, if you look@cow.com, they're
a really successful platform.

And the only thing that isn't open source,
I think is just their marketing site.

And we just believe that open
source makes better products.

It makes it easier to do
security checks, right?

Like if you're a big business, you
can just go and look through the

source code and make sure we're
not doing anything nefarious or

we're doing something dangerous.

It makes it easier for people
to collaborate on an idea.

So if they have an idea that like,
maybe this is a cool feature, they

can create an issue and say like,
Hey, I'm thinking about this for Anki.

What do you guys think?

And then we have our community.

We also have our team.

And we can get to a point where an
idea may not be the best idea in the

beginning, but by the time we've all
talked through iterations of it, we've

come out with this next feature or an
extension of a feature that could really

be useful for more than just one person.

And we, we just found that we just
wanted to be as open as possible.

So even internally as founders,
we are transparent with our team.

So they know exactly what's happening.

What are we doing?

What kind of deals are in the
pipeline, what deals have fallen

through or are successful?

And then again, like things like
revenue and all that kind of stuff and

how much money we have in the bank.

All that stuff we're
completely open about.

And it just makes for better overall
feeling every day knowing that

nobody is in the dark and there's
no secrets that are being hidden.

And we believe that
works for software too.

Building that way.

Makes it really easy for
someone to come and learn or, or

contribute or whatever it might be.

Mike Bifulco: Clearly it does.

I think you've established as, as
a pretty impressive product and one

that people are providing value to.

Very quickly while we've been chatting,
I pulled up your GitHub repo, and I know

this isn't exactly a direct litmus, but
it looks like you've currently got over

1400 pull requests merged into the product
between, you know, now and its inception.

Which is, you know, from any number
of, of contributors you know,

between internally and externally.

But one of the things I think
that comes along with that is you

end up having to do almost like
crowdsourced product management too.

And, and you touched on that a little
bit, but how, how do you balance,

like taking feedback from open source
contributors versus paying customers

versus what your team internally thinks

James: Yeah, we spend a lot of time
talking about this just in general,

so like being such a young company,
being less than a year old, it it.

A lot of our direction comes internally
around we believe this is a feature

that people want or need because
that's something we want or need.

Right?

Like it's one of those things
where you're like, I'm playing

around with AI and it, wouldn't
it be cool if we had this feature?

And, and so over the ti over the time
period, we've had people ask for feature

requests and, and whether that's through
open source or being a paying customer.

And it's just a fine balance of
deciding whether or not it's for the.

Greater good of the product, or is it
a very niche thing that somebody needs?

And if it's more niche, we try and pry
a bit more into what they're trying to

achieve because it may be something we
already have on the roadmap, but it's

like, you know, phrase in a different
way or, or what they're actually asking

for is not what they really want.

And we found over time that we, we've,
we've really got a fair balance there of

like, Hey, this is a cool feature, but.

Like, here's five different
edge cases where this probably

wouldn't work properly.

And like, what would you
think about this instead?

And kind of talking to
the community in general.

And that's been really good for us.

I think it's a tough challenge and
I think anyone that has an open

source project, it's just tough
to be like, we are not gonna build

this, or we are gonna build this, but
it's gonna be six months from now.

But if you wanna open a feature
request and like do it yourself,

like here's how you can contribute,
and it, it's just tough.

I think it's just one of those things,
you just gotta balance it the best

you can and decide what's better for
the greater good of the company and,

and the business side of things too.

Mike Bifulco: By nature you have a
lot of constituents through opening

the product up, and it's usually a
good thing to listen to feedback from,

you know, customers and people who
maybe just want to use your product

aspirationally, but are blocked by,
you know, something not existing.

But definitely also certainly
have to balance this out as like

it needs to run as a business and
be a functioning business too.

There's, there's.

Well, almost the curse of open source
is that when you're successful,

you start to get a massive amount
of signal to noise problems.

But the benefit of it too is when you
strike the balance, like your, your

product also a little bit maintains
itself or maybe grows itself.

And, and your team can, be more open
about that, you know, like, let's

have a discussion about this feature
before we go and implement it.

And it sounds like from your ethos
of keeping everything, you know, open

with the team and, and being sort of
approaching the problem with open arms

you can ask a few whys, like, okay, you
want this very niche feature, but I.

Why, you know, and why to that and why
to that until you get to do something

that maybe is a little more generic
or you know, I'm sure in, in some

cases you're ending up saying no, but
you've had the discussion and hopefully

publicly too, so everyone can kind of
learn from it and chime in as well.

I'm, I'm I'm, I'm impressed how
quickly this has come together.

Like it feels like you've got a a
timeline that makes no sense to me

because it feels like you're traveling
through time but also a product

that feels really, mature, right.

Given that like there's a lot of polish
in what you've built and a lot of really

thoughtful touches across your site,
across documentation, things like that.

So I'm, I'm interested a little bit in
hearing about the developer experience of

the product and from a couple of angles.

So first why don't we start with,
tell me a little bit about like,

the implementation side of this.

I, I have a, a AI based product
and I want to use un key for

you know, managing my API keys.

How do I get started?

James: Yeah, so it, we've tried to
make on key as easy as possible with

the smallest amount of implementation.

So if we just use TypeScript, 'cause
it's probably the easiest example because

we have like official SDKs for that.

Essentially the idea is you sign up
for an account through, through on key.

And we give you an onboarding
experience depending on what you want.

So if you are looking for API
keys, we, that's one onboarding.

Onboarding experience.

If you just want straight rate
limiting, we give you a different one.

But when you go through that
experience, essentially what you get

is something called a root key, which
is basically the keys to the kingdom.

You can set it to be able to do
a bunch of different things, but

the idea is that root key gives
you the ability to create a key.

Or update a key or delete a
key, whichever one of those kind

of operations that you need.

So the idea would be that you have an API
endpoint somewhere that basically just

says, you know, when a customer clicks
this button, create a key for them.

And it's just a simple, a simple
SDK call to like un key client dot.

Keys create and you give us some
sort of information based upon that.

So it's just like our API ID and
then maybe you need a user id 'cause

you wanna reference it to someone.

We give you the ability to do that
and then we return you two things.

The key itself and a key id.

And the key is only ever returned one time
and we'll never be able to retrieve it.

We'll never be able to
show it to you again.

Basically.

It's just a one time thing.

'cause we, the way that we
store the keys securely.

And in that point you give it to the
customer and the customer now has this

key that whatever it might do to interact
with your system, then we just have

another piece that's called verify key.

And Verify key takes two pieces.

It's the key itself and then the API
ID that you want to verify against.

And then you just make a call to
that and we'll tell you whether

or not they should have access.

So if you've got rate limiting,
for example, and maybe

someone's really hammering an
API endpoint and they've used.

More than you've said that
they can use for rate limiting.

We'll actually return back that you
sh basically it's a true or false

statement and we'll just return false.

And then at that point you can
handle it however you want.

You can reject them, you can
tell 'em to calm down whatever

you want to do through that.

And that's basically
the way that it works.

And then if the user is using something
like token, you know, usage based, and

they're like, oh, hey, this person's
actually upgraded their account.

I need to update the key.

We have another call that you can update
key and then just give us whatever

you need to update, whether that's
maybe their rate limits are higher

now, plus they are, they, they get
more usage or whatever it might be.

And the way that On Key's built, it's
built on a really simple rest, API.

So if we don't have an SDK for it, the
rest API is really, really easy to use.

We have an an open API spec.

So if you want to use generator to
generate all the endpoints you can.

And we've made it as easy
as possible to get started.

In theory, if you wanted to do a next GS
app, for example, that had this a like an

API endpoint, and then you need to verify
the key beforehand, you could probably

do the entire UN key implementation in.

Less than 20 lines of code,
including verifying your keys.

It's very, very simple.

We've made it as simple as possible
and it's really easy to get started.

Mike Bifulco: I am sure many of our
listeners are thinking about the

subtleties implied by everything you've
just said with a small amount of code.

20 lines of code, you know, for next are
probably similar for other platforms.

You've just described quite a bit of.

Work that is not easy to achieve, right?

It's like a very humble description of
a super cool product, securely issuing

and reissuing keys and mapping them to
access rights and rate limiting and all

that is a crazy amount of scope and like
a very cool thing to be able to just

kind of you know, excuse the slightly
sarcastic, joke, but like NPM install

and have, you know, your API managed.

Like, that's wild.

That's, that's such a cool thing.

You also touched on something before
that I think is really interesting and

maybe subtle if, if folks listening
haven't touched on this or needed to

implement this for themselves, but
usage-based API usage when it comes to

pricing is a really challenging problem.

And for the reasons you were saying
before synchronous versus asynchronous

is a really interesting challenge.

So maybe I'll set the scene here and I'm
curious maybe you can describe like the

problem space and why it's important.

But again, let's say I'm building
an API product and you've,

you've paid me for access to it.

So you've given me, you know, 10
bucks a worth of API usage, and

I have a usage based API call.

There are a few things that
can happen as you're, you're.

The, the value of your credits
with me drain having to do with

like race conditions and depletion
and refunding and all of those

sorts of things with my account.

So how do you convey all of that
information to end users when you're

James: Yeah, so it is very hard to do if
you're not using something like UN key.

'cause usually it's like, oh, I
have to use my database to basically

store a token number that then I
decrement and increment, and then

I take the risk of like my DB being
slow and now they've burst through

and now they're in negative numbers.

Like how does that all kind of work?

So with UN Key, we basically give
you the ability to, to put in a

number, whatever that number may be.

Let's say they pay for
a hundred uses for $10.

At that point, you have a few options
with un key to decide how you want

to handle the future of that key.

So for example, let's say they decide,
oh, this product's terrible and I wanna

refund, and you give them a refund.

They technically still have access
to that key when you do the refund.

And so what we can do is we
have a few different ways to

kind of basically disable a key.

So you can do it right
through the dashboard.

So if you're still manually billing and
you're manually doing that, you can just

go into the dashboard, find the key that's
linked to that user and disable it, and

then they won't be able to use that.

If you are doing automation where,
let's say they wanna refund and then

you basically scrub their account.

You can use either the delete
key, if you know for sure.

They're never, ever gonna come
back permanently, delete the key.

And now the, the key has become sort
of, you know, unusable or you can update

their key and just say it's disabled.

Maybe they'll come back.

And then what we do to protect
you from things like race

conditions and things like that
when you're using our key system.

We don't let you do an
asynchronous request.

We like, you have to wait
for us to actually respond.

You can't just be like, I'm just gonna
assume everything's fine and continue on.

And that protects you because
one, it basically stops your.

Anything else being processed
until UN key responds.

And because of the way that we work
behind the scenes, essentially what you

get is the correct and valid number.

Like we are heavily cashed.

We know exactly what the number is at
the time when the user makes the request.

So there's less of this worry of like,
I have to wait for my DB to respond.

Oh, they've burst through.

There's no way for them to actually
physically burst through that request.

And then what you can do is like
once they deplete and get to zero.

Maybe they wanna pay you $10 more and say
like, oh, I want another a hundred users.

This is super cool product.

Well, you can do the same thing.

So you can either manually
just do an update call and say,

give, update remaining, and
say, give me a hundred more.

Or if it's like a monthly
subscription, we have the ability to

refill automatically once a month.

So every month, if they've billed,
you can just basically say, every

month, just unie, handle this for me.

I don't care about it.

Just handle it.

And that makes it really, really easy.

And then the final piece to the puzzle
is in the very near future we, we will

have web hooks for you to hook into.

So we can tell you this user has done this
much usage if you're doing usage based

billing on your side, and we can send that
to you in specific timeframes or usage

base or however you wanna really do it.

And so that you can bill
via like 30 day invoices.

So like, let's say it's similar to us,
where once a month you get a bill from

us and we tell you how much you owe us.

You can now do that with UN Key and
not have to worry about implementing

the entire thing on your stack
and use whatever billing partner

you want, Stripe, paddle, lemon
squeezy, whatever it might be.

Mike Bifulco: I suppose that
means somewhere under the covers

you're probably using UN key to

James: Oh yeah.

Un key is built on un key.

That is for sure.

Yeah, we, we everything that
we do is powered by un key.

It's always the classic trope of
like, you know, Clark is using

Clark behind the scenes, right?

Like, if you go to Clark's
dashboard, you have to log in

with Clark to get into Clark.

It's the same thing for us.

So when you.

Bill when you like create your
workspace and you create your API

and you create that first root key,
that root key is then using UN key

to actually build you a root key that
you then use for a specific account.

It's very similar to that.

And then like when you do a
verification, we verify that

key against one of our own keys.

Mike Bifulco: That creates, a paradox
of its API keys all the way down,

but that's, that's a great way to
build the product, making sure that

you're close to it and using it.

I I also wanted to talk a little
bit about maybe the other side

of, of your product in DevX.

And particularly with your background
in developer advocacy it feels

like you've done a really good job
of, you know, making a splash and

socializing this because of the
reputation you built for yourself.

But I'm curious what what other I.

Benefits your work in developer advocacy
has, has brought to engineering a product

and building something that actually used.

And maybe the additional caveat that
I'll add there is that I, having worked

in developer experience for, for a while
myself, one of the things you hear,

especially while interviewing is that
developer advocates aren't engineers.

Like, don't build products,
can't build products.

And, and I think that.

Obviously is a, a trope and something
that has a lot of faults to it,

but it's something that also just
doesn't get talked about, right?

Like you have jumped from the world of
talking about building for developers

to building for developers, and now
you've got a product that's out there.

So yeah, tell me your secrets, man.

I wanna hear it all.

James: I, I think, yeah,
that classic trope of like.

Dev advocacy never can build a product.

Is is, is something that I
think was probably true when

dev advocacy was new, right?

Like it was just like more of
an educational kind of part

than it was about anything else.

And less about being involved in like
moving a product forward or pushing a

product forward, or helping engineering
or whatever, helping customers, and, and

because my development background was way
before I was dev advocacy, they gave me

some of that skillset immediately, right?

Like I could build a product
and don't have to worry.

But I think having the background
in dev advocacy and being unafraid

to be open is something that's
scary for a lot of founders, right?

Like you see these cool products
like one time and then you never

see or hear from them again.

And then like two years later you find
out, oh, they, they shut the doors

'cause they couldn't get another round
of funding or they just couldn't get

traction in the space that they're in.

And it's because you never see them
actually doing anything on either

social media or blog posts or being on
podcasts because they're afraid that

whatever they put out in the world.

That's the be all and end all.

Like it's gonna be cemented in history
and I can never go back on what I've

said or I can never change my mind
or I can never improve the products

because we've said this thing.

We took the opposite approach was
just like, just even if we're in

the middle of building sand, just
post it on social media and say

like, Hey, this is coming soon.

Or Hey, we built this and it's like
in alpha, like, love some feedback.

Then doing podcasts and, and, and
blog posts about things that we

have opinions on is a huge thing.

'cause you know, the internet is
full of people's opinions and having

our own as we've built this product.

Like we have a blog post that's about you
UIDs and how like people will use them

wrong and like, this is how you should
really try and use them and here's why.

And that post is still one of our
biggest drivers to the product.

And most of it comes from a place of
like, either, wow, this blog post is

amazing, it's a really great read, and
now I wanna know more about products.

Or, these guys have no idea
what they're talking about.

They have no experience.

Like, they're clearly wrong and like,
I have a really bad opinion about this.

Right?

So like you have these two
opposing opposite ideas and,

and, and we just don't care.

We're just like, cool.

Thanks for coming and checking us out.

Like.

That's your opinion and you know,
you rightfully can have that opinion.

And building all those things
together kind of really helps kind

of cement the products as a whole.

And then having this engineering
background and, and not being afraid

to like be wrong about something.

I am nowhere close.

My ability is nowhere close to
my CTO's ability in engineering.

So there's times where I'm
just like, ah, I just put this

together and see what happens.

And I push PR up and he is
like, what are you doing?

Like, now this makes sense?

And like, okay, well
let me go and try again.

Like, kind of thing.

And not being afraid to,
to, to learn as we go.

Because a lot of the stuff that
we built, we had no idea what

we were doing in the beginning.

We were like, we think this is gonna
work, but we won't know until we try.

And, and just being unafraid of that.

And I think dev advocates are
the perfect people for that too.

A lot of the time, you spend a lot of
time building content or education or

talking to people or whatever it might
be, and there's a big chance that whatever

you put out in the world, either people
aren't gonna like, they hate the, like

they really love it, it's not very good,
or it miss them up completely and being

able to like get back up and be like, oh
well, like we did our best with that one.

Let's move on to another post or
another video, whatever it might be.

That's the same I attitude that,
that you need to have, if you're

gonna build a product, it's just
like, this might not work, but let's

give it a shot and see what happens.

Mike Bifulco: I love that, that's
like a masterclass in both developer

advocacy and startup founder school,
you know, kind of slammed together.

There is I feel like the, the, one
of the, the hidden superpowers of

developer advocacy is learning to embrace
opening and working in the open and in

public and, and benefiting from the.

Internet's magical superpower of
every time you share something

online, someone smarter comes along
and tells you why you're wrong.

That's fantastic.

Like as, as long as you look at
that as, Hey, I can learn from this.

That's, that's a superpower,
that's a skill for sure.

And I think a lot of founders, I, I
mentor a handful of startup founders

and kind of give advice to folks who
are like early on in the journey.

And one of the things that I
think people miss out on a lot.

That a lot of building a product,
especially a developer focused product,

is that you've gotta love building it and
rebuilding it and iterating and like every

step along the way is part of the thing.

It can't just be like, I did it once.

It's done.

It's never done.

And that's, that's the fun part, right?

You've gotta learn to love that too.

It seems like you've married
the two together really well,

and certainly your team has too.

We actually haven't really talked
about your team much apart from

yourself and your, your co-founder.

But how big is the team right now?

What, what are what's the scale you're at?

James: five people total,
including myself and Andreas.

We have two engineers and then one
design engineer who does both design

and also a lot of front end work for us.

Mike Bifulco: Yeah.

Got it.

Yeah.

A small but mighty team building something
that's really, really pretty wild.

Are you expanding at the moment?

Are

James: are not hiring right now.

We just hired just recently,
actually April tonight,

design engineer came on board.

So we'll probably be hiring again core,
kind of close to the end of the year.

We definitely don't wanna expand too far,
too early and then be like, well, well

I don't know what you can do right now.

'cause we're like, we're all doing these
tiny pieces, you know, or the, you know,

the, the scary worry of being a founder
is like, what if we run out of money?

I don't wanna have to tell you.

Sorry, like you just got a job
with us now we have to let you go.

But yeah, we'll definitely be
hiring kind of close to the end

of the year again which is when
we started our first hire round.

So probably like October, November,
we'll probably start hiring again.

Mike Bifulco: Yeah, that's great.

I will make sure by the way, to include
links to UN Key and to James and to

all of the social, everythings in
the show notes, as well as actually

the blog post you mentioned before.

Before I let you go, I'm curious to hear
what's next, like, what are you thinking

about, what's the next exciting feature

James: Yeah, so we have a
couple of different things.

So we're currently working on
a special project for AI users.

Essentially the idea is
semantic caching for ai.

So the idea is that we can save you
both money and also just speed and

latency by using the same tech that
we use behind the scenes but give you

the ability to, to really have some
really nice responses if it's something

that's already been asked before and
you don't have to go and ask open AI the

same thing or some variation of that.

We're working on that right now.

That should be released probably in June.

If all goes to plan.

And that will be our first real, like push
into kind of the gateway esque product.

And then the really big thing in the
next probably 12 months will be gateways

in some variation, but gateways that
developers can use instead of gateways

that you need a whole DevOps team for.

We wanna make it really easy.

A few clicks, gateway, or here's an
API call and now I have a gateway.

That's the idea.

We're pushing towards the same
devex experience that you get with

the rest of the UN key products.

And then we just have a
few more things coming.

Like we have a cash package coming
that's not really related to On Key,

but is where we can help you do a lot of
like the heavy cash work in CloudFlare

workers and things like that that we use.

Now we're actually building that
out to be just a standalone package

that you can use for whatever you
want and don't have to use on key.

And then, yeah, it's just some generalized
improvements, more analytical data for

you guys to ingest and play around with.

Ingestible audit logs is coming so you
can actually push stuff to on key and

then do something with it afterwards.

Lots of things just to try and
help API development in general

Mike Bifulco: There's never any shortage
of new features to build, especially

when you've got an audience of

James: Yep.

There's never, there's never a time where
we're like, Hmm, what should we build now?

We definitely know that there's things to
build and, and we're happy to build them.

Mike Bifulco: james, that's
a really good spot to be in.

I appreciate you coming to hang out.

Last thing where's the best
place to find you online and

what's the address to find UN

James: best place to find
me is probably Twitter.

It's where I spend most of my time.

It's just James R.

Perkins.

You can find me there.

And then for Un Key, you
can now find us@unkey.com.

We just launched the new site
that you see today, which will be

whatever anybody looks at right now.

We launched that a couple of
weeks ago with un key.com domain.

Mike Bifulco: it looks great.

Congratulations on the
launch James Perkins.

I am thrilled to be able to
talk to you and super excited

to hear about your story.

Please come back anytime when you've got
launches to chat through or things you

wanna ask the community, or if you're
just interested in getting yelled at

about open API specs, I can do that too.

Thanks so much for joining me today.

I really

James: Thanks, Mike.

Really appreciate you.

Bye.

Mike Bifulco: Soon.