Apiable is building an API Portal service that helps API teams to create, secure, market, and monetize API products. In this episode of the podcast, Apiable founder Allan Knabe has a chat with Mike Bifulco about building a great api product.
- Allan Knabe
- Apiable - Every API is a business
- Careers at Apiable
- Pirate Weather
Creators & Guests
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: Hi friends, and
welcome back to APIs you won't hate.
My name is Mike Biko.
I'm one of the co-founders
of APIs you won't hate.
And of course, podcast co-host
and occasional friend of Phil's.
We get to catch up and talk
about API stuff when I can find
him wherever he is in the world.
But today I'm excited to sit down
and chat with a new friend of mine.
I'm here talking to Alan Kaba about
what he's building with API bull.
And really excited to hear your story.
Alan, thanks so much for joining today.
How are you?
Allan Knabe: Hi, Mike.
I'm doing very well.
Thank you.
Thanks for having me on the show.
First of all.
Mike Bifulco: Of course.
Yeah.
It's a pleasure to have you here.
I would love to to to hear a
little bit about you to start.
Gimme your, the history of how you
got to what you're building today,
and then I want to hear all about API
Allan Knabe: Okay, cool.
Yeah, I'll skip the early years 'cause I
don't think they'll interest anyone, but
Mike Bifulco: Sure.
Allan Knabe: I, I guess, you know, the,
the origin is like starting at university
saying information systems, which is code
word for not very good at programming.
I think, you know, everyone else were,
you know, software engineers, but I
would write code that was like one page
long or something like this, and then
a real software engineer would come
along and say, okay, you know, I could
write that same thing in one line.
Right.
And, kind of like the, the, the
penny click that I needed to
be a little bit more diverse.
So information systems where,
where I, I kicked it off
with my, my computing career.
And yeah.
From there I, I kind of started off
with an Oracle consulting company in
Birmingham, which is, you know, basically
where I'm from in Birmingham, uk.
And great Years had some like really
good fun in like these, like very
small teams of like 10 people.
It's where I really love to, to be, you
know, where everyone's working hard and
you can see like what you're achieving.
So good fun there.
But ultimately I left for a
bigger company, Fujitsu computers.
Mainly kind of.
Backend development type tasks and
Oracle databases and all this kind of
stuff that were, you know, popular in
the early two thousands before moving
on to being a Siebel consultant.
So, I dunno if anyone still knows
what Siebel is, but Siebel CRM was
really big in the two thousands.
And
Mike Bifulco: Sure.
Yeah.
Allan Knabe: yeah, I, I, I think I.
Mike Bifulco: while since
I've heard that word.
Yeah.
Allan Knabe: Yeah.
Yeah.
Siebel, it was massive.
Right?
And then Oracle bought them and kind
of, they disappeared a little bit, but
there are still some projects out there.
But I kind of, I san about 10
years of my life into Siebel,
I'll never get back somehow.
Right.
It's, it's, I don't know for people
who don't know where it is, it's,
it's basically before you had
Salesforce, you had Siebel and.
Instead of programming, they gave
you like this tools console, which
basically just toggle switches
and you toggle them on and off.
Right?
And it would just, you know,
activate feature toggles in code
that you could never see, right?
So like this black box and you had
no real idea what was going on.
And sometimes you would just
kill performance, right?
Because you were doing some sort
of outer join in behind the scenes.
So not nice stuff if we're being honest.
So my API story kind of started
when I, when I left Germany.
So I was in Munich for 10 years.
And I went to Swisscom in Switzerland.
So Swisscom is like at and t
basically, but in Switzerland.
And joined the API team.
So I, I moved across to, to
doing APIs and, well, it was
a world of difference, right?
The, the API team, you know, was really
young, fresh, cool thing to be doing.
You know, we were having like hackathons
and it was really about that genesis about
10 years ago on now of like when the, the
API started to really come onto the scene.
It was a really, really cool
time to be working in APIs.
Really
Mike Bifulco: Yeah, that's an
interesting time to be getting into it.
There was sort of this like renaissance
of people kind of having this realization
that they can go in and grab things
from services they want and like kind
of assemble products from, from whole
cloth based on just little bits and
bobs of services round and about.
And that's de definitely where the
modern conversation of how do we build
good things and like how, how do I
behave properly as someone consuming
or building these APIs started?
That's really cool.
What interesting timing.
Allan Knabe: Yeah.
Yeah, it was really cool.
And it was like, you know, I
think Apigee pre acquisition
by Google at the time, right.
So it was still in like
startup mode as it were.
And, you know, we got to go
across to San Jose and, meet
with a and go to the, I love APIs
conferences and all of this stuff.
And it was yeah, it was a nice
time, really great time to be
getting into, into the APIs.
I think nowadays we're maybe a little
bit more mainstream, although there are a
lot of API companies coming out now, like
startups, like my company, a pable, right?
We're we're startups and we're
entering this space and kind of
sitting over the top of what these
more traditional players are doing.
Mike Bifulco: Yeah.
And you know, that's a perfect segue.
So what's the elevator pitch for a pable?
Allan Knabe: Okay, well the, the
elevator pitch for a pable I mean if
we, if we think about when we came up
with the idea, it was also at Swisscom.
So my co co-founder is a, a
clever guy called Alexander Ham.
And he was working.
With me in the, in a squad as it
were, we had like this Spotify
squad concept going again, it was 10
years ago when it was mega popular.
And we led a team of like
10, 11 developers together.
And you know, we had a
great time doing that.
It was amazing fun.
But one of the challenges that
we had is that we were asked
to create new digital products.
So API products for Swisscom, so
think like payment services and.
You know, the precursor to like
WhatsApp and things like this.
That's what we were trying to do.
But we found that the tooling
that came out of the box for
developer portals was pretty poor.
So we were using the one that came
from apg, which was this Drew Pal PHP
solution that, you know, we didn't really
like it, but we used it for a while.
And eventually no one kind of patched
that solution and security said,
okay, it's just too vulnerable.
You have to take it down.
So a lot of companies
did that at the time.
And what did they do?
They built their own API portals, right?
That's what we did.
Right.
You know, we spent like, I don't know,
like two years, like making the API
portal and did a really good job.
Fantastic.
But it was kind of that feeling
that the, all this energy from
mankind is going into building.
API portals there are bespoke.
And, and really the amount of features
you want to build for an API portal.
If you're building it
yourself, it's limited, right?
You can only get X features in there
before someone says that'll do.
And it's basically just getting the API
key sticking some documentation on it.
But we wanted to do a
lot more with it, right?
And, and that's kind of like where, where
we went with API all is saying, okay,
well, treating APIs as products right
is one of the biggest things that we do.
You know, I really believe
in API product management.
I am an API product manager
and see the value in that.
So we really try to bake that
into API able, and that does go
hand in hand with monetization.
Not every company wants to
monetize, but those that do,
can do it with a pable, right?
So it's, yeah, it was that kind
of like genesis moment of saying,
okay, if everybody in the world
is building these API pools, why
don't we just build one that's like
great and provide it as a service.
So that's where we got to.
And I, I think what we're really
noticing as well on the, again,
more on the enterprise side, is
the amount of organizations that
have more than one API portal.
It sounds a bit crazy, but if you're
as an organization, you've done some
acquisitions and you end up with like
multiple technologies, so, so imagine
a situation where I think you've
got MuleSoft and you've got Kong
and you've got Apigee, for instance.
Sometimes you'll have three portals.
My, my previous company, Connor, at one
point, I, I'm glad to say it's not the
case anymore, but we had, I think Dev.
dot and we have develop dot and
we have developer dot, right?
And you've seen some, and
you've seen banks as well.
You see this very similar situation as
this, like different factions within the
organization using different technologies.
And the technology assumes that
you will use our portal and we are,
you know, the only company in the
world and, and you know, so there's.
Cross usage there.
So that's one thing that, that we kind of
identified and we said, okay, well we're,
we're technology agnostic then, right?
So you can have Kong and MuleSoft and
Apigee in your organization and just go
ahead and connect the gateways in, right?
So as a developer, we're making developers
life much easier that they don't have to
then log into three different API portals.
You have like.
One unified portal where you can
just get everything you need.
And the token management should work
in the same way across, across all.
Mike Bifulco: Sure.
Yeah, I think that's, it speaks to
an interesting thing that happens
in product development on any scale,
but certainly at enterprise level.
I would imagine pick, pick, I mean,
if you're listening to the show, pick
any like, fortune 500 sized company
that's not primarily a tech company.
Imagine the size of their dev team
and the amount of stress they're
under to deliver things probably in an
underfunded under timelined sort of way.
They will put as many resources as,
as they're able to, I'm sure, to
developing the API itself, right?
Make sure it does the things it
purports to do, right in the languages
that they, they are comfortable with.
And when it comes time to make that
thing available for usage there's
probably a very rushed moment where
it's like, ah, okay, now we need
to expose this thing to the world.
So let's,
what's the simplest way to put up a, a.
A developer portal where someone
can go and now consume our APIs.
And I think that's maybe the curse of
product development is it's like you
spend so much time building it, and then
the last bit of pushing it over the line
often is where things start to fall apart.
And if you've, I, I mean lots of our
listeners are probably familiar with
this, but if you've tried to consume an
API from, like some random company Inc.
You know, from, from wherever in
the world and you've come across a
site that looks like it was built
in, you know, visual studio.net in
Allan Knabe: right.
Mike Bifulco: you've had this feeling.
Exactly.
So, so that's really interesting.
And so, I mean, it's, it's a core
problem that, that a lot of these
product teams face and a lot of
API devs have certainly dealt with.
I'm curious, how, how long
have you been working on this?
You said it started when
you were at Swisscom.
What's kind of the timeline for that?
Allan Knabe: Yeah, we kind, we,
we carried the idea from there.
And it was really when I, when I
left Swisscom I, I moved to Finland
to Helsinki and started working with
an elevator or actually I think they
call themselves a people flow company.
Right.
To, you know, be more modern.
Right.
I guess, you know, but
they're an elevator company.
Yeah.
And when I started seeing, okay,
the same problem there, right.
Different technology, but you know,
multiple gateways and, you know, not, you
know, no one providing a good API portal.
That was kind of the, the point
for me where I said, okay, I need
to quit my day job and do this.
Of course, I quit in February, 2020.
I mean, the best timing
in the world, right.
Mike Bifulco: Yeah.
Allan Knabe: Yeah, I, I, I, you know,
of course, you know, coronavirus
was, was around at the time in China
and I just thought, okay, you know,
that won't be a problem for me.
And I quit my day job and
by April I was babysitting.
'cause we have three children,
so my wife was working and I
was just looking after the kids.
So that was good fun.
But that was kind of like
the genesis there in that.
In 2020 when I formed the company
and basically was looking around
for potential customers and we
found a great company called bmo.
They sell bicycle insurance.
And what they're trying to do is embed
their APIs within the shopping cart
of you know, larger bike companies.
So you can go like specialized
or con or someone like this.
See an insurance offer within
the shopping cart process, right?
So, so we've helped them with their
APIs and getting them exposed so that
they can get more partners effectively
and get more customers that way, rather
than relying upon someone buying a
bike and then thinking, oh, I wonder
if I should insure this thing, right?
Because that never happens, right?
But if it's in the shopping cart
process, you're like, oh yeah, I can
do this 50 bucks a month, whatever.
And put it in.
So, so yeah, so we, we built like
out the first version for bmo, which
is kind of like a small and medium
sized company which is good 'cause
we could do like, you know, the base
and work with them to get that done.
And so we were building
it like basically 2021 22.
We got funding in 23.
We basically perfected the products
and then we have a bunch of customers
working on it from like smaller startups.
We have a startup in Canada
that's called pirate weather.
And they've got now, I, I guess it's
something like 8,000 developers using
the portal, which is, is amazing.
Yeah.
But told us something about scale
within the product as well, so
that gave us some work to do.
So it's pirate weather.
Yeah.
And
Mike Bifulco: Wow.
Allan Knabe: so, so we basically
we're, we, we've onboarded these guys.
And that, that's where it kind of
came in and we've been working on
it for, yeah, some, some years now.
We've probably been working
on the product too long.
We should have, you know,
gone in, out the door sooner.
But we, we wanted to make it like
really feature complete, so wanna make
sure that it has like the, you know,
great API products that are monetized.
And one of the features we just
added, actually, that I really
wanna bring out is the API catalog.
Which is more like an
internal developer thing.
'cause we came across some, quite
some customers who have so many
APIs, like thousands of APIs, and are
cataloging them in an Excel sheet.
So it must be a developer working in
an organization like this bank we, we
were talking to in, in South America.
And if you wanna know what APIs the
company has and and which one to
use for any specific case, you gotta
be searching an Excel sheet right.
No developer in the world wants
to search an Excel sheet, right?
Nobody wants to search it, so, so we
put together this API catalog, which
effectively, because we connect into
the API gateways, we can retrieve
a list of all the APIs available
in that gateway and then list them.
Now if you've got like just one API
gateway, maybe that's not so useful.
But we find that especially in
enterprises, they can have like up
to a hundred API gateways or more.
Right.
You know?
Especially if they've got lots of regions,
again, different technologies coming
into Play Kong versus Apigee and so on.
But having like this
one unified API catalog.
Is being really helpful.
It's like one of the features that we
didn't intend to build, but, you know,
it was the most requested and it was
actually kind of easy for us to build
since we already did all the integration
work to the underlying API gateways.
Mike Bifulco: Yeah, I think that
fits pretty cleanly into the, like,
problems worth solving that a lot of
certainly enterprise scale companies
will never dedicate time to you
know, if, if the thing is working
and someone can find it in the Excel
spreadsheet, like dust it off, problem
solved, we'll call that good enough.
But I'm, I'm sure, especially if you've.
Been able to build a solution that's
reasonably plug and playable from
there and it makes life better.
There's clear value add, especially if
they see, you know, API usage, picking
up or whatever monetization, picking
up whatever the metric is there.
I think there's lots of
ways to measure that.
So can we talk a little bit about
the, I guess the like major features
that API will provides today?
It sounds like there's obviously the,
the gateway product and the catalog.
Is there a documentation angle as well?
What else are you providing right now?
Allan Knabe: Oh yeah.
Yeah.
I mean the, the core developer
experience is something that was
always very very important to us.
And, and so there we're actually using
something open source called rapid Doc
Web that I, I guess we can get to that.
In more detail, but we're using
Rapid Doc web to, you know,
put the API specifications up.
We were going to build our own
documentation tool, but then
we found this and said, okay,
look, it's absolutely fantastic.
We'll go ahead and use that.
So, so we put that in there for,
you know, developer documentation.
We do some nifty things like synchronizing
the documentation from the API gateway.
Which is nice.
So you can update it on the documentation
on the gateway and you get it synchronized
across into your API products.
Some of the other things we do as well
is we, we really tailor the documentation
for the subscription you are using, right?
So sometimes you, you see like
an API specification, which
is, I dunno, 50 pages long.
And you have to try and work out as
a developer, you know which parts
of it are relevant to like your use
case that you should be using, right?
And so what we said is that if you
can say, okay, in this particular
API product and in a particular
plan, because you might have like
a small, medium, and large plan.
And in the large plan, you
might get more endpoints.
More methods, right?
And you want the documentation
to reflect that, right?
So you can switch between these
different plans and see, okay you
know, oh, okay, I'm not getting a
post possibility on this endpoint,
but I do get that in the large plan.
Right?
And so making that really clear to
the developer what, what they're
working on with the whole, you
know, triad functionality is
a triad console there as well.
Once you've subscribed to an API,
the API credentials are automatically
assigned to the documentation.
So you can just start pressing
buttons and it will do, you know,
API calls for you and so on.
So, you know, trying
to help the developer.
And I, I'd say, you know, they're one
of the key things as well is that we
noticed, we noticed working at, at
Swisscom and elsewhere as well, is
that the decision maker to use an API
is not always the developer, right.
Developer may be the one like signing
up using it, but we really feel that if
we can get the decision maker to sign
up for the API and put their credit card
in and sign any contracts and go for
the approval process, and then do invite
the developer in a at the correct time.
That's much more useful for the
developer because, you know, no
developer likes waiting for approval.
Right.
It, you know, you, you go, you go to a
site, you sign in, you know, I wanna use
this API, the worst thing a developer can
see is, okay this is pending approval.
Yeah.
We'll get back to you when John comes
off his vacation in two weeks time.
So, so we, we really try and, you know,
work from our experience of seeing Okay.
You know, who's making the
decision to use the api?
Sometimes it's the
developer directly, right?
For, you know, more enterprisey,
contractee, APIs we, we let you know
more of a business person take care of
all of that stuff, and then just say,
okay, within the team, invite in the
developer to work on the API and then
they just, you know, get straight in.
The subscription is there, they get
the API key and they start working.
Okay.
Mike Bifulco: Yeah.
I am, I'm victim or I have been victim
of that in the past where hey, here's
the next great thing we're gonna use, or
maybe I have the idea to, Hey, like, our
team should probably adopt this product.
And you get there and you're
hit a door stop because it's
not security approved or I.
Accounting hasn't approved the
expense or whatever the case may be.
It's a really interesting approach.
I, I think typically when we're talking
about API products it's not really a
facet that comes up and it's definitely
like an important angle, especially I'd
imagine if you're dealing mostly with
enterprise level customers, there's a
lot more of that like red tape in place
to keep the business safe and secure.
That makes a lot of sense.
Allan Knabe: Yeah.
Mike Bifulco: You, you touched on
something a minute ago that I, I think
is interesting too, that you were talking
about differences in plans for APIs
and making different things available.
I noticed on your site that there's some
monetization features available as well.
Can you talk a little bit about that?
Allan Knabe: Yeah, that's,
that's really exciting.
Right now we're working on some of the
more advanced monetization cases as well.
At the moment we've got, you know, more
of a like standard subscription base
that if you subscribe to use these API
endpoints, you can use them for, I don't
know, 10,000 times a month, 10,000 API
calls for 50 bucks or something like this.
So that's kind of where we started on.
A lot of our early adopters have
used this, but we are getting
into some cases now where we're
doing more usage based pricing.
Which is what people
expect with APIs, right?
So per API call, you're gonna, we're
gonna charge you $1, or whatever it is.
The caveat there is that we, we
are not a proxy to the API, right?
So we do not get involved in like
the networking layer of your API.
We leave that to the API gateway.
So unlike some other solutions
which proxy everything and
add latency, we don't do that.
The downside of that, of course,
is that we then don't going get
to count the number of API calls.
So we have to do that afterwards
via the the log file, which is
what we're working on right now.
We hope I mean may, maybe even
by the time this podcast comes
out we'll have completed this
for these advanced cases where.
You know, you can charge for a
particular endpoint for a particular
method, you can have a different
price to anything else, right?
So especially with AI companies, they
if they really are interested in these
cases of saying, okay, certain calls
are more valuable than than other ones.
And we get 'em requests now for
credits as well to say, okay, someone
could buy a package of credits.
And then depending on the kind
of course they're making it
uses more or less credits.
So, so these, you know, it's really
interesting time to be working in
this and yeah, luckily the team
is doing a really good job, so.
Mike Bifulco: Yeah, that's a big change
in paradigm that I think we faced probably
somewhere in the last two years where LLMs
in particular have made it so that like
the same API call costs differently every
time you call it, based on how much input
and output that it's, it's using which.
I don't know if, if you use it back to,
call it February of 2020 that was a pretty
foreign concept not too long ago and is
very, very like standard these days for,
for a lot of the creative AI based tools.
So really cool to see
being able to support that.
There, there's a lot here.
I'm, I'm honestly really impressed by
the amount of things that, that API will.
Provides, and even like the granularity
you're getting into for, for monetization
between seeing freemium and usage based
and different subscription tiers and
all those things, there's, there's
quite a bit that goes into that.
Can you tell me a little bit about what it
would be like for a team that's interested
in using api, able to adopt API able, what
does the integration process look like?
Allan Knabe: For the integration
process, we really tried to make it.
As simple as possible.
I know everyone one says that, but we,
we saw like when we were at Swisscom and
elsewhere, that there are products you
can get and you can do a lot of your own
development to, to integrate, et cetera,
and you are ready some weeks later.
But we, we had, I mean if we take just
that one case of pirate weather very
small company in Canada, I think they were
up and running in an hour or something.
They just connected their.
Amazon API Gateway, which you can
do with a role right in the Amazon.
Like 10 minutes to connect that.
And once you've got your APIs well
then you just need to, you know, put
a pretty picture on it and say how
much you want to charge basically.
And it's kind of working, right?
So yeah, we really tried to do it like,
you know, product led in, in that case,
so that it was, you know, off the shelf.
Very quickly.
Obviously for enterprise customers, they
might want a little bit more, more help
with the onboarding process and so on.
And for that we have, you know,
pilot programs where we sit with
them and, and discuss their needs and
so on, which is fascinating because
then you get to uncover like these,
like really urgent needs they have,
like the, that's how we got to the
API catalog part as well, right.
Just by talking to, you know,
people who wanted to use it and then
figuring out that actually they want
a catalog to seal their APIs, right?
And being able to add that.
That quite quickly.
But it, it does drive my development team
insane because it, it's just constant
feature requests, you know, from me.
And I apologize to the team if they're
listening to this, but I, I do keep like
a constant flow of new features coming in.
So at some point I have to stop and we
just need to tidy everything up, but yeah.
Mike Bifulco: Well, that's the joy
of building a product that people
want, is that there's lots more ways
to use it that come up along the way.
So one of the interesting things
about the product you're building
then, and, and from what I'm hearing
is that a pable is probably from the.
Implementation standpoint of the
dev teams that are integrating
with API bullet, you're sort
of language ag agnostic, right?
There's really just needs to be
able to point to and understand
the sort of the shape of a gateway.
Is there do you find yourself working
with particular I don't know, flavors
of team more often than others?
Like, do you, do you find that
Ruby developers come to you or rust
developers or something like that?
Or is it coming from all over the map?
Allan Knabe: It is all over
the shop, to be honest.
We, we, we get everything come through
and at the moment we're getting all
shapes and sizes of company come across.
It's, it's obviously really
interesting working with startups.
And, and you know, them getting like
Python requests and stuff like this,
it's really interesting when they come
along because they, they wanna get going
immediately and have it finished in two
weeks and they don't mind giving you
a hundred requests at the same time.
So very useful speaking to those guys.
Very useful.
The enterprise is, you know, first
of all, you have a conversation for
six months with someone who's not
actually ever gonna use the portal.
And then, then you get to the real
team who are, who are kind of using
it and connecting gateways and stuff.
So it's two, two different worlds.
But yeah, in terms of like, you know,
languages, it's, it's a huge chasm.
Mike Bifulco: I could imagine.
What about open source work?
Are you doing anything
with open source projects?
Allan Knabe: Well, well,
I hinted at rapid Doc.
Is, is one that we use
within our products.
It's honestly very,
very well put together.
You, you can find it
at a rapid doc web.com.
I guess you'll put a link as well in.
Mike Bifulco: Yeah, absolutely.
Allan Knabe: Yeah, that's great.
So it, it, it's it's
a really good project.
I think, you know, probably more
people could get value from that
if you just want to, you know, if
you've got a simple API you wanna
document it and put it up somewhere
it's a really nice project for that.
And we're, we're hoping to,
to support that community more
and more as we go forward.
So, so that's exciting.
Other stuff we're kind of like
interested when we get five minutes
because like I said, it's a constant
like feature frenzy at, at api able,
but one of the things we're looking at
is more on the oof two side as well.
Somehow helping.
And this was, this was like an idea we
had a few years ago working at Connor.
And that's when you turn around to a
product manager when you're building,
for example, an app and development
team starts to ask some questions like,
what, what flavor of OO two should
we use for securing this application?
Right.
And getting blank stares back.
Right.
So the, the, there's some kind
of a translation needed there.
That I think is really doable.
Some kind of like a tool that
you could build to say, okay, in,
you know, more, more human terms.
How would you like to secure something?
What are the cases, right?
You know, is it on a per user who's
logging in basis or is it more of a
machine to machine case, wherever.
So some kind of like,
maybe just utility that.
You know, you go through that flow
and out of it comes like the correct
o or flow or you know, JWT, what
you should be using as a technology
to secure it for that given case.
Right?
So that's kind of one open
source tool that we would like
to, to put out at some point.
'cause OF two is, you know,
well, it's developer, right?
And it doesn't translate very
well to, you know, you can't send,
you know, we've done this, right?
We've sent like business people the
o to a specification and said, yeah,
just choose the right flow, right?
And they've looked at it and
go, oh my God, this is crazy.
So, so there's that kind of thing there.
The other one that we would like
to look at maybe get a chance this
year a little bit more is to say,
okay, how green are your APIs?
Right.
So I'm, I'm sure Phil would be
interested in this one as well.
But we're in a, a very good place
since we're connected into all of the
API gateways across the organization.
And we can, you know, see from the log
files what developers are all doing.
And start to drop in some hints
for the organizational owners, the
customers to say, okay what could you
be doing to reduce the footprint here?
Because I mean, APIs are, is it 83% of all
internet traffic or is it more than that?
I can't remember.
It's around that kind of like area,
a huge amount of work happening
with APIs and you know, are there
some quick wins, for example.
If we see a developer is
getting the status of something
every two seconds, right?
It could be you know, a potential
then to turn around and say
well, maybe this should be behind
some kind of a web hook, right?
Say, okay, instead of some polling all the
time, you know, and, and that generating
a lot of backend work, you could say,
okay, we'll update you in like four hours
when this thing has changed status, right?
So.
That's like an immediate idea,
but I'm sure we could uncover
like, a lot more to say.
Okay.
Just, you know, let's, let's reduce
the number of API calls if possible.
And also not forgetting the, the
load on the back ends as well.
Mike Bifulco: Yeah.
Oh, that's, that's a really interesting
product angle and you're certainly well
positioned to be able to advise on that.
Given what you must know about how,
you know, gateways are deployed and
consumed and all that really fascinating.
Yeah.
I think that is, one of those things
that teams rarely think about, right?
Like, not everyone has a Phil Sturgeon
on their team who is very, very cognizant
of the existential crisis facing all of
us with, with environmental friendliness.
And it's hard.
It's, it's something that's subtle, right?
Like, it seems really simple to
make a polling call and like, yeah,
every two seconds we're sending a
couple of packets across the web.
But like,
you stack that up for a day and a week
and a month, and you're, you're, putting
a lot of energy through the wire that
doesn't necessarily need to be done there.
That's super cool.
I like that.
Allan Knabe: that's,
Mike Bifulco: oh, sorry.
Go ahead.
Allan Knabe: I was gonna say, it's, it's
actually a, it's probably an entirely
new company and product of its own Right.
But that, that, that's, you
know, if someone wants to run
with this idea, go for it.
Yeah, again, my team hate me because
I always have these crazy ideas.
I.
Mike Bifulco: I like it.
I'm into it.
Well, I, I will make absolutely sure
to drop your GitHub organization in
the show notes as well, if people
are interested in following the open
source and exposed code and projects
that you're working on, on the web.
And certainly if folks are interested
in chasing you down for working
on some of these projects there,
there'll be ways to do that there too.
Let's let's talk about
what's to come for you.
What is API bull looking at building next?
What are the things on the
horizon that are exciting for you?
Allan Knabe: Yeah, I think I
already, I already touched on kind
of like these, these features coming
in advanced monetization cases.
Also along with that, the analytics
that we can get to say, okay, how
are you using the APIs a little bit.
This like green thing is in there as well.
Of course, you know, when we get to see,
okay, what you, what you're doing with
the APIs and, you know, our developers
you know, signing up to use your api I,
but then not making the first API call.
Or did they, or they, were they a
regular user of your API and certainly
dropped off and things like this?
There's lots of very interesting things
we can do there as well, but I, I think
we're pretty much like feature complete.
Other than that we'll probably add more
API Gateways, we support Amazon, API
Gateway and Kong and Appg and Azure.
And so we'll probably add some
more API gateways this year.
Lots of people on like MuleSoft
and stuff like this, so, we'll,
we'll, we'll add those in.
But that's yeah, we're, we're,
we, we need to, you know, not
do more features and so I'm
Mike Bifulco: Yeah, features versus focus
is a perennial startup founder challenge.
I get that.
Okay, so what about your team?
Are you expanding?
Are you looking at hiring?
Allan Knabe: Okay.
So we're, we're currently
going through our seed round.
So, so we're doing another raise at
the moment, and as soon as that's
complete, then yes, we will be looking
for developers to join the team.
You know, especially we have
need for DevOps type people, site
reliability engineers to, to take
care of the infrastructure because
there's a lot of moving parts.
We opted for a single tenancy
application which is, which is great.
But at the same time takes a lot of,
you know, maintenance and looking after.
So that's, that's definitely one role
we'll be looking for in the future.
Mike Bifulco: Got it.
Yeah, that's another link I have in the
show notes is the, the correct sort of
URL for careers or job listings for api.
I able too.
That's great.
So before we wrap up, Alan where,
where's the best place for listeners
of the show to go to find and chat
with you if they're interested?
Allan Knabe: Okay.
I spend most of my time on, on LinkedIn.
I'm not cool enough to be on X, so
I'm, I'm mainly on, on LinkedIn.
Other than that, you know, it just come
to the website and then just, you know,
throw in a contact request or something
and you know, get a, get ahold of me.
That way as well,
Mike Bifulco: That's great.
And just so that we say it
out loud, what is the website.
Allan Knabe: a API able io so you can
think of it's, we make you API able
or you could be asking a question.
As a developer, when you look
at some code, you can say.
Is that a pable?
Mike Bifulco: I love it.
Again, another one of those things
we'll drop in the show notes.
And Alan, thanks so much
for, for joining me today.
It's been a real pleasure.
I'm super excited about what y'all are
building, and happy to have you come back
on the show anytime if you're you know,
rolling through new feature announcements.
So there's some you know, environmentally
friendly things we want to get
into for a deeper conversation.
I'm happy to do that too.
Super, super cool to have you here.
Thanks for joining today.
I appreciate it, Alan.
Allan Knabe: Yeah.
Thanks a lot, Mike, for having me on.
Really enjoyed it.
Mike Bifulco: Of course.
Yeah.
Take care.
Talk to you soon.
Allan Knabe: Thanks, bye.
Mike Bifulco