DEV Community: Jamal Omotoyosi

Building a "Semantic" API Proxy: How I handled privacy and 200 OK "Lies"

Jamal Omotoyosi — Fri, 27 Mar 2026 06:11:09 +0000

I’ve spent the last few weeks building Inspekt, an AI-powered proxy that tells you why an API failed instead of just giving you raw logs. I hit 100 upvotes on Product Hunt today, and the "Day 1" feedback has already forced me to rethink my architecture.

The "200 OK" Problem:
Standard monitors only trigger on 4xx/5xx codes. But what about GraphQL or certain REST APIs that return a 200 OK with an errors array hidden in the payload?

Inspekt solves this by analyzing the semantic meaning of the response. It doesn't just look at the status code; it audits the entire exchange.

Update 01: The "Visibility & Trust" Patch

Based on community feedback today, I just pushed a major update to the proxy logic.

Local Privacy Scrubbing I realized I shouldn't be sending raw Authorization or Cookie headers to an LLM.

The Fix: I implemented a local scrub() utility. Before the data leaves the server for analysis, it redacts sensitive keys. Your credentials stay on the proxy; the AI only sees [REDACTED].

Transparent Response Schema I refactored the response object to be more "Axios-idiomatic" and transparent. The developer now gets the Full HTTP Exchange alongside the AI’s diagnosis.

The New Schema:
JSON

{
"success": true,
"data": {
"response": {
"status": 200,
"headers": { "content-type": "application/json" },
"data": { /* Raw API response from target */ }
},
"analysis": {
"summary": "One sentence description of what happened",
"status": { "code": 200, "meaning": "OK", "expected": true },
"diagnosis": "Why the server responded this way",
"issues": [],
"fixes": [],
"headers": {
"notable": [],
"missing": [],
"security_flags": []
},
"body": {
"explanation": "What the body contains and means",
"anomalies": []
},
"performance_flags": [],
"severity": "ok"
}
}
}

Technical Challenges:

Context Windows: Handling massive JSON payloads by implementing a custom truncation utility to keep the analysis under 8,000 characters.

Metadata Integrity: Ensuring the analysis object stays mapped to the correct response data even under high load.

I’m still figuring out the "production-grade" side of backend architecture, so I’m looking for some critical feedback.

How are you guys handling sensitive data when passing request context to LLMs? Is a "Deny-List" enough, or should I be looking at Regex for the response data too?

Check the Repo: https://github.com/jamaldeen09/inspekt-api
See the PH Launch: https://www.producthunt.com/products/inspekt

I built an AI-powered API Proxy to explain 4xx errors in plain English

Jamal Omotoyosi — Thu, 26 Mar 2026 18:19:37 +0000

Let’s be honest: 422 Unprocessable Entity is a nightmare when you're in the flow. I got tired of it, so I built Inspekt.

It’s a headless proxy that intercepts failed API requests and injects human-readable AI fixes directly into the JSON response.

Tech Stack

Next.js (App Router) for the landing and dashboard.
Vercel Edge Runtime for low-latency proxying.
OpenAI SDK to generate the "Diagnosis" field in real-time.
TypeScript for everything (obviously).

How it works

Instead of hitting your API directly, you hit the Inspekt proxy. If your API returns a success, it passes through. If it fails? Inspekt catches the error, asks an LLM what went wrong based on the schema/payload, and appends a _diagnosis field to the response.

We are live on Product Hunt today and I’d love to hear your thoughts on the proxy architecture!

Product Hunt: https://www.producthunt.com/posts/inspekt
Live Site: https://inspekt-api.vercel.app

[Boost]

Jamal Omotoyosi — Wed, 25 Mar 2026 13:17:31 +0000

Jamal Omotoyosi

Mar 25

I rebuilt a failed SaaS as a free API in one day, here's what changed

#backend #api #node #saas

Comments

2 min read

I rebuilt a failed SaaS as a free API in one day, here's what changed

Jamal Omotoyosi — Wed, 25 Mar 2026 13:15:40 +0000

A year ago I built a tool called RespAi. It was an API testing app with AI-powered response analysis, basically Postman but with an AI layer that explained why your API responded the way it did.

It failed immediately. I was competing directly with Postman which has millions of users and brand recognition I'll never touch. Classic mistake.

But the core idea was solid. Developers waste real time manually reading through cryptic 4xx and 5xx responses trying to figure out what went wrong. That problem didn't go away just because my first product failed.

So yesterday I stripped it down to its simplest possible form and shipped it as a single API endpoint.

What Inspekt does

You send it a request. It proxies it to your target URL and returns two things:

The raw response from the API you're testing
A structured AI analysis of what happened and why

The analysis looks like this:

{
"summary": "POST request to Google's homepage returned 405 Method Not Allowed because the root URL does not support POST.",
"status": {
"code": 405,
"meaning": "Method Not Allowed",
"expected": false
},
"diagnosis": "The root endpoint '/' is configured for GET requests only.",
"issues": ["HTTP method mismatch: POST used instead of GET"],
"fixes": ["Change the request method to GET"],
"headers": {
"security_flags": ["x-powered-by header exposes server stack"]
},
"severity": "warning"
}

Why an API and not a GUI tool

Because developers already have Postman for GUI testing. What they don't have is something they can call programmatically, from a script, a CI pipeline, a monitoring job that gives them an intelligent explanation of what went wrong without manual inspection.

Try it

Free, no auth needed:

curl -X POST https://inspekt-api-production.up.railway.app/api/v1/analyze \
-H "Content-Type: application/json" \
-d '{"url": "https://jsonplaceholder.typicode.com/posts/1", "method": "GET"}'

Repo: github.com/jamaldeen09/inspekt-api

Would love brutal feedback from anyone who tries it.