Skip to content

feat: add an endpoint that checks params before you call a model - #171

Open
brunobuddy wants to merge 2 commits into
feat/param-applicability-enginefrom
feat/validate-endpoint
Open

feat: add an endpoint that checks params before you call a model#171
brunobuddy wants to merge 2 commits into
feat/param-applicability-enginefrom
feat/validate-endpoint

Conversation

@brunobuddy

Copy link
Copy Markdown
Member

Second of four. Stacked on #170, so review that first. The diff here is only the endpoint.

💭 Why

The engine in #170 is only reachable from TypeScript. Most of this ecosystem is Python, and agents reach for curl before they reach for a package.

✨ What changed

  • POST /api/v1/validate takes a model and params, returns issues plus safeParams.
  • Every issue carries a code: unknown_parameter, invalid_value, not_applicable (with conflictsWith).
  • GET on the same path returns the endpoint contract instead of a bare 405.
  • Listed in /api/v1/index.json, llms.txt, and the /api docs page.
  • npm run typecheck now covers api/ too, via tsconfig.api.json.

👤 For users

safeParams is always a payload that passes validation, so a caller who doesn't want to reason about the rules can spread it and proceed. Accepts a bare model slug when only one provider publishes it.

🔧 For operators

No backend. The catalog compiles into the function bundle from the committed generated data. No database, no filesystem read, no self-fetch.

The no-store header rule has to stay after the general /api/(.*) rule in vercel.json. Those rules layer, and the shared s-maxage=3600 would otherwise cache one caller's verdict and serve it to another.

📝 Notes

  • Verified with a local vercel build: the function is produced at functions/api/v1/validate.func, static /api/v1/*.json is untouched, and I ran the compiled artifact directly to confirm the verdict. Routing does not collide because static files are served in the filesystem phase and validate is not a path the static build emits.
  • 14 tests driving the handler with real Request objects, no server needed.

@vercel

vercel Bot commented Jul 30, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
modelparams.dev Ready Ready Preview Jul 30, 2026 1:16pm

Request Review

Second of four, on top of the applicability engine.

POST /api/v1/validate takes a model and a params object and reports
unknown parameters, values outside their range, and combinations the
provider rejects. It also returns safeParams, a corrected payload that
always passes validation, so a caller that doesn't want to reason about
the rules can spread it and move on.

Every issue carries a machine-readable code (unknown_parameter,
invalid_value, not_applicable) so callers can branch on the failure kind
instead of parsing prose. not_applicable also names the parameters that
caused the conflict.

No backend. The catalog compiles into the function bundle from the
committed generated data, so there is no database, no filesystem read and
no self-fetch. GET returns the endpoint contract rather than a bare 405,
because that request is usually a person or an agent exploring the URL.

The no-store header rule has to follow the general /api/(.*) rule in
vercel.json: those rules layer, and the shared s-maxage would otherwise
cache one caller's verdict and serve it to another.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

meta Repo docs, CI, and config site Website code or tooling

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant