Subscribe
Share
Share
Embed
Docsalot founder Faizan Khan sits down with APIs You Won't Hate host Mike Bifulco to talk about helping devs automate and build better docs for their products... and more!
- Docsalot - Agent-readable docs, for developers and AI agents
- All Them APIs - Compare APIs before your agent writes the integration
- Faizan Khan - on Twitter
Creators and 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.
Hi friends, and welcome
back to APIs You Won't Hate.
My name is Mike Befolco, and I'm sitting
down today with a new friend to have a
discussion about docs docs of all sorts.
If you're an API developer, you've no
doubt been exposed to many of them, and
I'm really interested to meet and talk
with Faizan Khan from Docsalot where we'll
be talking quite a bit, I'd imagine, about
documentation, but also how the nature of
documentation is changing, the way people
use docs is changing, and to be perfectly
honest with you, the way not people use
docs is changing quite a bit as well.
Faizan, thanks so much for joining today.
I am super psyched to
have you on the show.
How are you doing?
I'm good.
Thanks so much for having me.
Excited for this
Yeah, of course.
Tell me a little bit about yourself
and how you got into the p- the
place where you are right now, and
I wanna talk about Docslot and, I
don't know, the origin story as well.
Yeah, for sure.
So I'm the CEO of Docsalot
as in Sir Docs a Lot.
So we create API docs CLIs,
SDKs taking in OpenAPI specs.
Yeah, a bit about the background.
We started as a dev tool product,
so it was called SlashML.
We went through Alchemist Accelerator,
and we were targeting developers,
so trying to get them onboarded.
And as you do, you start bottom up
you build a lot of docs, a lot of
content, a lot of dev tooling around
that, SDKs and stuff like that.
And through that, we built an internal
tool that was way better than any of
the market out there, and SlashML wasn't
getting any traction, so we were like,
"Okay, let's see if we can sell this."
So we just went around, shopped around
and got immediate traction from that.
And that's how Docsalot came into being.
It's been a year now,
almost, on Docsalot itself.
And yeah, here we are as it is.
Yeah, we are definitely here.
And a- always interested to hear
about a pivot and finding traction in
particular, but why don't we start here?
Tell me a little bit about the
elevator pitch for Docslot.
So if I've never heard of it before,
what does Docslot mean to me?
Yeah.
So Docs-a-Lot essentially we call it
the docs for agents and by agents.
So es- essentially what that means
is the-- it in-- we ingest everything
in your company org, so source
code, Slack communication, internal
communication could be OpenAPI
specs, and then we spit out any
agent-facing or customer-facing content.
So it could be documentation,
SDKs, CLIs, MCP server.
And it's essentially a dev-focused
dev marketing agent that's in
your company working with you.
Oh, really interesting.
And so that's as contrasted to the typical
process or like the maybe old world
process of developing documentation.
What did it look like before Docsalot and
how does that differ from what's here now?
Yeah, so before Doxalot, it would be a
normal hu- a human basically taking in,
reading the product analytics seeing
how the people, how users are using the
product, and then chatting with a bunch
of engineers seeing what features are
released, and then just going up there.
Could be any other product, could be
markdown files, updating the change log,
updating the what features were released,
and also just adding new pages to
onboard more people onto their platform.
Doxalot takes all of that out of the way.
And then on top of that, if you
have SDKs, MCP servers, you have
multiple surfaces that the product
manager or the dev marketing or
the dev rel person is maintaining.
So we just help with that.
Having worked in DevRel for a long time
myself, I'm familiar with the process of
maintaining documentation for one SDK in
one language is a fairly intensive thing.
Usually requires some
subject matter expertise.
It definitely requires some use
of the thing, so testing, like if
I'm gonna deploy docs for my SDK,
I should be sure that it works.
And then it requires
some ongoing maintenance.
As the, as bugs are fixed, features
are added things of that nature go on
within the product organization you need
to keep your documentation up to date.
And so there's a lot of that I think
is interesting and requires nuance.
And I think a lot of people might
bristle at the idea that their
documentation would entirely be
written by agents and maintained by
agents, but can you tell me what that
feels like as the end user of it?
So we are not removing
the human from the loop.
We are just augmenting the human.
We are removing the
grunt work out of there.
So we we bring all of the information
onto a dashboard, and then the agent
sort of drafts the first version.
There is always a human approval
required on the final version and
the tweaking and stuff required.
The reason this is helpful is because
there is nowadays so much shipping
going on with agents small teams are
shipping at the rate of 40, 50 engineers.
And con- contrast to that, the-- there
is still a few-- like the ratio of
engineers to human product managers
is still five to one on the lower
end and could be 10 to one, right?
So the features are being shipped
faster, but the customer-facing
stuff is still lagging behind.
So we augment all of that.
People do have internal
workflows for that.
I'm not saying people can't
build that internally.
There are some effort, but when people
or when teams start doing that, they
realize that it's one of those build
versus buy kind of thing, right?
They start maintaining their own
workflows and then they realize, okay,
we need a more reliable sort of system
for this to create PRs, to surface
relevant customer queries so that we
can write relevant pages for them.
That all sounds very familiar to me.
And I think having an automated
hand in some of that certainly
sounds like it would be helpful
and could save a fair bit of time.
You mentioned earlier that one of the
things that the product does is that
you can integrate it with your team's
Slack, and you might have mentioned
Discord, some other things as well there.
But even-- So I have been using
Slack for quite a while too.
That's an interesting idea to me too
because a lot of the context of what's,
what is happening on building out a
product happens in DMs, it happens in
public channels, it happens in meetings,
it happens in planning tools like
Jira or Linear or whatever you use.
Tell me about that.
Like, how is it listening to Slack, and
w- do you get questions from your users
about "Oh, should I be nervous that I'm
publishing pictures of my cats in Slack
and that Doxolot is listening to that?"
No.
So Slack is like like one of the, the
issue that we ran into is Slack is
similar to any GitHub integration.
Like you go through the IT team or
the VP of engineering, and you're
really specific about the kind of
accesses that you're getting in Slack.
So the way it works is it's just
a bot that you install, and it
only gets invoked if you tag it.
So it's not always on.
In Discord it's always on, but in,
in Discord's case we have-- you would
create a special sort of channel in
which it's always on, which is most of
the time a customer support channel,
so that when a customer starts a
query, the bot responds first, and
then there is a human beneath that.
In Slack's case it's just a bot that
you tag as you would a human coworker.
And then a normal query would be
like, "Go look at the previous
threads or the previous discussion
and just create a page out of this
for me to review later." That's it.
Like that's as far as we go.
for the folks listening, if you've never
had the opportunity to build a Slack
bot, it is a little bit baffling and
intimidating at first, but you will get
that familiar, what would you call it?
Like OAuth consent screen where
it asks you what you wanna give
it access to and all that, and
yeah
your stuff can do is brokered
by Slack's agreements there too.
Yeah.
Yeah, it's also like we go through a
pretty nitty-gritty detail of onboarding.
At this point, like every IT
team has evolved the Slack bot.
So we are pretty, Like we initially
with Slack also started with always on
like Discord, but like you mentioned,
like you get access to everything,
which is not what most teams want
Sure.
Yeah, I think that's the first thing
that I would be a little nervous about.
And genuinely that's because I publish or
pub- publish, I share too many memes with
my team and, those don't need to leak into
our documentation or whatever it may be.
So it sounds like due to the nature
of how the product works, it is
largely a tool for communication and
obviously generating documentation.
Are there any limitations or edges in
terms of compatibility with languages?
Will it work with Rust and Python
and all the things, or is it
- specific to certain I guess stacks?
No, it pretty much works with everything.
The only limitation on is on the SDKs
that we generate from OpenAPI specs.
We only generate three so far.
We can upon request, we can do other
things, but like the three are we are
con-- is what we are confident about,
and you can just get started with it.
Python, TypeScript, and Golang.
The rest, it's a question of like
we haven't received any customer
requests and not enough pull for us
to put much effort on that front.
Among the many things that DocsALot
ingests, then it sounds like OpenAPI is
one of those things, and it'll read your
OpenAPI spec and generate documentation,
yes, but SDKs as well from it.
That's really interesting.
That's like a highly competitive
marketplace for sure, but definitely
something where if it's embedded in
your doc system as well or your process
for generating docs and creating docs,
sounds like it'd be really interesting.
I was looking at your site for
DocsALot, the marketing site, and
going through the list of features.
There's quite a bit there.
It's really interesting.
Just to enumerate a few off the top of my
head, obviously documentation generation.
There is SDKs generation MCPs and
then some benchmarking things,
like lots of stuff going on here.
I'd love to talk about any of that that
you're interested in chatting through.
Yeah, for sure.
we could talk about how sort of the
benchmarking thing or how agents are
rather using the docs and how we are
thinking about that, because that's an
active area of interest among all DevTool
people and in, in how to get more agents
to use their product rather than humans.
So let's start with that then.
What do we, what do you mean agents
are reading my documentation?
What is that actually under the covers?
S-so it's essentially you must have
observed it in your workflow or any
of your engineers' workflow, like all
of us use agents now, like Co-Codex,
Claude, Cursor, it could be anything.
Like we don't-- When we try a new tool,
all we do is ask Codex to "Okay, sign
me up onto that, that tool." So that's
how most of the onboarding is happening
nowadays, which means that agents are your
primary-- If you're a DevTool founder,
agents are your primary customer, right?
Like you want to make sure that the
agents can onboard itself in as few steps
as possible without doing multiple tool
calls without ingesting a lot of content.
It should just be like read one page
and you're there and all of it comes
down to the way agents operate.
Like we have a bunch of-- Like we,
Because like we think about that a lot,
like we observe agentic traffic and
want to make sure that our customers
get more customers or agents rather.
So we-- Like that's one of the key
areas that I'm spending a lot of my time
on, just analyzing a bunch of traffic
that people are getting on their docs.
So one of the things we do, which
is a secret, is that we are on
Cloudflare, so we route all of
the traffic through Cloudflare.
So before Cloudflare even had the
bot or the differentiation between
Codex and Claude it was just bot.
Like you had no idea if it was a crawl-
crawler, Google crawler bot or a spam
bot or a cursor query or a Codex query.
So which means if you had that disabled,
you were not getting any requests.
Like your docs were just
returning a 403 or a 404.
So we let everything in.
Like we were like, okay, let's just see
if we can do some empirical analysis
on that ourselves, and that gives us
some-- gave us some really interesting
insights, like where to place the
index.md or the llms.txt on every page.
Because the way agents read file
is they go they go depth first.
So they don't browse.
They don't look at the index file.
They will just find the nearest matching
page to the query and just read that
page all the way to the end and be like,
"Okay, I'm done now. This is it." The
onboarding page does not let me onboard
Or the onboarding page only has support
for X, Y, Z, and therefore we are done.
Or in, in worst cases early on, it
would also hallucinate the answer.
So it would be like the onboarding
page mentioned this, and that, and
I'm gonna pattern match it against
the other docs that I've read
and do-- figure out what it does.
What you want in that case
is you want it to recover.
You want it to go back to your index
file and expo- explore other pages
where the answer might exist, right?
So that recovery part is really important,
and we experimented with a bunch of
things like putting the LLMs at the
top, putting the LLMs at the bottom,
LLMs or TXT in, in every, every page.
In the middle try to stick in.
And what we found is if you just put it
in the first column and have one simple
line that says, "Hey, if you're an
agent, we have this llms.txt contains a
list of all of the pages in our docs."
Yeah.
Wow.
You've just said something that's
very simple that is a little
bit shocking to me in some ways.
But okay, let me make sure I understand.
So a- agents are coming and browsing
my doc site to learn how to use my
tool because people are sending it to
me from Cursor or Claude or Codex, and
they are using a very algorithm-driven
way of seeing what's on my site.
So when they get there, they find
the way to go to llms.txt, which is a
text file that explains what LLMs have
access to on my site, or I think you
said index.md, which is a similar idea,
both of, yeah
Yeah.
And so what you're saying is it gets
there and it does the first thing it can
find on that first tier is if it says
this is onboarding, it thinks that's the
onboarding, that's the tendency of it.
And so the escape route is to then give
them something that says, "Hey, just
so you know, as you're reading through
this, there's more stuff here. Go here
if you're a bot and get all the stuff."
That isā¦ That's really interesting.
That's very cool.
And obviously not how humans work, right?
People don't tend to
look at things that way.
Yeah.
if you have multiple onboarding
paths, like in our docs, we have
a CLI onboarding and a web editor
onboarding and an MCP onboarding.
Like three types of onboardings.
If you ask the agent to go onboard
itself to Docs a lot, it's if we didn't
have the LMS or DXT, it's just gonna
be like, "Okay they only have web
editor onboarding, so therefore I'm
gonna open the browser in Codex and try
to sign up via your Google account."
But in that case, what we want is for
for it to use the CLI or the MCP, right?
Which isā¦ So yeah, in that
case it's really helpful.
Yeah.
Oh, that's really interesting.
Okay, so pedaling back a little bit
then, writing docs for agents and for
people, the, the actual, meat and potatoes
of the docs of how to do things like,
let's say, the "Hello, world" of my SDK.
Is there a difference in writing that for
people versus writing that for an agent?
Or is it more a matter of how you
tell it to get to other things?
I think it's subtle differences
we don't have that muchā¦ so
agents want negation on every page.
If you don't have a negation like this
is what this page does and this is
what this page does not do the agent is
going to be like, if you remo- if you
leave out the do not do part, the agent
is gonna be like, "This is the page."
This is it.
And there- therefore, because it
pattern matches it against text, right?
So it's if you say let's
say the onboarding.
If your onboarding page does not
explicitly say that this is web editor
only onboarding and we have other
onboarding parts as well, it's gonna
be like, "Okay, this is the only
onboarding that I could find, and
therefore I'm just gonna use this."
Whereas humans will explore.
Humans will be like, "Okay, let me
see. Let me click a few buttons,"
r-right.
Yeah.
And to use a weird parallel, humans'
context can go beyond that session.
I may have been on this page yesterday
and remember that there's an MCP
or something that I can use here.
Oh, man, that-- what a really
interesting space to be in.
That is at the edge of a lot of
things are changing very quickly
and how do we all do this well?
And so your you said you found a lot of
traction with this product pretty quickly.
What did your first customers look like?
The people that were actually
adopting it, what were-- did
they have things in common?
Where did they come
from surprising places?
Yeah, mostly.
So like I mentioned, we went
through Alchemist Accelerator and
the early customers were mostly
just us going to them and be like,
"Can we create docs for you?" Like
manually before we had a product.
And that was a clear signal for
Paul "Okay, like we don't have
time. We have a demo day coming
up," and yeah, just do that.
Like we are paying GitBooks and Mandify
who are the sort of the bigger players.
Like we're paying them anyways if you
can do that half the cost without me
touching anything, like just do that.
And at that point, we were of
course using like coding agents
to build all of this ourselves.
And what we initially started with was
like, okay, let's just focus on this.
Le- let's say if you have a Docusaurus
of your docs, can we automate maintaining
Docusaurus, like all of the open
source, like Astro, Starlight Fuma docs?
Like we are platform agnostic.
Like we just maintain the docs.
So we were at the GitHub
level, if you will.
Like we had a Git- GitHub app and
we would ingest source code and then
just spit out changes to the docs in
Markdown or could be HTML file even.
Some people had their own custom
Next.js file, like in Nextra.
And then over time as, as Claude
were, was becoming more mature,
we realized that, okay, people can
build these triggers themselves,
maintain these things themselves.
We just started improving the platform,
improving the design of our docs,
because that's-- when all is said and
done, people still want their docs
to look really good, regardless of
whether agents are using them or not,
because it's it's an expression of who
you are as a company or as a product.
Especially if you're in dev tools.
Developers tend to be really judgy so if
your docs look wipe coded or half done
or not aesthetically pleasing they'll
be like, "Okay, the product is not
that mature." Like they're a bit early
we are our own harshest critics without a
Yeah.
Yeah.
Yeah.
So it doesn't matter if agents are the
users of docs, like there is still a human
at the end of the day making the decision.
So the docs have to look pretty.
Like that's one of the key like rule
for any docs platform or even if
anyone is building it on their own,
like your docs have to look pretty.
Like I've seen a clear differentiation
of in our journey, but also
in our customers' journey.
When you flip the design of the docs, like
you immediately-- people start immediately
seeing you as a more mature product.
The product is the same.
You just change the design, but it's
this like contrasting difference.
And that in itself is a
very human benchmark, right?
If you send an agent to the same docs with
two flavors of theme or however you wanna
look at it, they don't care, They wanna
know if it works, and maybe that's more
objective certainly, but there's still
lots of humans making decisions here and
actually, often swiping the credit card.
That's an important angle there.
I would love to talk a little
bit about how this is all built.
You've mentioned a few bits of
tech here, so some Cloudflare
stuff and a few different LLM tech.
Like what, what's under the covers?
Yeah.
So it's a-- So the dashboard
is built in Next.js platform.
We are on Google and Cloudflare
in the middle for load
balancing and other things.
And then for every sort of customer docs,
we spin up a separate Cloud Run instance.
That helps us make things
really isolated and simple.
And in case of if it's an enterprise
customer, all we do is just increase
the number of load balancing.
And if it's a small sort of early
pro-tier customer we just spin
up a simple smaller instance.
It makes it easy for me to price the
product and for customersā¦ and it
also makes it just more secure, like
everything is sandboxed and isolated.
Like no, no environment
leakage is happening.
We don't have one box.
Yeah, and that was intentional by
design when we were building the
platform around the same time.
I don't want to name them, but like
one of the bigger platform had a
similar hack happened, and that was
one of the hack is someone got access
to one box and information leakage
did happen from other customers.
So we were like really particular
about okay, let's delay the
launch, but let's make sure we
have separate boxes for everything.
Yeah.
I guess probably in your case too, that
necessarily means that your, like the
bot that has context about my product
only can get context about my product
'cause it's cordoned off to that
thing and, is listening to my team by
whatever ways too, I would imagine.
Yeah, that one yeah, that one as well.
But the-- it's also more around like the
if you have a GitHub app installed in your
organization and if someone gets access to
that instance the- they don't have access
to other other instances basically, right?
So other organizations, right?
Hacks can happen, like you can't defend
against them, but like it's easier for
us to just spin down one instance versus
one box that has 1,000 customers, right?
Yeah, that could be problematic,
Yeah.
Yeah.
Okay.
You mentioned a minute ago as well
predictable pricing for your customers.
Let's talk a little bit
about the pricing model.
What does it cost to get onboarded?
What is in terms of dollars but also time?
What does it take for people to get
started, and what's it gonna cost them
the first time they spin up some docs?
Yeah.
S-so one caveat is like we are
not-- we don't have a free tier.
The if people want a free service,
they can go to one of the competitors,
just search for them, and then they
can spin up a good-looking docs.
We areā¦ So our lower tier
starts at 39, and then it's 99 for
the pro tier, which gets youā¦
And the difference between the two is
just if your docs are receiving more
traffic and you want more automations
you just move to the higher tier.
And then we have the enterprise
tiers, which has SSO and other things.
And it's similar for MCP servers
and SDK generation as well.
If you are doing more updates you
will go to the upper tier, otherwise
on the lower tier it's free.
There is a two weeks free trial, so it's
literally free to try it out, everything.
And then other than that, we
are free core open source.
So we have a bunch of open source
products using the pro tier.
And yeah, so it's commercial and
non-commercial, so we give it away
for free to open source products.
And in terms of how much it
costs us, like the docs platform
is really simple to price.
Essentially, if you remove
all of the AI automation.
AI is a bit harder to price.
Like you don't know the token pricing and
how much how much you are spending versus
the versus how much people are using.
So we are still on a predictable pricing.
Some-- I see some of the people
have gone into credit-based model,
which I feel like makes sense for
enterprise customers, but for a
startup that can be really detrimental.
If they, one of their developer
comes in and makes 500
changes, do they pay 5,000 now?
Like right.
Yeah, it can be unpredictable,
especially with startups when
things are moving really fast.
The CEO does not have time to add all of
the thresholds and automations, right?
And our primary like target
audience is like startups.
Like we are not going after enterprises
like that's how we got most of the pull.
And to be honest, we can't serve
enterprises at our scale as well.
So it's like we love startups,
we are at startups level.
We still have aā¦
call to action.
If you're build- building an open source
product or running a startup and you
need docs gen of some sort or SDK gen
or MCP gen, like you should beā¦ Your
ears should be perking up right now.
Yeah.
Yeah.
Like our thing is like we are serving
the one, one poor product manager
or the one poor DevRel guy who is
getting bombarded by the features
that their team is shipping and have
no time to just maintain everything.
So that's the person
that we are targeting.
hugely beneficial if you're that guy.
This is the best day of
your life, certainly.
We were also chatting before I hit record
about something that we're, we are happen
to be kindred spirits in this world of
of building things for people on the web.
Tell me about All Them APIs.
What's that?
Yeah, so all the APIs started
with just our sort of problem of,
okay, how are agents using the
products, docs, and everything?
And then so all the API is essentially
a set of benchmarks where what all we
do is take public docs of any product,
not just ours, could be any product.
Like recent, we did a cluster analysis
of emails, and then we give it to
Claude and Codex, and then we just
give it one prompt, and the prompt is
the same for all of the benchmarks.
And we're like, "Okay, go onboard
yourself onto this product.
Create any emails, create any accounts
that you want, use any tool that you
have access to, but do not stop un- until
you're done, and log everything." So we
log everything in the process of that
onboarding process, and that gave us a
really interesting sort of ways of how
the Codex is using the tool, but also
what docs and products are more prone
to agent onboarding versus what are not.
Clear limitations that I'll just name
a few if you have them, and if you're
a de- dev tool founder might want
to consider thinking around them.
One of the ones is so if you have a
credit card like trial might want to
consider just adding threshold and
removing the credit card requirement.
Like that's where a lot of like
Firecrawl, I think, was one, and
then a few others, which makes
sense, like you want to remove spam.
But because agents are trying products,
they don't have access to credit
cards, like you want to give them
free stuff to try before, before then.
The other one is which is-- which
could be a bit harder, but so the
the Claude and Codex did have access
to Gmail, like my Gmail account
or a test account that we created.
But if it requires registration, if
there is no social auth, then it just
increases the number of steps, and
it was prone to fail in one of those
steps because the email arrived late,
the two-factor auth arrived late,
and all of those kinds of things.
And then i- in one of the cases which
I won't name, the like if you have
three or four products and if you
just have one docs for that product
again, it, it brings, comes back to the
other things that we were discussing.
Make sure you explicitly say that the
product that you are looking for is that
one not the first page that you found
yeah.
Yeah, that I think you called it before
n- the show the negatives or show
the, show what's not there on that
Yeah.
Yeah.
yeah.
Oh, that's really interesting.
As I've spent a lot of my career thinking
about information architecture and
design of things for people but it really
is a very important difference there.
I feel like I'm furiously taking
notes here and marking down
things mentally to go try out
after we get off the phone here.
That's really interesting.
And so all them APIs is
something, it's public, right?
People can access this.
What's the URL for that?
It's allthemapis.com.
A-L-L T-H-E-M apis.com.
Very straightforward.
I'll make sure that's in the show notes.
And so maybe if you're building out
an SDK of some sort good to give yours
a run through the run-- Yeah, a run
through all their APIs to test it out.
Man, that's really fascinating.
And so you've certainly taken away
a lot from that and it's like a
kindred product that's making your
features better without a doubt.
I'm curious what's next for you.
So what are you excited about
that your team is building
and what's around the corner?
Yeah, so we have lots
of exciting features.
One of the things that we are thinking
on, like I mentioned, is is how can we
get more customers or agents for, for our
customers that, that's using our platform.
So we are thinking of like there
is a bunch of things because
docs is just one thing, right?
Like there are, there is if you have
an MCP server, there is the MCP,
but also all them APIs is also a, a
sort of a, a path in that direction.
Like if you have an API product how
can you get more eyeballs on that?
So one of the things that we
are thinking of is what would
a dev marketing person do?
Can we
oh yeah
that?
How do you get more eyeballs?
Some content generation social media
automation a change log announcement.
How would a human announce that kind of.
So there is some exciting things
coming up in that sense, which will
give our customers more eyeballs and
that's a great idea.
Sure.
That's one of those rituals that
has to happen with every release
and definitely requires human power
to do and hours of their lives.
And there's lots of good things
you can do around branding and
brand voice and all that there.
That's a super cool idea.
I'm really into that.
Okay.
So Farzan, be- before I let you go I'm
a-- I've got two more questions for you.
We we've talked a lot about DocsALot.
I don't think I've said
the URL, docsalot.dev.
There will also be a link in
the show notes to that for folks
to make sure they check it out.
If someone is interested in trying
DocsALot or has feedback for you, where's
the best place to find you online?
So I'm on Twitter,
F-A-I-Z-A-N-1-0-double one four.
We'll link that.
And then on LinkedIn, they can
just find me, Faizan Docsalot.
I should pop up.
Blue Sky as well.
Looks like everywhere, but also
they can just if you log into
any of the websites, you'll see a
support or anything, and I should
pop up on the website at some point.
If I don't, then we are
not doing a good job.
That's perfect.
Sounds good.
Faizan Khan, th- thank you so much
for taking the time to chat with me.
It's been really cool
learning about Docsalot.
I'm excited to see where you'll go, and
please feel free to join us back on the
pod anytime if you've got additional
releases to talk through, or if you
have API chat you wanna get into.
Yeah, for sure.
It's been a pleasure.
We'll do another one.