Launched this week

SpecGuardian API validator that works

Launched this week

Validate API requests & responses against your OpenAPI spec

12 followers

Validate API requests & responses against your OpenAPI spec

12 followers

Visit website

It's an OpenAPI 3.x reverse proxy that validates HTTP requests and responses against your spec. Invalid requests get rejected with 422, bad upstream responses return 502. All with structured RFC 7807 error details showing exactly which field failed and why. Drop it in front of any REST API. No code changes needed.

SpecGuardian API validator that works gallery image

Free

Launch tags:API•Open Source•Developer Tools

Launch Team / Built With

Zernio WhatsApp APIBuild WhatsApp features & agents in minutes

Promoted

Maker

📌

Hey Product Hunt! 👋 I built SpecGuardian because I ran into a frustrating wall at work. We were using Stoplight Prism as a validation proxy in our integration test pipeline and it kept letting invalid responses slip through. The culprit? nullable: true on a $ref. Prism just doesn't handle it correctly. Same story with anyOf, oneOf, and allOf. All things that show up constantly in real-world APIs. I spent more time fighting Prism's false positives and missed validations than actually catching real spec violations. At some point I thought: how hard can it be to build this properly? That question became SpecGuardian. I also had a personal reason to build it: I've been wanting to write something meaningful in Go for a long time. I work primarily in PHP and had dabbled with Go before, but never shipped anything real with it. This felt like the perfect project. Small enough to actually finish, complex enough to actually learn something. SpecGuardian uses kin-openapi under the hood, which handles all the tricky schema composition correctly. The proxy itself is built on Go's net/http/httputil.ReverseProxy. It's not trying to be Prism. It doesn't mock responses. It does one thing: validates requests and responses strictly against your OpenAPI spec, and tells you exactly what's wrong in RFC 7807 format. I'd really appreciate a ⭐ on GitHub. It means a lot as a first Go project shipped publicly! Would love feedback from anyone running OpenAPI specs in staging or CI pipelines. Happy to answer questions below!

Report

2d ago

API issues usually become expensive long before anyone notices them.

Curious—what's the most common mistake you've seen teams repeatedly make with OpenAPI specs that SpecGuardian catches early?

Report

12h ago

honestly the RFC 7807 error details are exactly what i've been begging for at work, makes it so much easier to figure out which field actually broke. dropped it in front of our staging api in like five minutes.

Report

20h ago

Would love to see a mode where you can dry-run it in shadow mode and just log validation failures without rejecting anything, super helpful for safely rolling it out in front of legacy services that might have weird edge cases in their docs.

Report

18h ago

The RFC 7807 error format with field-level failure details is genuinely well thought out, makes debugging upstream contract drift way less painful.

Report

17h ago