DEV Community: Kynth

Any document in. Clean JSON out. — how I turned my apps' AI layer into a 39-endpoint API

Kynth — Wed, 08 Jul 2026 13:26:48 +0000

I run a suite of AI products, and every one of them kept re-implementing the same jobs: parse an invoice, normalize a bank statement, redact PII before it hits a log, fight a chargeback. Prompt-level extraction fails silently — the JSON comes back malformed or subtly wrong just often enough that every app grew its own retry/validation/normalization layer.

So I pulled that whole layer out into one API. It's called Kynth Core.

The spearhead: documents

Nine document engines, each committed to one document kind — that commitment is what makes the output schema-valid and field-accurate instead of "usually fine":

Endpoint	Job	Price
`invoice`	Invoice → vendor, dates, PO refs, tax, line items	$0.08/invoice
`receipt`	Receipt → merchant, items, totals, expense category	$0.06/receipt
`statement`	Bank/card statement → every transaction, normalized	$0.12/statement
`resume`	Resume → structured candidate profile	$0.08/resume
`tables`	Any document → every table as clean headers + rows	$0.08/document
`split`	Multi-doc scan bundle → classified, split documents	$0.10/bundle
`compare`	Two contract versions → material changes + risk	$0.15/comparison
`contract`	Contract → parties, term, renewal, obligations, risks	$0.12/contract
`parse`	Anything else → structured, validated JSON	$0.10/document

Flat price per document — a 9-page statement costs the same as a 1-pager. And the accuracy isn't a vibe: every endpoint's field-level score is public at api.kynth.studio/benchmarks, run against the live production API and re-run on every prompt or model-routing change.

…and 30 more jobs on the same wallet

The catalog behind the spearhead, browsed at /endpoints: guaranteed-schema extraction (structure — your JSON Schema in, conforming output out, retries handled), entity matching, batch categorization, ticket triage, meeting minutes, reply drafting, collections sequences, 3-way PO matching, fraud triage, moderation against your own policy, brand-voice rewriting, a cited web-research brief, lead screening, agent memory (semantic store/search, no vector DB to run), transcription, image generation, and TTS.

Every endpoint is a finished job with its own page and its own per-task price — never a prompt you have to engineer.

The design decisions I actually care about

Priced per task, not per token. You know what a document costs before you send it.

You're only charged on success. The charge happens after a valid result, in the same row-locked transaction that writes the usage ledger.

Model routing is internal. Each task runs on the cheapest model that's good enough (Gemini / Claude / GPT, chosen per job, re-tuned as models improve). You never configure it; you just get the price on the tin.

500 free credits every month, no card. Enough to ship a real integration before you pay anything.

Three ways to call it

curl https://api.kynth.studio/v1/invoice \
  -H "Authorization: Bearer ksk_live_…" \
  -d '{ "fileUrl": "https://…/invoice.pdf" }'

TypeScript:

import { KynthCore } from "@kynth/api";
const kynth = new KynthCore({ apiKey: process.env.KYNTH_API_KEY! });
const doc = await kynth.invoice({ fileUrl });
console.log(doc.total, doc.usage.balanceRemaining);

Python:

from kynth import Kynth
doc = Kynth(api_key="ksk_live_...").invoice(file_url="https://.../invoice.pdf")

And an MCP server, so Claude or Cursor call all 39 endpoints as native tools:

claude mcp add kynth-core -e KYNTH_API_KEY=ksk_live_… -- npx -y @kynth/api-mcp

The SDKs and MCP server are generated from the same catalog the OpenAPI spec is built from, so they can't drift from the API.

Try it

Home: https://api.kynth.studio
All 39 endpoints: https://api.kynth.studio/endpoints
Benchmarks: https://api.kynth.studio/benchmarks
Interactive reference: https://api.kynth.studio/reference
OpenAPI spec: https://api.kynth.studio/openapi.json

I'd genuinely like feedback on the endpoint set — which of these you'd actually reach for over rolling your own against a raw model, and what's missing. Reply here or poke at the API.

Modeling Prior Authorization as a Payer-Policy Matching Problem

Kynth — Mon, 06 Jul 2026 16:03:02 +0000

It's 4:47 PM. There are nine prior authorizations in the queue and the person working them has been at it since lunch. Each one is the same ritual: open the chart, hunt for the diagnosis codes, cross-reference the payer's coverage policy PDF (the one that changed last quarter and nobody told you), copy the ICD-10 that justifies the CPT, paste it into a portal that logs you out every twenty minutes, and hit submit knowing there's maybe a 70% chance it comes back denied for a reason you could have caught if you'd had time to read all eleven pages of the policy.

Then it comes back denied. And now it's an appeal, which is the whole thing again but angrier.

If you've built anything near a medical practice, you know this queue never empties. It just ages. And every aged auth is revenue sitting in limbo. I spent the last year building software to work this pile, and the interesting part wasn't the AI — it was realizing prior auth isn't a writing problem. It's a matching problem.

The pile is a matching problem, not a writing problem

The naive build is: dump the chart into an LLM, say "write a medical necessity letter," ship it. It produces confident, fluent prose. It also gets denied, because a payer doesn't grade prose. A payer grades whether specific, enumerated criteria in their coverage policy are each backed by something in the chart.

So the real unit of work isn't a letter. It's a set of (criterion → evidence) pairs. Aetna's policy for a given procedure might require: failed conservative therapy for ≥6 weeks, documented functional impairment, imaging confirming the indication. UnitedHealthcare wants a different three things. The job is to bind each criterion to a concrete chart citation — and to notice, before submitting, when a criterion has no evidence behind it. That empty binding is your denial risk, and you can see it coming.

def assemble_justification(chart, payer_policy):
    bindings = []
    for criterion in payer_policy.required_criteria:
        evidence = retrieve_evidence(chart, criterion)  # dated chart citations
        bindings.append({
            "criterion": criterion,
            "evidence": evidence,
            "satisfied": bool(evidence),
        })

    unmet = [b for b in bindings if not b["satisfied"]]
    denial_risk = len(unmet) / len(bindings)   # the number you want BEFORE submit
    return Justification(bindings=bindings, risk=denial_risk, gaps=unmet)

The gaps list is the whole product, honestly. It turns a blind submission into "these two criteria are unmet — go get the PT notes before you send this."

Grounding, because hallucinated evidence is malpractice

retrieve_evidence is where every shortcut bites you. You cannot let the model say the conservative therapy happened. It has to cite the note that says it, with a date. We treat any binding whose evidence isn't traceable to a real chart span as unsatisfied — a false "satisfied" is far more dangerous than a false gap. A gap gets flagged for a human; a fabricated citation gets you denied, or worse.

The other subtle bit: coverage policies drift. The criteria set has to be re-parsed from the live policy, not memorized, or you'll assemble a beautiful justification against last year's rules.

The denial is structured too

When a denial comes back, resist the urge to "write an appeal." A denial cites specific reasons — usually a criterion the payer claims wasn't met. So the appeal is just the inverse operation: take each denial reason, find the criterion it maps to, and rebut it with the evidence binding you already built. Point by point, in the payer's own vocabulary. Half the time the evidence was there and the reviewer missed it, and a targeted rebuttal is far stronger than a fresh persuasive essay.

What actually changed

The lesson that generalizes beyond healthcare: when an LLM task feels like "generate a document," check whether it's secretly a matching task with an audit trail. Model the criteria, bind them to evidence, expose the gaps, and let the fluent-prose part be the last, cheapest step. The pile still exists — but now something works it down instead of just aging it.

We packaged this as Authorize — try it free. It's how we built the thing that finally empties the queue.

Predicting When a Client Will Actually Pay: Modeling Invoice Timing With an AI Agent

Kynth — Mon, 06 Jul 2026 00:38:49 +0000

The single hardest thing about getting paid isn't writing the invoice. It's the follow-up — knowing when to nudge a quiet client, and doing it in a tone that doesn't torch the relationship. Most tools solve this with a dumb cron job: "send a reminder 7 days after the due date." That's wrong for almost everyone, and here's why.

The problem with fixed reminder schedules

Payment behavior isn't uniform. One client pays like clockwork on day 32 of a "net 30" invoice — not late, just their rhythm. Another pays on day 5 but only if you remind them on day 3. A blanket "day 7 past due" reminder annoys the first client (who was always going to pay) and misses the second (who needed the poke earlier).

So the real problem is per-client timing prediction, not scheduling. You want to model each client's payment distribution and act at the point where a reminder has the highest marginal effect — the moment they're most likely to convert intent into a transfer.

Modeling payment rhythm as a per-client distribution

Every invoice gives you a labeled data point: (sent_date, due_date, paid_date, amount, was_reminded). Over time, per client, that's a distribution of "days from send to pay." The naive move is to average it. Don't — averages hide the shape, and the shape is the whole signal.

We model each client's pay-day as a distribution and track two things that matter more than the mean:

Dispersion — a tight distribution (always day 30–32) means a reminder before day 30 is noise. A wide one means the client is reminder-sensitive.
Reminder lift — comparing paid-day distributions with and without a nudge tells you whether reminders actually move this client, and by how much.

for client in clients:
    hist = paid_events(client)              # list of days-to-pay
    p50, p90 = quantiles(hist, [.5, .9])
    lift = mean(days_without_reminder) - mean(days_with_reminder)

    # act just before the client's own habitual pay point,
    # but only if a nudge historically helps them
    if lift > MIN_LIFT_DAYS:
        send_at = due_date + p50 - REMINDER_LEAD
    else:
        send_at = due_date + p90     # let reliable-but-slow payers be

The else branch is the one people skip, and it's the most important. A client who reliably pays on day 45 doesn't need three reminders — they need zero until day 44. Suppressing unnecessary nudges is as valuable as sending well-timed ones, because every needless reminder trains the client to ignore you.

Cold start: the first invoice has no history

With no per-client data, you fall back to a hierarchical prior: start from the population distribution (or a segment — agencies pay differently than startups), then let each new payment pull that client's estimate toward their own behavior. Bayesian updating does this cleanly. After two or three invoices, the client-specific signal dominates the prior. Before that, you're at least not guessing blind.

Drafting in the user's voice — the calibration problem

Timing gets the money moving; tone keeps the client. The reminder has to sound like you, not like a collections agency. We feed an LLM a few of the user's real past messages as style exemplars, plus structured context (days overdue, prior reminders sent, relationship length) so the model can calibrate escalation:

First nudge on a reliable client → light, assume-good-faith.
Third nudge, 30 days over → firmer, still professional.

The trick is that escalation is a function of the client's own history, not a global template. Same overdue count, different tone, depending on whether this client has ghosted before. Pass that history into the prompt and the model calibrates it far better than any if/else ladder you'd hand-write.

What makes it an agent, not a script

It closes the loop. Every paid invoice updates the distribution, re-estimates lift, and reschedules the next client's reminders. It decides not just what to send but whether to send at all — and the "send nothing" decision is a first-class action. That feedback loop is the difference between automation and an agent that gets better at your specific book of clients over time.

We built this as Tally — it watches every invoice, learns each client's rhythm, and drafts reminders in your voice at the moment they actually pay. Try it free → https://kynth.studio/l/tally