Full transcript
0:00I'm Alex, founder CEO of Stainless. Um,
0:02previously worked at Stripe or was on
0:03the API platform team there. Um,
0:07worked on um kind of everything under
0:09the sun related to um API platform. Uh,
0:13but most notably uh did a re rebuild
0:17redesign of the API docs. Um, actually
0:19collaborating with with Dave here a
0:21little bit. Um, and then um a uh created
0:25the Stripe uh SDK generator. Uh and so
0:29stripe SDKs have been handmaintained for
0:30a long time and and that was really not
0:32scaling well. Um and uh what we have is
0:37is uh now is has been working a lot a
0:40lot better and started stainless um
0:42about four years ago to bring that and
0:44other other important parts of API
0:45tooling to to everybody. Um and so our
0:48mission is really to help every company
0:50have um a stripe level API and and to
0:52really kind of I like to say make the
0:54internet more interconnected. Um, and
0:56so, uh, we now have, um, a number of
0:59different products, um, SDK generators,
1:02um, uh, CLI generator, Terraform, Docs,
1:06MCP. Uh, we're working on request logs
1:08and other things on the back end as
1:10well. Um, but we just generally like to
1:12nerd out on on everything related to
1:14APIs. Um, we're a team of about 50,
1:17including a number of people who worked
1:18on this stuff, uh, worked on the same
1:20team uh, at Stripe, also Heroku and
1:22others. And so um uh we've got some
1:26stuff that we've we've built today, but
1:28we just love to um really do everything
1:30around designing building APIs well and
1:33and love to talk with customers and
1:35others about that. Um I'm joined today
1:38uh by Kevin and Min um uh on our team.
1:42Uh Kevin runs um Devril and marketing
1:45and and joins us from OpenAI where he
1:48actually um a user of stainless um as a
1:52member of the API team there. Um and so
1:54we can also talk to um some experiences
1:58um
2:00great. Uh so I I can jump in with a
2:02little bit of some of the problem
2:04statements that that we have.
2:07Why SDKs? Why have those mattered
2:09historically? Why do those matter today?
2:11um other aspects of API tooling um and
2:16um briefly touch on
2:18what we do. Um but really I'm most
2:20interested in folks questions and and
2:22getting into discussion. Um so
2:26um I'll start in a in a sort of a
2:29pre-agentic world. Um just makes the the
2:31narrative and the story a little bit
2:32easier. um where you know what what what
2:36what the pain we saw at Stripe was
2:38everybody um
2:42pretty much everybody who used the
2:44Stripe API was doing it through the
2:45official SDKs. Um so you know from my
2:48perspective as an engineer building the
2:50API and and to all my peers it was kind
2:52of like postvv1charges
2:54that that was the API endpoint but to a
2:57to a user it's stripe.charges.create
2:59create, right? It's the Python library,
3:01the Python library, the TypeScript
3:02library, what have you, that actually is
3:04the API to the customer. Um, and when we
3:07provide that and we provide that
3:09especially with type safety across the
3:11entire breadth of the API, um, that
3:14means your your API is like, you know,
3:16kind of like actually real code in in
3:18your codebase rather than this, um,
3:20really unsafe, you know, foreign
3:22interface. Um, and uh, really like a big
3:25pain to do even all the basics with. Um
3:28and of course without code generation um
3:31that was pretty impossible to keep up um
3:34all the all the request parameters
3:35response properties you know it's
3:37thousands tens of thousands across the
3:39stripe API um to keep up with and
3:42there's some open source tools that do
3:43this but they were just very many miles
3:46away from the stripe quality bar um and
3:50uh a huge pain to maintain um we we
3:53heard from from others who were trying
3:54to do that and then kind of end up
3:56moving your your developer brand
3:57backward wards um really hurting more
3:59than than helping in terms of the
4:00developers actually trying to use the
4:02API, trying to use the SDKs. Um fast
4:05forward to today's world on the one hand
4:08you have the pain point of developers
4:11are increasingly delegating the actual
4:13coding work to agents. You want that to
4:15go well as they're building integrations
4:16with your APIs internal or external. You
4:19want that to be smooth, predictable. You
4:21don't want the developers have to
4:22constantly kind of get under the get
4:24under the cloud code covers, so to
4:26speak.
4:27um and uh enabling agents that are that
4:31are writing code against an API um to be
4:34able to um iterate smoothly against a
4:37typed interface, an intuitive typed
4:39interface makes that process go a lot uh
4:42smoother. And then of course once you
4:43end up deploying to production, you you
4:45have a lot more confidence that things
4:46are going to go okay. You know, at least
4:48you're passing type check. Um and if you
4:50then need to iterate later, of course,
4:51it's a lot safer to do that. Um uh
4:56some teams I actually haven't seen this
4:59very much in the wild so far um but um
5:02you know some folks may say like hey can
5:04we be vibe coding SDKs at this point um
5:07the concerns there are often around um
5:10kind of the repeatability the robustness
5:12you you these are it's generally an area
5:14where you really want to see things um
5:17very consistent um uh from one parameter
5:21to the next from one regeneration to the
5:22next Um and and and especially with
5:25programming languages that a team is not
5:27familiar with, you know, because you
5:28need to be supporting all of your
5:29customers. Um it's it's an area where um
5:33you know, we're kind of still a
5:35requisite to be working with, you know,
5:38old school code generation of more of a
5:40compiler-like architecture, which is
5:41which is how we do things. Um I'll pause
5:44here for for for any questions. Um I
5:46want to make sure that this is sort of a
5:49a problem direction that that is
5:51interesting to folks.
5:56or clear.
5:58Great. Um so in terms of stainless um
6:01just quickly sort of like um uh what we
6:05do, how we work um
6:08uh
6:09it's a very simple Oh, Kevin, great.
6:12Thank you. um uh we'll take in your open
6:15API spec um uh and um layer that in with
6:20a stainless config which is a thin
6:21configuration file filling in a bunch of
6:23the missing pieces that usually are not
6:25in an open API spec that'll then just
6:28produce SDKs docs MCP servers CLI so on
6:32those go out as repos um uh anyone who's
6:36looked at the OpenAI Python library the
6:39OpenAI TypeScript library um anthropic
6:42etc
6:43Um, that's that's our product, right?
6:46That that repo is is generated by
6:48Stainless. Um, and so we just kind of
6:49like produce GitHub repos and keep them
6:52up to date. We do release PRs and as as
6:55a team ships updates to their open API
6:57spec um through a GitHub action that'll
7:00just automatically result in those in
7:02those updates getting pushed out. Um,
7:04and so for teams it's just, you know,
7:06click approve and and the release goes
7:08out for, you know, version 2
7:12185.0
7:14or whatever of of the Python library.
7:17Um, and um,
7:21yeah, there's there's there's plenty
7:22more that we can go into, but that's
7:23sort of the basics of what we do. Um,
7:25and so I'm I'm excited and interested
7:27for um, questions and discussion.
7:36Um there there there's there's more we
7:39can go into on a variety of topics. Um
7:41but um
7:44everybody has different things on uh top
7:46of mind. So
7:51>> uh we could also uh voice over a quick
7:53demo. I know that's a a big part of
7:55these uh discussions. Um, since I I have
7:58the tab open, Alex, is it cool if I just
8:00give like a quick
8:01>> Sure. Yeah. Yeah. Folks are interested
8:03in that.
8:03>> Yeah. Thanks.
8:05>> Um, awesome. So, uh, so the Alex
8:09mentioned kind of how stainless works at
8:11a high level. um a project that you have
8:14set up with stainless takes that open
8:16API spec um and the stainless config and
8:19you can use those two things to generate
8:21uh lots of different output targets
8:23including uh API documentation
8:26uh you know SDKs across languages uh a
8:29CLI and an MCP server. Um so you can
8:32interact with that through the command
8:34line or you can use the uh or you can
8:36use the studio interface that we're
8:38we're looking at here. And if we go to
8:41the uh API studio, um this actually kind
8:44of lets you preview what your uh SDK is
8:47going to look like based on your current
8:49uh stainless config and open API spec.
8:52Um so you can kind of look at the
8:54different uh methods uh within your
8:57documentation um across uh different
8:59languages. uh when you're uh building
9:02your SDKs across uh across different
9:05languages
9:06um there might be specific um you know
9:10uh platform things that you want to look
9:11into or like naming uh problems that
9:14would show up like as as diagnostics. So
9:16there's a little bit of like debug uh
9:18tooling there. Uh but uh one of the
9:21things that you get uh as part of like
9:23the stainless build process is a GitHub
9:26repo. Um which uh when you kind of click
9:29through to that and let me share this uh
9:32is just is this is the final output of a
9:35stainless SDK build which is uh code
9:38that actually you can uh modify yourself
9:41like um the generated code here uh is uh
9:44based on your open API spec plus like
9:46naming conventions and other
9:47configurations that you have. Um but
9:49like any of these files uh are actually
9:52now editable. Um so even generated code
9:55you can go in and like make changes to
9:57it. So if there's like a particular part
9:59of the API that you want to have like
10:01very fine grain control over um every
10:03bit of code is editable. Um and as your
10:05SDK is regenerated on subsequent um
10:08occasions
10:09those same uh git commits that you
10:11created are reapplied over the top of
10:14the uh generated code. So you have the
10:16ability to kind of reach in and
10:18customize customize anything.
10:21The uh other thing that you get uh that
10:23I wanted to show is which is relatively
10:26new uh is the uh is reference
10:29documentation uh for your API as well.
10:32Um so the uh current uh doc sites for
10:36openai and anthropic are actually
10:38powered by this uh technology today. And
10:41uh these uh documentation sites can be
10:43hosted uh either by uh stainless on our
10:46infrastructure uh or it is at the end of
10:48the day just an Astro site. So you can
10:50uh take the code that's generated by
10:52stainless uh hosted anywhere you want
10:55and again because it's built on Astro
10:57you can hack it, customize it, integrate
10:59it into whatever uh you know whatever
11:01environment uh makes sense. Um what you
11:04get uh with the docs um is uh a couple
11:08of things. uh you do get automatically
11:11gen autogenerated uh API reference. So
11:14in addition to just uh rest API
11:16documentation
11:18uh you also get sort of SDK specific uh
11:21documentation. So um most uh
11:24documentation sites will have like
11:25multi- language uh code snippets. Um but
11:28oftentimes you kind of have to map
11:29between the SDK uh to like the REST API
11:33documentation as it exists on the site.
11:35Um, one of the really cool things is
11:36like within the documentation, if you
11:38have a TypeScript selected, say, um, you
11:41can actually like click through to the
11:42different uh, types and kind of
11:45understand exactly like what the
11:47TypeScript interface looks like in
11:49addition to just understanding like what
11:50the, uh, what the REST API behavior is.
11:54Um, another thing that's really cool,
11:56um, and ends up being, uh, useful in the
11:59context of, uh, like an MCP server where
12:01you want to, uh, describe how your API
12:03works is you can author your, uh,
12:05narrative docs, um, in the same like
12:07using the same tooling. Um, so we have,
12:10you know, built-in widgets and other uh,
12:13components that you might expect in like
12:15something like a docsurus or a mintfi um
12:17that you can use to manually construct
12:20uh, document documentation as well.
12:23And then maybe the last demo bit before
12:25we can uh stop for questions again is uh
12:28the generated uh MCP server uh that you
12:32get for your API. Um so as a part of the
12:35TypeScript uh SDK um you can also enable
12:39the generation of an MCP server that
12:42will uh enable uh uh agents like whether
12:46it's a cursor or codecs or clog code or
12:48what have you uh to accurate uh generate
12:51accurate uh like API integration code
12:53for your uh for your API uh based on the
12:56most recent version of the spec and the
12:58uh and the SDKs. Um there's also like
13:01kind of an optional experimental like
13:02code execution layer as part of the uh
13:05MCP server as well. Um where uh you can
13:08with pretty high accuracy like actually
13:09have agents um operate the API uh by
13:12generating code using your SDK uh to
13:15generate you know arbitrarily complex uh
13:18workflows. uh which ends up being quite
13:20a bit more accurate than you know
13:21defining you know hundreds of different
13:23tools uh and also more accurate than
13:26like manually writing uh you know fetch
13:28requests or like interacting with the
13:30HTTP API uh directly um because of the
13:33advantages of writing like uh you know
13:35good error messages and types that the
13:37the model has to work with um with the
13:39SDK. So uh th those types of interfaces,
13:43those agent interfaces, developer
13:45interfaces through SDKs and docs are
13:47kind of what Stainless helps you
13:48generate. Um so yeah, I'll stop there
13:51and I think this would be a good time if
13:53folks have questions or other stuff that
13:54we wanted to see in greater detail.
13:56That'd be great.
13:59Uh Pavon maybe.
14:02>> Yeah, thanks and thanks Kevin and Alex.
14:04That's actually good uh intro. Couple of
14:07questions I have. Uh first one is uh you
14:10guys said okay you'll take from the API
14:14uh spec and then some spec and stainless
14:17around what the SDK should do. um would
14:20make sense uh for I could see how it
14:22would work for a thin SDK where all it
14:25does is take the request and directly
14:27hit the end point. But um if SDK has
14:30more more logic around it like batching
14:33offline operations or like pulling stuff
14:37and doing some transformations on the
14:39stuff or like how how do you handle it?
14:45>> Yeah, great question. Um so um as sort
14:47of Kevin was was noting one of the
14:50things that we really try to do is um uh
14:54let you sort of think of the SDKs that
14:56we generate as as almost like a platform
14:57that you can build on. Um and so uh in
15:01in a lot of cases people sort of expect
15:04everything in the API to have a direct
15:06translation to the library right um in
15:10some APIs that's totally sufficient.
15:13people don't expect or want anything
15:15more. In others, there's some or
15:18sometimes a lot of much richer, you
15:21know, functionality that a developer
15:23would want or expect. The the examples
15:25you gave um uh you know, batching
15:29offline, etc., um are
15:33great um great examples of that. Um, and
15:38the fact that you can take a generated
15:40repo from Stainless and edit it as if it
15:43was not a generated repo is where you
15:45can then um, kind of add any of that
15:48higher level functionality that you want
15:51um, as you would to any repo. Um, and
15:54here you know the advantage is basically
15:56you don't have to deal with all the
15:58other stuff, right? So, u, you can
16:00compose um, the generated code as you
16:03want. Uh the example on the screen here
16:05is from OpenAI. Um we have a number of
16:08these kind of like custom helpers um in
16:10this case helping with um structured
16:12outputs um and and tools um where we are
16:18able to offer this parse method which is
16:20totally handwritten uh and much higher
16:22level. Um and uh we're also working on
16:29um some sort of like AI prompts that
16:31help people translate from one
16:33programming language to another with
16:35these high level um high level methods.
16:38That's something that we kind of help
16:39some customers do by hand today. Um so
16:42you know you might have a team that
16:43knows TypeScript well or knows Python
16:45well or what have you. they can get in
16:47there and produce something that makes
16:49sense for that programming language and
16:51then we can kind of, you know, we're
16:54working on tooling that'll automatically
16:55help people. Um but for now sometimes
16:58we'll just get in there and help folks
17:00say okay let's first ensure that we have
17:03sufficient test coverage then let's
17:05translate over the tests then let's
17:07translate over the implementation you
17:09know then let's make sure that there's
17:10appropriate docs and everything and do
17:11all of that with you know something like
17:13a cloud code prompt um to kind of you
17:16know often people really want a large
17:18number of programming supported and
17:20don't have the bandwidth to to handw
17:22write um higher level helpers and all of
17:24those and maintain them Um is that kind
17:27of what you're looking for?
17:29>> Uh that makes that that was uh because I
17:32think in my understanding usually the
17:35APIs that SDK provides and the
17:39HTTP rest endpoints that the SDK sends
17:42data to is normally not one to one.
17:45usually would have lot more APIs and lot
17:48more things that could be tweaked
17:50independently on the SDK side versus how
17:53so then SDKs maybe it's unique to
17:56amplitude we have a bunch of SDKs and um
17:59we the SDKs basically do the object
18:02management as well so that they could
18:04actually set it independently and then
18:06it kind of handles the batching and all
18:09that stuff and our rest endpoint is like
18:11a very simple one where it expects all
18:14the data every time kind of situation
18:17where the users uh who are instrumenting
18:19our SDKs wouldn't probably want to send
18:21every detail with every API. So there is
18:24like different object management um
18:26batching storage and like networking
18:30rate limiting and all the other stuff
18:32that kind of goes into and some of them
18:35are platform dependent too like what you
18:37use for the storage or like other stuff.
18:39So I was kind of curious how you'd
18:41handle it.
18:43Yeah, again it's it's sort of like we'll
18:45provide that base um of of um direct
18:50rest mapping oftentimes uh and then and
18:53then if you want higher level you know
18:56object-oriented mappers um uh
19:00things that wrap together a number of
19:02endpoints get more stateful etc that you
19:06would do on top there are there are um
19:08you know it really depends on the API
19:10and the use case it's actually something
19:11that we see relatively rarely
19:13um to the depth that you're talking
19:14about, but it it definitely happens and
19:16and Amplitude would not would not be
19:18alone in that. Um so APIs that are
19:22closer to a database um or other areas
19:25where we'll see some similar patterns
19:26there. Um uh but yeah, things like rate
19:30limiting um a lot of the networking
19:32stuff we will handle kind of in our
19:34level. Um, and then the other stuff on
19:37top of that, it it just isn't really um
19:41reliably something that can be
19:43generated. Um,
19:45>> makes sense.
19:46>> The judgment calls around how the
19:50different objects map and especially to
19:52the idioms of the programming language
19:54um [clears throat] tend to be quite
19:56bespoke. Um, and so that balance tends
19:58to um that's how we've seen that kind of
20:01like work well.
20:04>> Yeah. Cool. One other question I have uh
20:06you lightly touched and want to maybe go
20:09hear more detail is um nowadays the SDKs
20:13using SDKs to actually code write the
20:16code. A lot of it is probably done by
20:17the AI AI as well and you they just pick
20:21from the internet and is MCP is the way
20:25that you guys are making sure that AI
20:28picks the latest and greatest and great
20:30examples that we want them to use or do
20:33you guys are looking at skills or like
20:35want to hear more on like how how you
20:37guys are making sure that AI is actually
20:40in using the SDKs in the right way. Uh
20:44yeah, this is this is a great question.
20:46So so for anyone building an API and
20:48wanting an agent to integrate well with
20:50it
20:52looking at the agentic enablement we
20:53like to call it holistically is really
20:55important. Um and there are a number of
20:57tricky things. you you hit the nail on
20:59the head with one of the most kind of
21:01pernicious and annoying which is that
21:03the agents um kind of by default are
21:05going to maybe download the wrong
21:07version of an SDK, some random version
21:09or hallucinate um different parts of the
21:12API or um will sort of assume they're
21:16on, you know, version 2.20 whereas the
21:21user is actually on version 2.40 and
21:23things are different now. um all sorts
21:25of things like this. And so and that
21:28just gets to be such a pain and you know
21:30at that point you know you don't have
21:32autonomous integration happening at all.
21:34You have a developer who's like trying
21:37to get up to speed with large amount of
21:39you know LM code while also trying to
21:42read your docs while also trying to
21:44catch up with with the SDK docs or or
21:46what have you. Um and and it can turn
21:48into a mess. So it's really important to
21:50be able to offer something where the
21:53model will kind intuitively discover
21:57um uh the right way to find the right
22:01information um that's up to date and
22:03current. Um so there's a number of
22:06things to do there. Um and different
22:09coding agents might act differently.
22:10Different model numbers might act
22:12differently. You know a model in the
22:14future might behave differently than the
22:16models of today. And so I think it's
22:18important to have bases covered. Um I
22:21think we're not yet publishing skills on
22:23behalf of our of our customers, but
22:24that's something that's coming soon. Um
22:28uh the doc site that Kevin was showing
22:30earlier, actually Kevin, I don't know if
22:31you want to pull one of these up. You
22:33can replace, you know, you can just add
22:35MD to the end of any of these URLs,
22:38right? Um and we see that sometimes
22:40agents will sort of figure that out. Um
22:43and um
22:47uh
22:49you can do and and I think [snorts] the
22:52versioning
22:53maybe it's not on the pet store. I'm not
22:55sure.
22:56>> Yeah, sorry. I generated this one a
22:58while ago. Um I see we did that.
23:01>> It should work on um you know open open
23:03I would imagine. Um could be could be an
23:06example. Um but um
23:11uh we'll see that models kind of like
23:14will just look up the docs um and and
23:17this can help um or those stocks like
23:19will be linked in the repo of the
23:21package. So if the if the model can find
23:24uh the SDK, it'll actually be able to
23:26see in some cases, oh here's this Python
23:30library. Let me go see if there's
23:31documentation for that for that version.
23:33Um and so we're shipping a version
23:35selector. what people where you just
23:37pick the docs for the exact version of
23:39the library that you're working on. Um,
23:43and uh, especially with with the way
23:46that, you know, API versions tend to
23:48evolve
23:49in a way that's less transparent, having
23:52those SDK versions, you know, um, gives
23:55people something concrete to to pin to.
23:57Um, and um, and so that's something
24:01that's that's helpful. Um
24:06>> OpenAI does have like a completely
24:07custom um implementation of
24:10>> I see. Okay. Okay.
24:12>> I think they've like they're swallowing
24:14those routes.
24:15>> I mean we we all know what uh uh what a
24:17markdown file looks like. So [laughter]
24:20So that's right. Um
24:24uh but um
24:28uh yeah, MCP is another surface that we
24:30expose this through as well. Um, and so
24:33yeah, so so we'll, you know, when you
24:36produce an MCP server, users can say,
24:38hey, I'm using the Java library or
24:40you're using the Python library or what
24:42have you. Um, how do I do this? And that
24:44will search the docs that will produce
24:46the same the same markdown that you
24:48would see um on the doc site is also
24:51accessible through the MCP server. Um,
24:54and so that could be a more surefire
24:55way. Um, it does have a a setup step
24:59involved, right? like the developers
25:01have the MCP server. Um sometimes that's
25:03quite trivial. Sometimes people don't do
25:05it. Um and so you know from our
25:07perspective you want to have all your
25:08bases covered have MCP have skills have
25:12just like an LMS.txt withdown files on
25:16the website so that the model can just
25:18you know crawl and find it there too. Um
25:21and and one other thing that we've seen
25:22work as well um actually is just you
25:25know the benefit of having uh SDKs and
25:29libraries is that you know coding agents
25:31are are good at recode and so sometimes
25:33we'll we'll observe that they just read
25:35the source of the Python library or they
25:37read the source of the text library at
25:38hand um and then they very quickly get
25:41to what they're looking for um in in a
25:44very predictable way um and so um
25:49you So as a developer I I might not
25:52always want to have to do that but in in
25:54some situations that ends up being
25:56smooth as well.
25:58>> Okay. If you basically have more inline
26:00documentation in the libraries or at
26:01least
26:04in the languages where the whole code
26:06gets pulled in and
26:09agent can see the right version of the
26:12code then maybe
26:14>> if if your code is legible. Right. So,
26:17one of the one of the problems that we
26:18were encountering, you know, when I was
26:20at Stripe and we were looking at, can we
26:21can we use an off-the-shelf codegen
26:23system, you'd have the most basic, you
26:27know, CRUD endpoint of creating a
26:29customer or something and it's a hundred
26:31lines long and it's totally unreadable,
26:33you know, just creating a HTTP request
26:35and it's like, what's going on here? And
26:37so, you know, Kevin, I don't know if you
26:39can pull up um a basic CRUD for the
26:42source of open air or something, but um
26:45you know, it'll be like one line long of
26:48something like that. And so if if you
26:50have readable
26:52source code that's like well documented,
26:54has dock strings on everything,
26:57we consistently find that basically
26:58everything that helps a developer is
27:00helpful to an agent as well.
27:02um you know sometimes it takes a
27:03slightly different path but um yeah with
27:07a with a caveat of the SDK has to be
27:08reasonably good. Um yeah models can just
27:12read source code and and depending on on
27:14on the model the the agent that can work
27:17quite well. Um,
27:21>> okay.
27:22>> Yeah. Um, so streaming is actually
27:23pretty complicated, but still it's um
27:26it's it's a relatively concise um
27:31um
27:34yeah method body here. You just see
27:36cancel. Okay,
27:38we're sending a post request to the
27:39cancel endpoint.
27:45Was that helpful, Puffin? Yeah, that's
27:47that was helpful. Yeah, I think it's
27:48definitely evolving. So, expecting soon
27:52we'll probably would have new ways that
27:54the foundational model companies would
27:56ask us to share information.
27:59>> I know. I know. Yeah. It's something
28:02that we stay very on top of um and are
28:05always, you know, we obviously work
28:06closely with with pretty much all of
28:08them. Um and uh it's a fastmoving space.
28:12Um, and so it's just something where,
28:14you know, we work to keep keep on top of
28:17it for for all of our customers. But,
28:19um, it does it doesn't frankly quite
28:20feel like we've landed on the perfect
28:22thing yet.
28:23>> Yeah. Yeah. I think yeah that that's
28:25that that's my take too. That's why I
28:27was curious about your thing too because
28:29internally amplitude SDKs uh like I our
28:32team as part of the activation we get we
28:34have a bunch of SDKs and different
28:36languages and one of the things were
28:38kind of the top of the mind and we
28:40didn't really do anything because we
28:41didn't know what is the right solution
28:43is like how do you make sure that agents
28:45get always the right documentation. Uh
28:48right now if you're like oh I don't have
28:49any control over it. It basically does
28:52its own internet search and then finds
28:54stuff and then finds the git repo and
28:56then tries to do best and yeah.
29:01Yeah. The the Okay. Yeah. The the MC
29:04when the MCP servers that that we do
29:06with the dock um especially you know uh
29:10with the right version um that's worked
29:12really really well. Um yeah, we we we
29:15see that models can a agents can like uh
29:20produce the right code a very high
29:21percentage of the time with with with
29:22that solution. Um
29:26>> okay.
29:26>> Yeah, it it's it's taken some prompting
29:28around
29:31you know teaching it how to search the
29:34docs well uh and stuff like that. Um and
29:36of course you have to like set up the
29:38the right index and
29:40and all of that. Um but uh it's not free
29:46out of the box um when if you know if
29:48you're building it yourself. Um but you
29:50know that's that's now in our in our MC
29:52in our MCP product and so kind of does
29:56come free box.
29:58>> Nice.
29:59>> Cool. Um I took a lot of time. Thank
30:01you. Thank you for answering the
30:02questions.
30:03>> Yeah. Quite quite enjoyed them but yeah
30:05would love to open to the floor to
30:07others.
30:11Thanks. Maybe I'll go next. Just uh
30:13switching gears just a little bit.
30:14Thanks both for really good
30:15presentation. I like the interplay with
30:16the demos. Um can you talk about like
30:19suitable scale for uh for like a
30:21stainless client project? Is this really
30:23mostly built for like big big players
30:25like OpenI Anthropic? What about like
30:27somebody has a small SDK maybe just 10
30:29commands or small API just a few
30:31endpoints? Is is would this be a
30:33suitable offering like scale-wise?
30:36>> Yeah, absolutely. Yeah. Um, and in fact,
30:38we have a a free tier. Um, it's pretty
30:39generous, I think. So, for a handful of
30:41endpoints, um, not only can use it, you
30:42can use it for free. Um, uh, and I think
30:45we've got I think we've got like a 500
30:48free tier users or something like that
30:50that that are regularly publishing SDKs.
30:52Um, if I remember correctly. So, we see
30:55a ton of startups,
30:57you know, or or whoever seeing a lot of
30:59success um, with that. And we never hear
31:02from them um, but it seems to be working
31:04out well. Um, and you know, um, I think
31:07that we we always have more work we want
31:09to do on our documentation, uh,
31:10ourselves, but I think I think it
31:12probably implies that they're they're
31:13able.
31:14>> Very cool. And the docs, uh, like the
31:16Astro docs that comes part of that
31:18initial offering. Very cool. Very cool.
31:20>> Yeah.
31:21>> Thanks.
31:24Um, yeah. I mean, you know, it's one of
31:27the annoying things with APIs in
31:29general, is as I'm sure we're all very
31:31uh aware is
31:34whatever choices you make, you kind of
31:36want to get it right up front rather
31:38than so many other things in software
31:39where you can ship something and then
31:41iterate from there. Um and uh one thing
31:45we see is that you know when when teams
31:47choose to kind of start the right way
31:49with their API program whatever that may
31:50be whether that's choosing the right
31:52pageionation design you know what I mean
31:54or um the right way to do SDKs or
31:57something like that having the first
31:59launch you know as things are in an
32:01earlier stage um already have the right
32:05foundation it makes it so much easier
32:06because you don't have as much migration
32:08cost which can just be such a pain um
32:11later down the line And so yeah, we we
32:14we really try to make sure that folks
32:16who are who are early in the API program
32:17or have something smaller um are able to
32:20kind of get off on the right foot um
32:22without without a lot of headache.
32:24>> [snorts]
32:24>> Um there's there's help that we provide
32:27for as well. Um but that that tends to
32:30be, you know, more hands-on.
32:47Uh
32:48any any questions already, Tony?
32:53Anyone?
32:56I didn't have a bunch of stuff coming in
32:59and I think you guys covered a lot of it
33:01already actually um in the discussion.
33:06>> Great.
33:09>> Thanks.
33:11>> Actually, I'll I'll uh I think I have
33:13one on the fly here. So, the title of
33:16you know this session is called how to
33:17build worldclass APIs. want to flip that
33:20around a little bit sort of and and ask
33:24how would you guys define a worldclass
33:25API versus
33:27standard fair API?
33:32Uh I love that. Yeah, I mean there's
33:42I think the standard fair API that that
33:44that a lot of developers experience out
33:46in the wild as they're building um and I
33:48think that that we've all probably
33:49encountered um involves a lot of
33:52messiness. Um I think the the sort of
33:54like
33:57lowest common denominator API that
33:58people tend to see out there is is
34:00pretty underspecified. might be
34:02difficult to tell what's going on. You
34:03might see a lot of inconsistency across
34:05different parts of the API. Um or you
34:08might have consistency in a way that
34:10that can be frustrating um or limiting
34:13um and um you may have
34:20interfaces that are generally like not
34:22so discoverable. Um and so uh what
34:26happens there is you know obviously
34:29people building APIs are investing all
34:31this engineering resources into the
34:33backend functionality into into all the
34:36capabilities but then you have um
34:39friction you have sort of a bottleneck
34:40at adoption where people maybe can't
34:44easily discover or adopt um the great
34:47features that have been shipped. Um, and
34:51um, I think if you compare
34:55that kind of like lowest common
34:56denominator world to a worldclass API,
34:59um, what you're going to see is that
35:01it's really easy to find what you're
35:02looking for. It's really easy to
35:04discover the interesting functionality.
35:06It's easy to to adopt it. Um, and things
35:09tend to be consistent from one part of
35:11the API to the next. Um, in a way that's
35:14that's pretty uh intuitive. Um,
35:18Kevin, is there more that you would add
35:19there?
35:23>> Yeah, definitely. I think the like for
35:26an API first uh company like the
35:31uh one one way to like look at it is
35:33like your API that you provide like to
35:36be considered uh like world class in the
35:39same level as like a stripe or a Twilio.
35:41um should be concerned with like uh
35:43providing extremely high utility like
35:45relative to the effort that you have to
35:47put in. Um this is sort of consistently
35:50true with a lot of the very successful
35:51API platforms out there where um with a
35:54single line of code uh using a Tulio SDK
35:57uh you can send a text message which is
35:59an incredibly uh complex thing to do um
36:02under the hood. Um so really great APIs
36:04have a great way of like starting off
36:07very simple and providing a tremendous
36:09amount of utility and then scaling up
36:12well from there. Uh such that the amount
36:14of value you get out of the API uh
36:17scales up in a favorable fashion with
36:19the amount of effort that you have to
36:20put in to um put in to actually use it.
36:24um with a like for a API service
36:26provider again like somebody closer to
36:28like an OpenAI or a Twilio um you also
36:31need to be able to demonstrate like a
36:33tremendous amount of leverage over what
36:35it would take to kind of stand up the
36:36same infrastructure um to to run it
36:40yourself. Um which is kind of what like
36:42the reason why you know people pay
36:44exorbitant sums to Data Dog. uh because
36:46uh to stand up a stack that is as
36:48capable as something like data dog will
36:50be prohibitively expensive to have like
36:52a solution that um is as performant is
36:55as complete um has the same level of
36:58reliability. Um so the uh you know the
37:01cost the the total cost of like having
37:03API infrastructure that does the same
37:05thing um is is so high that it would uh
37:08it would be insane to use um anything
37:10else. Um and then like developer
37:12experience is definitely the third uh
37:14component of that uh where if you
37:16actually care about your API being
37:18adopted um you need to care about things
37:20like uh sort of cognitive uh overhead of
37:23like a developer that's learning how to
37:25use the API. Um every new feature um
37:28that you add like every parameter every
37:30endpoint like kind of adds to the amount
37:33of cognitive load that a developer um
37:36has to carry in order to use the API.
37:38Um, so like adding features to that
37:40surface area uh should be treated kind
37:42of like adding weight to the space
37:43shuttle. Um, you can't just add things
37:45willy-nilly. Um, every every parameter
37:48has to be like pulling its weight in
37:50order to like earn its spot in the in
37:52the API. Um, you also kind of need to go
37:55to where developers are um to like in
37:57the world before agents it meant uh and
38:00continues to mean like having SDKs
38:02across a broad range of programming
38:04languages or the ones that are most
38:05important to your community. uh in the
38:08age of agents it means uh providing MCP
38:10server skills um you know being present
38:13on the skills.sh registry um and and
38:17that's something that like a a platform
38:19like stainless helps you accomplish kind
38:21of putting your uh interfaces in the
38:24places where they need to be.
38:31I have a followup on that one. Uh
38:32although I see this meeting or some sort
38:34of timer ticking down at 20 seconds. I
38:36don't know.
38:37>> I know it's intimidating, right? But I
38:38[laughter] think I think we won't get
38:39kicked out.
38:40>> Is that when we get ice cream social
38:41afterwards or
38:42>> Yeah.
38:43>> Um, you know, so it's um
38:47there's been a lot of talk about what's
38:49called AI technologies very broadly,
38:52right? Including MCP service like that.
38:54One of the things I think is interesting
38:55is
38:58what's happening.
39:00>> I I think we can keep going [laughter]
39:04for another minute or two. Um but if
39:05anyone has a drop on
39:08>> there I'll make this quick. You know the
39:11thing that I think about is um you know
39:13sort of like AI slot for APIs which is
39:16to say you know the value of APIs being
39:19consistent and discoverable and let's
39:23say in some ways well documented or
39:25design designed for uh like audit and
39:29logging in more highly regulated
39:31environments. How much that do you guys
39:33think sort of disappears in the universe
39:34where a lot of it is just hey AI go find
39:37the right you know APIs it doesn't
39:39matter if it's discoverable because it's
39:40going to find it.
39:44>> Yeah it's a I mean it's a good question.
39:46Um I think like the uh we're pretty far
39:49away from the models being like like
39:52they are pretty good at some like needle
39:53and haystack uh situations, but there's
39:56also like just a cost of like uh context
39:59like you have to manage like how much um
40:01the model can actually reasonably
40:04comprehend with any given turn. And the
40:06more information you shove into the
40:08context, the dumber the model gets um
40:10over over time. Um, so to the extent you
40:13can like expose a smaller slice of
40:15content to the model, it's going to
40:17perform better initially and over
40:18multiple uh multiple turns. So having
40:21like a really chatty API uh is also a
40:24really great way to like if you have to
40:26do 20 API requests uh to accomplish a
40:29workflow uh that's 20 responses that are
40:31in your context window that uh degrade
40:34the performance of the model over time.
40:36So I think like efficiency of
40:37communicating with an API is going to
40:39continue to be important for a while.
40:43Yeah, I wonder how that's how long
40:44that'll be that'll be true for. It's
40:46just the thing I think about a lot as
40:48you know a leader of teams and like the
40:52the sort of gotcha news of the software
40:55engine software engineering discipline
40:57is dead and then all software engineers
40:59go h pretty much the exact opposite in
41:02fact.
41:04>> Yeah, exactly.
41:06>> Yeah.
41:07>> Anyway, thank you guys for this. It was
41:08really interesting a really interesting
41:10conversation.
41:11>> Thank you, Arty.
41:12>> Sure.
41:15>> Okay. Thanks, Paul. Cheers.