Internal tools nobody wants to document
The most common case: you built an internal tool, it works, and now three other engineers need to call it. APIDocGen turns your endpoint list into a Markdown reference they can read and copy from, without you writing docs by hand. The lower the documentation friction, the more likely the docs actually exist.
Microservice fleets
When one repo holds a dozen small services, each needs a consistent reference or the team loses track of what calls what. Documenting per service from its endpoint list keeps the format uniform, and the Markdown drops into each service's repo. You regenerate when the routes change.
Partner and integration APIs
A partner needs to call your API but doesn't need a full portal. A Markdown reference with per-endpoint examples and auth notes is often enough to get them unblocked. APIDocGen produces that reference from the routes you expose.
Onboarding new engineers
New team members learn an API fastest from a reference they can read and copy. A generated Markdown doc gives them a starting point — example requests they can run, plus the auth header — so they're calling the right endpoint on day one.
Where it fits less well
APIDocGen is built for "I have endpoints, I need a reference." If you need a hosted, interactive portal, spec validation, or API keys, a spec-first or hosted tool is the more honest fit. Use APIDocGen when the job is producing clean Markdown from a list, fast.