Requesty

Requesty Documentation Audit

The docs cover a lot of surface area (300+ models, multiple SDKs, webhooks, EU routing, structured outputs) but the foundation is shaky: hostnames, auth schemes, model counts, and code samples disagree with each other across pages, and the canonical llms-full.txt file — which agents will rely on — ships broken code.

1. Three different API hostnames documented, only two exist in the OpenAPI spec (critical)

Location: /features/key-management-api, /features/request-feedback, /api-reference/openapi.json

Problem: The Key Management API page documents a base URL of https://api.requesty.ai. The Request Feedback page hits https://api.requesty.ai/feedback/{request_id}. But the published OpenAPI spec (/api-reference/openapi.json) declares only two servers: https://api-v2.requesty.ai (management) and https://router.requesty.ai (inference). api.requesty.ai doesn't appear in the OpenAPI document at all.

Consequence: Developers and agents that read the Key Management or Feedback pages will copy the wrong host and either silently hit a redirect (best case) or get DNS / 404 failures (worst case). Agents driving this via the OpenAPI spec will never discover the feedback endpoint. Worse, the discrepancy is invisible — there's no callout that "this endpoint uses a different host".

The fix: Pick one management host (presumably api-v2.requesty.ai), update both the Key Management API and Request Feedback pages, and add the feedback endpoint to the OpenAPI spec. If api.requesty.ai is a real alias, document it explicitly and add it as an OpenAPI server.

2. llms-full.txt ships broken Python and TypeScript code samples (critical)

Location: /llms-full.txt (Quickstart section)

Problem: The agent-facing full-text bundle contains two code samples that won't run as-is:

• Python: default_headers: {...} uses Python dict-colon syntax inside a function call where it must be default_headers={...} (the rendered HTML quickstart correctly uses =). The sample also imports os but never uses it.
• TypeScript: uses Python-style snake_case keys (base_url, api_key, default_headers) instead of baseURL, apiKey, defaultHeaders, and sends role: 'User' with a capital U which the OpenAI SDK rejects.

Consequence: This is the file agents (Claude Code, Cursor, etc.) and LLM-powered IDEs are most likely to ingest wholesale. Every developer onboarded via an agent gets non-running code. The rendered Quickstart at /quickstart is correct, but the llms-full.txt mirror — the one explicitly built for machine consumption — isn't.

The fix: Regenerate llms-full.txt from the same source as the rendered Quickstart, and add a CI check that compiles/lints every code block. The TypeScript sample must use baseURL/apiKey/defaultHeaders and role: 'user'.

3. Anthropic base URL: /v1 or not? Two pages disagree (critical)

Location: /features/eu-routing vs /features/pdf-support

Problem: EU Routing explicitly says the Anthropic-compatible endpoint takes no /v1:

base_url="https://router.eu.requesty.ai", # EU endpoint (no /v1)

The PDF Support page's Anthropic SDK example uses base_url="https://router.requesty.ai/v1" for the same Anthropic-style messages call. The OpenAPI spec lists /v1/messages under router.requesty.ai, which deepens the confusion: is /v1 part of the path, part of the base, or both?

Consequence: Developers copy whichever sample they hit first. One group gets 404s. Agents that read both pages and pick the contradicting one silently break Anthropic compatibility. The mismatch also makes it impossible to write a correct universal client.

The fix: Decide whether the Anthropic SDK base URL includes /v1 and fix every code example to match. Add an explicit "Anthropic base URL" subsection to the auth/quickstart pages that calls out the difference from the OpenAI-compatible base URL.

4. Two auth schemes (Authorization: Bearer vs x-api-key) with no explanation, and the OpenAPI spec only declares one (critical)

Location: /api-reference/endpoint/messages-create vs /api-reference/openapi.json and the rest of the docs

Problem: Every OpenAI-compatible example uses Authorization: Bearer <key>. The Anthropic-format messages-create reference uses x-api-key, with no explanation, no statement that both are accepted, and no warning that the Anthropic SDK sets x-api-key automatically while a hand-rolled curl call needs to switch headers. Meanwhile, the OpenAPI spec declares only one security scheme: BearerAuth — so SDK generators consuming the spec will never produce a working Anthropic client.

Consequence: Developers writing raw HTTP clients (no SDK) will guess wrong and get 401s. Agents generating curl from one page and headers from another produce broken requests. Tooling that builds clients from the OpenAPI spec will emit Bearer-auth code that fails against the Anthropic endpoint. The single auth scheme is the most basic contract of an API gateway — having two undocumented schemes for two endpoint families is a foot-gun.

The fix: Add one "Authentication" page that states both Authorization: Bearer <key> and x-api-key: <key> are accepted on every endpoint (if true), and link from every reference page. Update the OpenAPI spec to declare both security schemes and apply x-api-key (and/or both) to /v1/messages. If only one scheme works per family, say so explicitly with a comparison table.

5. Management API page documents 5 endpoints; OpenAPI spec has 11 (significant)

Location: /features/key-management-api vs /api-reference/openapi.json

Problem: The Key Management API page documents only a handful of key endpoints. The OpenAPI spec exposes the full set under /v1/manage/*: apikey, apikey/{id}, apikey/{id}/usage, apikey/{id}/limit, apikey/{id}/label, apikey/{id}/expiry, group, group/{id}, group/{id}/member, org, org/usage — 11 paths total. Group management, org usage, expiry, label, and individual-apikey GET/DELETE aren't documented in prose anywhere visible from the docs nav.

Consequence: Developers who want to automate org/group management or set expiry/label programmatically have to read the OpenAPI JSON manually. Agents only get the prose docs and miss half the platform.

The fix: Generate the management API reference from the OpenAPI spec (Mintlify supports this) so the two can't drift, or at least add a "More endpoints in OpenAPI spec" section listing the missing 6.

6. Model count claim varies between 150+ and 300+ across pages (significant)

Location: /llms-full.txt (intro), /frameworks/langchain, /frameworks/pydantic-ai

Problem: The top of llms-full.txt says "300+ models". The LangChain framework page hard-codes "150+ LLMs" inside an example prompt ("What application should I build now that Requesty router provides access to 150+ LLMs?"). The Pydantic AI framework page does the same in its demo prompt.

Consequence: This is a credibility issue: an obvious inconsistency at the marketing-headline level signals stale content elsewhere. For agents trying to summarize "what is Requesty," the number returned depends on which page got cached. The framework examples baked into prompts will be wrong as soon as the catalog grows.

The fix: Single-source the model count from one variable (Mintlify supports variables / snippets), and never bake a count into an example prompt — use a relative phrase like "all the models in the catalog."

7. function_call example in API Reference is invalid JSON and uses deprecated field (significant)

Location: /api-reference/overview

Problem: The response sample shows:

"function_call": {
  "name": "get_current_weather",
  "arguments": "{ "location": "Boston, MA"}"
}

The inner JSON string is not escaped — pasting this into any parser is a syntax error. Separately, the request defines a tool (newer API) but the response uses the deprecated function_call/finish_reason: function_call shape rather than tool_calls.

Consequence: A developer copying the example into a fixture or test will get an immediate JSON.parse failure. An agent learning the response shape from this page will generate code that handles the wrong field. New OpenAI SDK versions don't populate function_call when tools are used.

The fix: Escape the embedded JSON ("{\"location\": \"Boston, MA\"}") and update the example to tool_calls with finish_reason: "tool_calls" to match the request's tools field.

8. Reasoning page says Anthropic budget is "passed to Google" (significant)

Location: /features/reasoning

Problem: Under the heading "When using Anthropic via Requesty", the docs say:

If the client specifies a reasoning budget string (e.g. "10000"), Requesty passes this value to Google.

The same paragraph is duplicated verbatim under "When using Vertex AI via Requesty".

Consequence: Either the routing is genuinely sending Anthropic-bound reasoning budgets to Google (a real privacy/correctness bug worth disclosing), or — far more likely — the section was copy-pasted from the Vertex section without being updated. Either way, developers reading this can't trust the reasoning routing semantics. Agents will pick whichever interpretation supports the user's question.

The fix: Rewrite the Anthropic section to describe Anthropic's actual thinking.budget_tokens semantics. Audit any other section that may have been duplicated.

9. Chat Completions reference hard-codes a default model in the OpenAPI schema (significant)

Location: /api-reference/endpoint/chat-completions-create

Problem: The Chat Completions endpoint reference (and the underlying OpenAPI schema) says:

model — default: openai/gpt-4o-mini. The model name. If omitted, defaults to openai/gpt-4o-mini.

But Requesty also supports user/payer-configurable default models — meaning the actual runtime behavior when model is omitted depends on account settings, not the literal value baked into the spec.

Consequence: SDK generators and agents that consume the OpenAPI spec will treat openai/gpt-4o-mini as a hard contract. A user testing a new account whose default has been changed to a premium model could rack up unexpected costs, or vice versa. The OpenAPI default is what tooling will believe.

The fix: Remove the hard-coded default: openai/gpt-4o-mini from the OpenAPI schema and document the account-configurable default behavior in prose, or make the literal default the actual unconditional behavior and remove account-level overrides. The two cannot both be true.

10. Code samples have undefined variables, tuple-by-accident bugs, and cross-language syntax errors (significant)

Location: /features/structured-outputs, /frameworks/haystack, /frameworks/pydantic-ai, /features/pdf-support, /features/request-feedback

Problem:

• structured-outputs: uses api_key=request_api_key where the variable is named requesty_api_key — NameError at runtime.
• haystack and pydantic-ai: requesty_api_key = Secret.from_env_var("REQUESTY_API_KEY"), (trailing comma) creates a 1-tuple, which then gets passed to api_key and fails on the SDK side.
• pdf-support JavaScript: f'data:application/pdf;base64,{pdfData}' uses Python f-string syntax in a JS sample — not valid JS at all.
• request-feedback: the Node.js example uses anthropic/claude-3-7-sonnet-latest while the Python example on the same page uses openai/gpt-4o, and the Python example uses requests and openai without showing the imports — so a copy-paste fails at import time.

Consequence: Every one of these is a copy-paste-and-run failure. Agents will faithfully reproduce the bugs. Even a developer who notices the typo loses 5–10 minutes diagnosing why an example doesn't work.

The fix: Add a code-block linter / executable doc-test step in CI. At minimum, search every page for request_api_key, ,$ after Secret.from_env_var, and f' / f" inside JS/TS fences. Make paired examples on a single page use the same model and show all imports.

11. Webhook delivery documented; signing/verification is not (critical)

Location: /features/alerts

Problem: The alerts page documents retry count (3), backoff, timeout (15s), and payload format — but never mentions a signing scheme (HMAC header, signing secret), the User-Agent Requesty uses, or how a receiver should verify a webhook is legitimately from Requesty.

Consequence: This is not just a documentation gap — it's a security problem. Any production webhook handler needs to verify authenticity, or it's trivially spoofable. Webhook payloads here carry usage/cost data, which means a spoofed payload could drive alerting and downstream automation. Developers will either build naive endpoints (security risk) or have to support-ticket the question. There's no way for an agent to write a correct receiver from these docs.

The fix: Document the signing header (or add one if none exists), include a verification snippet in Node and Python, and call out the User-Agent / source IPs if either is stable.

12. Stale requesty.mintlify.app alt-domain links inside production docs (significant)

Location: /features/structured-outputs, /api-reference/overview

Problem: Both pages link to https://requesty.mintlify.app/features/streaming instead of https://docs.requesty.ai/features/streaming. mintlify.app is the staging/preview domain Mintlify gives every customer.

Consequence: Users following the link land on a preview/staging copy that may diverge from production, may be unindexed/noindexed, and breaks if Mintlify rebrands the subdomain. Agents that follow the link cache the wrong canonical URL.

The fix: Add a redirect at the Mintlify project level and grep the repo for mintlify.app — every match should be a docs.requesty.ai URL.

13. Empty code block in Vercel AI SDK page (significant)

Location: /frameworks/vercel-ai-sdk

Problem: Under the heading "Provider Instance" the page says "You can import the default provider instance requesty from @requesty/ai-sdk" — and the code block that should show the import is empty. The page title is also missing a word: "Using Requesty router the Vercel AI SDK" should be "Using Requesty router with the Vercel AI SDK."

Consequence: Vercel AI SDK is one of the most popular integrations in this niche. The most critical snippet on the page (the import line) is missing. Developers and agents can't actually proceed without guessing the export shape.

The fix: Restore the import statement (likely import { requesty } from '@requesty/ai-sdk') and fix the page title.

14. LlamaIndex TS example uses a placeholder base URL (significant)

Location: /frameworks/llamaindex-ts

Problem: The code sample uses https://your-requesty-endpoint.com/v1 rather than the real https://router.requesty.ai/v1. There's no callout flagging the placeholder.

Consequence: Developers copying the sample will hit DNS resolution failures. Agents will copy the placeholder verbatim into generated code because nothing marks it as a placeholder.

The fix: Use the real router base URL in every example, or wrap placeholders in an obvious convention (<YOUR_BASE_URL>) and call them out in prose.

15. Inconsistent model-library URL across pages (minor)

Location: /frameworks/llamaindex-ts, /frameworks/vercel-ai-sdk, other framework pages

Problem: Some framework pages link to app.requesty.ai/models, others use app.requesty.ai/model-list or app.requesty.ai/model-library. Only one is the canonical destination — the others redirect or 404.

Consequence: Trivial for humans (they click through the redirect), but inconsistent URLs across pages indicate no single source of truth. Agents may cache the wrong path.

The fix: Single-source the model library URL in a Mintlify variable.

16. Stray non-ASCII character at end of Session Reconstruction page (minor)

Location: /features/session-reconstruction

Problem: The page ends with …without requiring any session management on your end.ß — a trailing ß (German sharp s) that's clearly a typo.

Consequence: Pure cosmetic, but it signals the absence of editorial review on a published page.

The fix: Delete the stray character.

17. Sign-up credit promo embedded in unrelated integration page (minor)

Location: /integrations/librechat

Problem: The LibreChat integration page contains a marketing callout: "New users receive $6 in sign-up credit when creating a Requesty account." This dollar figure isn't repeated on the pricing page (where it belongs) and is highly likely to go stale.

Consequence: When the promo changes, this page becomes false advertising. Putting promo amounts inside random integration pages also means there's no single place to update them.

The fix: Move the dollar amount to one canonical pricing/sign-up location and link to it. Or remove the figure and link to the sign-up flow.

What they do well

• The OpenAI-compatibility story is clean: the rendered /quickstart shows a 2-line drop-in replacement that genuinely works, and the same pattern carries to LangChain, Vercel AI SDK, LlamaIndex, Haystack, Pydantic AI.
• An llms-full.txt exists at all — most competitors haven't published one. (It just needs to be correct — see finding #2.)
• EU routing is documented as a first-class feature with a clear endpoint table — a real differentiator that's easy to find.

Top 3 recommendations

1. Fix the host / auth / Anthropic-base-URL contradictions first (findings #1, #3, #4) — these are the contract of an API gateway and they currently disagree across pages. Until they're consistent, no SDK example can be trusted as canonical.
2. Regenerate llms-full.txt from the same source as the rendered docs and add a code-block lint step to CI (findings #2, #7, #10). Today the agent-facing file is in worse shape than the human-facing pages.
3. Document webhook signing and generate the management/inference reference from the OpenAPI spec (findings #5, #11) so receivers can be built safely and the docs can't drift from the spec. Add the missing /feedback/{request_id} endpoint to the spec while you're there.