Octri.dev
Generate customizable Docs, SDKs, MCP server, and monitoring
179 followers
Generate customizable Docs, SDKs, MCP server, and monitoring
179 followers
Upload an OpenAPI spec and Octri (octri.dev) generates a customizable documentation site, SDKs in ten languages (TypeScript, Python, Go, Rust, Ruby, PHP, Java, Kotlin, Swift, Dart), and an MCP server for agents. Each SDK carries an error reporter that ships switched off. Once its developer turns reporting on, failures in their app can reach the API owner with a readable stack trace tagged to the SDK release. GitHub sync regenerates docs and SDKs when the spec changes.
This looks super useful ! Having the SDKs report their own failures back automatically is a massive time saver. Quick question : how hard is it to add custom CSS to the generated docs site ?
@axel_paulin Thanks a lot Axel! You can easily add custom-CSS through our dashboard settings through a simple text-box that takes in your CSS code and applies it to your docs site!
We designed the Studio over 3 years to make it as easy as possible for anyone to go in and customize the docs looks with as little of knowledge about code/CSS as possible!
Also, our UI based customization tool is pretty powerful with all the built-in components, custom components that you can build with it, and the powerful Notion-like docs editor!
Hey @emad_khair Really like the idea of closing the loop between SDK generation and what actually breaks in production. How does Octri handle API changes over time, can it detect breaking changes in the OpenAPI spec and flag which generated SDKs or existing integrations might be impacted before a new version is shipped?
@dounia_boughalem Thanks a lot Dounia!
That's a really good question! Yes, we watch your spec and automatically generate SDKs and update the changelog with what exactly could break current integrations if they decide to update.
in addition to that, we actually have internal build checks, tests, and linting run before publishing. So a problem introduced in a recent update gets caught before the SDK goes out to public! These checks are available on literally all tiers (even free!), so all the SDKs produced by Octri maintain the highest possible quality!
Congrats @emad_khair and @khalidkhairx10 , I saw your post on Reddit and had to come say it here. Three years building it with your siblings is something else, and I like that the SDKs are meant to read like code someone wrote and not like generated code. Just one thought though: what happens to my customizations when the spec changes and the SDK gets generated again? Do they survive, or do I redo them?
@diae Thanks a lot for your support Diae!
Any changes you make for docs or SDKs get protected and survive any future generate! 🙌
the "SDK reports its own production errors back" part is the one I'd actually pay for, docs and SDK generation are table stakes at this point but almost nobody closes the loop on what happens after a user integrates. was literally in a forum thread earlier today about a team shipping a test that passed without ever causing the failure it claimed to catch, and this is the same problem from the other side - an SDK that looks fine in a demo but silently breaks for one specific language or edge case in prod. does the error reporting tell you which generated SDK (language/version) is failing, or just that an integration somewhere is throwing
@galdayan Hi Gal, Thanks a lot!
indeed the monitoring is going to be a great feature to keep teams in the loop and easily identify problems without the back and forth that they usually go through to just identify a small edge case bug!
The reporting is per language and gets deminified and points exactly where the failure is happening! We also auto group all errors to avoid the user being flooded by the same error.
Happy to answer any other questions you have regarding this feature as it's pretty new to the industry to be shipped in a client SDK.
@emad_khair per-language plus auto-grouping covers the two things I was actually worried about - a vague "something failed somewhere" is almost useless once you've got ten SDKs in the wild. auto-grouping makes me curious about one more thing: does it also catch the "same root cause, different symptom" case, like a Python SDK throwing a type error and a Go SDK throwing a nil pointer because the same upstream field went missing - or does grouping stay scoped to one language at a time
I like that the SDKs are not just generated once and left alone. The production error feedback makes the whole workflow feel muh more practical for real API integrations.
@anthony_adams_ Exactly! We also have full info about the monitoring part and it's telemetry if you're interested here: https://octri.dev/dpa/monitoring
This is a really interesting idea! I love how you turn an API into something much easier to work with instead of making developers handle everything manually.
I’m currently building my own software products, and I can already see how something like Octri could save me a lot of time, especially around API documentation and SDK generation.
Really well thought out. Congrats on the launch!
@elghanam Thanks a lot Mohammed for your feedback and support! We are very glad to hear that developers are seeing the value that Octri provides! 🙌