Orca V1.1 Auto API Docs by Frequency - Stop writing API docs. Let traffic do it.
by•
Orca watches your live API traffic and auto-generates documentation ranked by real usage - so your busiest endpoints get documented first, and nothing you actually ship goes undocumented.
Replies
Best
Maker
📌
Hey Product Hunt 👋
Giorgi here, back with ORCA V1.1.
When we launched, ORCA answered a question most teams couldn't: what APIs are actually running in production? Passive traffic analysis from a mirror port - no agents, no SDKs, nothing touching prod.
But discovery surfaced a second problem. Once you show a team 120 endpoints where their spec claimed 40, the next question is always: "okay… so what do these actually do?" And nobody wants to hand-write docs for 80 endpoints they just found out about.
So V1.1 writes them for you.
ORCA now auto-generates API documentation directly from observed traffic - real request/response shapes, real parameters, real auth patterns. And it ranks by frequency, so the endpoints handling thousands of calls a day get documented first, instead of the one someone hit twice in a staging test. Live traffic in, OpenAPI out.
Still fully on-premises. Still agentless. Still built for banks and government clients who can't ship traffic to someone else's cloud.
The part I find funny: the docs ORCA generates are usually more accurate than the ones people wrote by hand, because traffic doesn't drift from itself.
Would love to hear how you handle API docs today - hand-maintained specs? Generated from code? Given up entirely? (No judgment on the last one.) Happy to dig into the architecture, how the frequency ranking works, or anything else. Fire away!
Report
honestly this looks really clean for teams that don't want to touch production code. one thing though - would be great if you could plug in threat intel feeds directly so the DNS exfiltration detection can flag known bad domains out of the box instead of just catching the pattern
Report
Maker
@rabiasa3v Thanks Rabia! Threat intel feed integration is on the roadmap and fits cleanly - since everything runs on-prem, we can match against known-bad indicators (domains, IPs, JA3/JA4) locally without calling out to a third-party cloud, which the banks and gov clients need anyway.
Appreciate the suggestion - abuse.ch (URLhaus/ThreatFox) is exactly the kind of feed that fits this model, so it's going on the shortlist.
Report
The mirror port approach is clever for avoiding deployment headaches. One thing that would make this even more useful for us is a visual diff between API versions, so we can quickly see when a new endpoint pops up or an existing one's behavior changes, instead of just getting a flat list of what's currently running.
Report
Maker
@remzi698130@remzi698130 Love this - it's the natural payoff of docs from traffic instead of code. We can snapshot specs over time and diff them: new endpoints appearing, ones going silent, behavioral drift on existing ones (new param, changed response shape, an auth check quietly dropping). And since it's frequency-ranked, we can flag significance - a new endpoint taking thousands of calls/day matters more than one hit twice in staging.
Definitely going on the roadmap. I'm leaning toward a passive view you check rather than pushing everything to alerts - keeps it from getting noisy. Though one idea I like: let you set a frequency threshold, so only changes above a certain traffic level push to Slack/webhook, and everything else just sits in the passive view.
Replies
honestly this looks really clean for teams that don't want to touch production code. one thing though - would be great if you could plug in threat intel feeds directly so the DNS exfiltration detection can flag known bad domains out of the box instead of just catching the pattern
@rabiasa3v Thanks Rabia! Threat intel feed integration is on the roadmap and fits cleanly - since everything runs on-prem, we can match against known-bad indicators (domains, IPs, JA3/JA4) locally without calling out to a third-party cloud, which the banks and gov clients need anyway.
Appreciate the suggestion - abuse.ch (URLhaus/ThreatFox) is exactly the kind of feed that fits this model, so it's going on the shortlist.
The mirror port approach is clever for avoiding deployment headaches. One thing that would make this even more useful for us is a visual diff between API versions, so we can quickly see when a new endpoint pops up or an existing one's behavior changes, instead of just getting a flat list of what's currently running.
@remzi698130 @remzi698130 Love this - it's the natural payoff of docs from traffic instead of code. We can snapshot specs over time and diff them: new endpoints appearing, ones going silent, behavioral drift on existing ones (new param, changed response shape, an auth check quietly dropping). And since it's frequency-ranked, we can flag significance - a new endpoint taking thousands of calls/day matters more than one hit twice in staging.
Definitely going on the roadmap. I'm leaning toward a passive view you check rather than pushing everything to alerts - keeps it from getting noisy. Though one idea I like: let you set a frequency threshold, so only changes above a certain traffic level push to Slack/webhook, and everything else just sits in the passive view.