What I Built

Payload Doctor is a small tool for integration developers. You paste a failing JSON or XML payload and the error it produced, and a local AI model explains what went wrong and suggests a fix.

I work with enterprise integrations day to day, and one of the most common time sinks is staring at a rejected payload: a wrong date format, a missing field, a namespace mismatch, an expired token. The obvious shortcut is pasting it into a cloud chatbot, but integration payloads contain business data (customer names, emails, order details, credentials), and that data usually isn't yours to send to a third party.

The people who would pay for this are freelance integration consultants and small dev shops that work with client data and can't, or won't, paste it into a cloud AI. Payload Doctor gives them the speed of an AI assistant without the data leaving their laptop.

Code

AbbeyIT / payload-doctor

Payload Doctor

A local, private assistant for integration developers. Paste a failing JSON/XML payload and its error, and an open-weight model running on your own machine explains what went wrong and how to fix it.

Runs on your laptop through Ollama. No cloud API, no per-request cost, works offline.
Emails, tokens, IPs, and long IDs are masked in code before the model sees anything. The UI shows exactly what was sent.
The server binds to 127.0.0.1 only.

Quick start

# 1. Install Ollama (https://ollama.com), then pull a model
ollama pull qwen3.5:4b      # or a smaller one: llama3.2:3b

# 2. Run the app
npm install
npm start                            # http://127.0.0.1:3000

Options (environment variables): MODEL (default qwen3.5:4b), PORT (default 3000), OLLAMA_HOST (default http://127.0.0.1:11434).

How it works

src/redact.ts masks secrets and personal data, using the same placeholder for the same value ([EMAIL_1]).
src/prompt.ts builds the prompt and adds…

View on GitHub

How I Built It

Model: qwen3.5:4b, an open-weight model, running locally through Ollama.

App: Node.js and TypeScript with Express, and a single plain HTML page for the UI.

No cloud calls: the server talks only to the local Ollama API and binds to 127.0.0.1, so it isn't reachable from other machines.

The model is only part of what makes it work. Most of the reliability comes from the code around it:

Redaction before the model. Emails, tokens, JWTs, IP addresses, phone numbers, and long opaque IDs are masked in code before the model sees anything. The same value always gets the same placeholder ([EMAIL_1]), so the model can still reason about it. The UI shows exactly what was sent.

A deterministic parser check. Small models are unreliable at spotting a missing comma. So the code runs JSON.parse first and tells the model whether the payload is valid.

Structured, validated output. The model replies in JSON, which I validate with zod. If the reply is unusable, the app retries once with the validation error.

A small eval script. npm run eval runs a file of test cases through the model and reports PASS or FAIL, so I can change the prompt or the model and see what happens.

Testing it

I wrote 10 test cases for problems I see often in integration work, all with fake data: a wrong date format with a missing required field, a trailing comma in JSON, a SOAP namespace mismatch, an expired auth token, a string sent where an integer was expected, a payload that's too large, a missing Content-Type header, an upstream gateway timeout, a rate limit, and malformed URL-encoded form data.

Results: 10 of 10 passed on qwen3.5:4b, each on the first attempt with no retry needed. Answers took 26 to 42 seconds each on my laptop.

Where the small model struggled: the answers were right from the start, but my first run was far too slow. The gateway timeout case took 179 seconds, the expired token case took 107, and the SOAP namespace case hit my 180-second timeout and failed. The model was spending most of that time on hidden "thinking" before it replied. Because the model is open and runs locally, I could change that directly: I turned off its thinking mode and raised the request timeout. The same cases then ran in about 30 seconds, and the SOAP case passed.

Known limits:

The eval is a keyword check. It confirms that the answer mentions the right field or concept, not that every word of the fix is correct.

Redaction is pattern-based, so it won't catch things like names or account numbers.

Treat the answer as a second opinion, not a verdict.

DEV Community

Payload Doctor: a private, offline AI that explains failing integration payloads