The value of clay is is not its code base IMO. Clay connects many providers that each have licenses starting around $100-150/mo. Even if you open source your solution, users would still have to purchase subscriptions individually, manage their usage, etc. This can get expensive quickly. On top, it takes time and is annoying. Lastly, there's complexity to self-hosting the AI and web scraping stuff. I'm unsure if there are many GTM teams willing to put up with hosting this themselves.
Fun fact, you can actually rebuild the entire core functionality of clay using https://pipe0.com with ~1000 lines of code.
Thanks for your feedback.
Many people are already used to using different tools to achieve their data enrichment goals
but those who use something like clay to simplify the use of these tools
In my opinion, a tool of this type is like an overlay see make and n8n but at its simplest
Thanks for that. Took a look at it, and... it doesn't handle 3.1 documents correctly. One of the major defects in the OpenAPI document spec pre-3.1 is that you can't put descriptions on any usage of a model in your API. I mean... WTF?
So if you had a data structure called User, and you used it to represent users in different roles in your API somehow, you can't annotate the instances of User in your document to say what kind of user you're talking about. You can annotate the elements inside the User model (like strings, numbers, or whatever) but not usages of the model itself. Before version 3.1, this blunder rendered OpenAPI half-useless for one of its core purposes: documenting your API.
API-Fiddle acts as though that's still true. There is no Description button anywhere in your schema alongside any use of a model.
We're trying to build the best tool out there for team that want to build api-first and speed up development and code generation this way.
I'm happy you wrote this article!
Here are a few questions for you:
- Do you think the mock API is the best way to get Feedback from stakeholders?
- How do you merge your changed OpenAPI document into your master documentation when it's time for prod?
- How do you share your draft contract with e.g. a frontend engineer so they can get started building the UI?
Yeah, I think even if you are fairly technical it's still pretty hard to manage a growing OpenAPI doc that is good enough to generate clients, sdks and docs from it.
I think that we'll soon be able to help you generate mock clients as well. Probably by generating a first pass with AI and letting you adjust the details manually. This way it could be one-click.
I think this is a good intro into OpenAPI contracts. What generally sells people into OpenAPI is:
1.) The ability to document things with tools like swagger ui, api-fiddle, scalar
2.) The ability to automate things with auto-generated api-clients, mocks, tests
3.) The ability to secure things with tools like Cloudflare API Shield
3.) The ability to go api-first and speed development up
I agree. API-first is the way! Change your schema, auto-generate types into your code and use them for your server definition. It's just faster and more secure this way. Use api-fiddle.com or spotlight.io to work with the schemas (branching, sync with Github).
In a fully typesafe world, it should be pretty hard to derive from the shema this way.
This article is awesome and resonates with my experience! I used to work for one of the big cloud vendors. We frequently had doc writers in our sync calls. Quite frankly, they never had a chance! Much of our documentation, our errors, status codes etc. was burried in the code and we (developers) were simply to busy to work effectively with technical writers.
Don't get me wrong here. Where I say "busy" I don't mean their work wasn't important (it was!) but we had our own projects and jumping on a call to improve errors messages is not too exciting for most of us - and it's not the stuff that drives promotions. As a develper it's simply to easy to gatekeep code.
Now follows a shameless plug: I'd be so excited to hear your opinion about a tool I'm building. It's called https://api-fiddle.com. Conceptually, it should help developers work API-first instead of code-first. It's great for devs because it makes the work faster and safer. BUT, an added benefit is that API docs are no longer burried in code and technical writers have a nice interface to contribute to them (and hold devs accountable!).
Dieter Rams’ design philosophy encourages simplicity, honesty, and functionality—values that translate beautifully into the world of API design. By applying these 10 principles to REST APIs, developers can create APIs that are not only functional and efficient but also enjoyable and intuitive to work with.
