Jupiter developer documentation, May 2026

V3 — 2026-05-31 correction revision. Original prepared 2026-05-28 (V1); V2 issued 2026-05-29. V3 is a correctness pass: three defects in the prior revisions are fixed against a fresh re-verification of the documentation mirror. (1) F-3 title count corrected from "fifteen" to "fourteen" distinct OpenAPI titles — the prior headline was off by one; the enumerated table was already correct and is unchanged. (2) F-5 a non-existent "internal inconsistency" in the Trigger create-order specification was retracted — re-verification shows the v1 specifications are internally consistent (title, version, and server URL all agree); the v1/v2-coexistence finding itself is unaffected. (3) F-2 the V2 "framing addition" referencing an external governance classification and cross-vendor recurrence has been removed; F-2 now stands on the directly-verifiable Jupiter facts alone. No other finding changes in scope, severity, or recommendation.

Prepared for: Jupiter, Developer Documentation team Date of review: 2026-05-31 (V3; V2 2026-05-29; original review 2026-05-28) Documents reviewed: developers.jup.ag/docs documentation corpus mirrored 2026-05-28 — 248 files (~4100 KB) covering 9+ product surfaces (Swap, Trigger, Recurring, Lend, Prediction, Price, Tokens, Portfolio, Send, Studio, Transaction) plus narrative sections (Get Started, Guides, Portal, Tool-Kits, AI, Resources, Legal, Changelog) Review type: Documentation quality, correctness, and developer-integration-readiness assessment across Jupiter's REST API ecosystem

---

Executive summary

The Jupiter API documentation set is structurally complete (248 of 248 enumerated URLs returned 200) and serves its primary purpose: documenting an extensive set of REST API surfaces across the Jupiter product family (Swap V2, Trigger Orders, Recurring/DCA, Lend Earn + Borrow, Prediction Markets, Price API V3, Tokens, Portfolio, Send, Studio, Transaction Submission). The corpus carries 21 findings across the documentation quality dimensions reviewed.

Documentation is usable for integration but the issues catalogued below introduce avoidable friction for developers, with two findings (F-1 and F-2) representing acute integration-experience issues that materially mislead integrators.

Top-priority items requiring attention:

The two CRITICAL items are systemic and likely share a single root cause (docs-build pipeline configured against legacy infrastructure):

• F-1 affects every page in the documentation set in a consistent way: 248 of 248 pages begin with a documentation-index banner that recommends fetching https://dev.jup.ag/docs/llms.txt (the LEGACY host), and the sitemap.xml—last regenerated 6 days before the mirror date—exclusively references the same legacy host across 219 URLs. Search-engine crawlers consuming sitemap.xml index the legacy URLs (incurring a redirect on every fetch); LLM/agent tooling reading the banner is steered to a discovery URL on the legacy host. The canonical host developers.jup.ag appears in llms.txt content and in inline narrative documentation but never in sitemap.xml or banner. This is fresh stale, not legacy artifact: the docs-build pipeline is regenerating both artifacts against the wrong host.

• F-2 affects the Ultra API surface: the pricing/rate-limit table at /portal/plans lists seven /ultra/v1/* endpoints as active billable surfaces with credit costs (/order = 1, /execute = 0, /holdings/{address} = 3, /holdings/{address}/native = 3, /shield = 1, /order/routers = 1, /search = 10), but no Ultra reference documentation exists at developers.jup.ag/docs/api-reference/ultra*. The only Ultra documentation in the corpus is a migration stub at /swap/migration/ultra-to-order telling consumers to move to Swap V2. A developer consulting the rate-limit table to size their integration sees Ultra as an active product; clicking through to reference docs finds nothing; reading the migration page is told the product is being effectively deprecated. The mismatch is acute.

The HIGH-severity items concentrate on cross-product consistency. The Jupiter API ecosystem comprises 10+ independently-evolving product surfaces (Swap, Trigger, Recurring, Lend, Prediction, Price, Tokens, Portfolio, Send, Studio, Transaction). Each surface's documentation has its own OpenAPI title naming convention (14 distinct titles across 78 inline specifications), version-numbering scheme (56 specs at 1.0.0, 20 at 2.0.0, 1 at 3.0.0, 1 at the YAML-quoted form '1.0'), and—in the case of Trigger—simultaneously-active v1 and v2 versions without a published migration timeline. A developer integrating across multiple surfaces accepts inconsistent typed-client naming, inconsistent version-number semantics, and ambiguity over which API version to target.

---

Methodology

The review was a systematic read-through of every file in the documentation mirror, applying a documentation-quality checklist tuned for vendor-published REST API surfaces with extensions for Jupiter's specific multi-product architecture and Mintlify-platform inline-YAML-OpenAPI authoring pattern. The checklist covered:

• Content integrity (per-endpoint title ↔ tags ↔ path ↔ parameter set internal consistency)
• Response schema completeness and required/optional field marking
• Identifier and endpoint canonicity (base URLs, version paths, auth header naming)
• Cross-product canonicity (consistency across security schemes, version-numbering, server-URL conventions, parameter vocabularies across Swap / Trigger / Recurring / Lend / Prediction / Price / Tokens / Portfolio / Send / Studio / Transaction)
• Host-migration coordination (sitemap host vs canonical host vs documentation-index banner host)
• BETA / preview surface lifecycle policy
• Schema definition duplication across endpoint specifications
• Documentation-index banner positioning and content
• Code sample correctness against current SDK versions
• Deprecation and lifecycle hygiene (dates, deprecated field markers, replacement pointers, version coexistence)
• Cross-link and cross-reference integrity (internal links resolve in mirror; rate-limit-table endpoints all have reference docs)
• Security scheme metadata consistency
• Renderer portability (markdown vs JSX-wrapped content)

Each finding was severity-graded against developer-impact criteria:

• Critical — Reader misled into wrong integration path; class-wide doc surface affected
• High — Material integration friction; non-obvious workaround required
• Medium — Friction reducible by reader effort; doc quality observable
• Low — Cosmetic inconsistency; affects polish, not function

Findings IDs are opaque sequence numbers (F-1 through F-21) with no semantic content outside this report.

Substrate verification was mechanical: file counts, OpenAPI title and version-number distributions, server-URL declarations, host-frequency counts across sitemap and banner content, sitemap regeneration dates, broken-link sweeps, schema body comparisons (via md5sum), and security scheme distributions were performed via grep / diff / awk over the local mirror and are independently reproducible.

---

Findings

Critical

F-1 — Every page emits a documentation-index banner pointing to a legacy host; sitemap.xml freshly regenerated on the same legacy host

Fixed Re-check of the published text, 11 October 2026.

Category. Host-migration coordination — discoverability artifacts misaligned with canonical host Affected files. All 248 mirrored pages + sitemap.xml.

Observation. Every one of 248 documentation pages opens with a 3-line blockquote:

> ## Documentation Index
> Fetch the complete documentation index at: https://dev.jup.ag/docs/llms.txt
> Use this file to discover all available pages before exploring further.

The URL https://dev.jup.ag/docs/llms.txt resolves via 301 redirect to https://developers.jup.ag/docs/llms.txt (the canonical host). The canonical host is referenced consistently in narrative documentation, in the llms.txt content itself, and in API-key portal cross-references. However, the banner—which is the first content every reader sees on every page—uses the legacy host.

In parallel, sitemap.xml exclusively references the legacy host: of 219 URL entries, 0 use developers.jup.ag. The sitemap was last regenerated on 2026-05-22 (6 days before the mirror date), making this fresh stale rather than legacy artifact—the docs-build pipeline is actively regenerating both the banner template and the sitemap against the wrong host.

Developer impact.

• Search-engine crawlers consume sitemap.xml and index legacy URLs. Search-engine-discovered traffic incurs a 301 redirect on every fetch.
• LLM agents and developer-tooling reading the banner are steered to a discovery URL on the legacy host. They cannot follow legacy-host paths if those paths appear in third-party sources (Stack Overflow, blog posts, Discord links) and must reason about host equivalence themselves.
• Cross-channel inconsistency (sitemap and banner on legacy; llms.txt content and narrative on canonical) creates a persistent SEO + agent-ecosystem split.

Recommendation. Update the documentation-build pipeline to emit the banner template and regenerate sitemap.xml against the canonical host https://developers.jup.ag. Add a CI check that asserts every <loc> in sitemap.xml uses the canonical host (fail build on mismatch). Issue 301 permanent + Link: rel="canonical" headers on legacy-host responses with a published retirement timeline so cached external references migrate over a defined window.

---

F-2 — Ultra API surface is billable in the pricing table but reference documentation is absent

Fixed Re-check of the published text, 11 October 2026.

Category. Product-lifecycle hygiene — pricing/billing surface out of sync with documentation surface Affected files. /portal/plans (rate-limit credit table) + missing /api-reference/ultra/* + /swap/migration/ultra-to-order (migration stub).

Observation. The pricing/rate-limit table at /portal/plans lists seven Ultra endpoints as active billable surfaces:

No corresponding reference documentation exists. Multiple internal links across the corpus point at /api-reference/ultra, /ultra/index, /ultra/add-fees-to-ultra, and /ultra/manual-mode—all return missing-page when followed. The only surviving Ultra content is a migration stub at /swap/migration/ultra-to-order which describes Ultra as effectively deprecated:

*"If you currently use Ultra /order + /execute, migration is minimal. The endpoints are the same, with a new base URL."*

Developer impact. A developer sizing their integration consults the pricing table, sees seven Ultra endpoints with credit costs, and reasonably assumes Ultra is an active product surface. Clicking through to documentation returns 404; consulting the migration stub is told to use Swap V2. The developer must reverse-engineer whether to: (a) integrate against Ultra anyway and budget billing for it, (b) skip Ultra and use Swap V2 per the migration stub, or (c) wait for clarity. No source in the documentation provides authoritative guidance on Ultra's lifecycle state.

Recommendation. Decide and communicate Ultra's lifecycle state explicitly. If deprecated: remove Ultra endpoints from the rate-limit/billing table; add a deprecation banner with retirement timeline to the migration stub; emit 410 Gone or 301 redirect on /api-reference/ultra* requests with destination at /api-reference/swap/v2. If active: restore the reference docs and add a per-endpoint specification page to developers.jup.ag/docs/api-reference/ultra/*.

---

High severity

F-3 — Fourteen distinct OpenAPI titles across 78 endpoint specifications with no coherent naming scheme

Unchanged Re-check of the published text, 11 October 2026.

Category. API taxonomy + cross-product naming convention Affected files. All 78 endpoint-specification files (Mintlify inline-YAML-OpenAPI pattern).

Observation. Jupiter's documentation uses Mintlify's inline-YAML-OpenAPI pattern where each endpoint page declares its own complete OpenAPI specification fragment inline as a YAML code-fence. Across 78 such specifications, 14 distinct info.title values appear:

Version-in-title suffix is used inconsistently: present for Swap V2, Tokens API V2, Trigger Order API V2, Price API V3; absent for Prediction Market, Lend, Portfolio, Recurring, Send, Studio, Token Verification, Content. Three Swap specs omit the "Jupiter" namespace prefix that the other 75 specs include.

Developer impact. Typed-client codegen (TypeScript, Python, Go SDK auto-generation) emits 14 inconsistently-named packages or namespaces. Cross-product code reviews lose the ability to reason about which product surface a change affects from title alone. New integrators searching documentation for "Jupiter Tokens API" find both Jupiter Tokens API V2 (verb: search/list/get) and Jupiter Token Verification API (verb: verify) without obvious surface boundaries.

Recommendation. Standardize a per-product naming convention. Two viable forms:

• Form A: Jupiter <Product> API V<n> consistently, where products are: Swap, Trigger, Recurring, Lend, Prediction Market, Price, Tokens, Token Verification, Portfolio, Send, Studio, Transaction, Content.
• Form B: <Product> API V<n> consistently (drop "Jupiter" prefix everywhere; rely on the docs-host context).

Apply via bulk-rename across the 78 specification fragments at the docs-build layer.

---

F-4 — info.version numbers do not form a coherent versioning scheme

Unchanged Re-check of the published text, 11 October 2026.

Category. Versioning policy Affected files. All 78 endpoint-specification files.

Observation. The OpenAPI info.version values across 78 specifications:

The version numbers do not correlate with the product-version suffix in info.title: a Jupiter Lend API specification at version: 1.0.0 shares its version-number form with a Jupiter Trigger Order API V2 specification also at version: 1.0.0. Versioning conveys no information about API surface version, change boundary, or product maturity. The single '1.0' quoted-string outlier (in the Recurring API get-recurring-orders specification) breaks typed-client codegen that expects standard SemVer string form across all specifications.

Developer impact. Consumers using OpenAPI version metadata to track API evolution find the metadata empty of meaningful signal. The quoted-string outlier silently breaks tooling that assumes consistent version-string form.

Recommendation. Choose and apply a per-product versioning policy. Three viable approaches:

• Match info.version to the title-suffix version (e.g., Trigger Order API V2 → version: 2.0.0; Price API V3 → version: 3.0.0).
• Use info.version for per-specification revision tracking (e.g., bump on every spec edit; track in build metadata).
• Adopt date-versioning (e.g., 2026.05.0) per spec generation.

Whichever is chosen, replace the '1.0' quoted-string with the consistent form.

---

F-5 — Trigger API v1 and v2 are simultaneously documented as active without migration guidance

Partly fixed Re-check of the published text, 11 October 2026.

Category. Product-lifecycle hygiene + cross-version coexistence Affected files. All Trigger reference specifications + /portal/plans.

Observation. Two versions of the Trigger API are documented as active simultaneously:

• 2 specifications declare server URL https://api.jup.ag/trigger/v1: cancel-order, create-order.
• 8 specifications declare server URL https://api.jup.ag/trigger/v2: challenge, confirm-cancel, deposit-craft, order-history, update-order, vault-register, vault, verify.

The rate-limit table at /portal/plans lists both v1 and v2 endpoints as billable. There is no migration banner on either set; no deprecation date for v1; no "v2 is the recommended path" guidance in narrative documentation. The v1 specifications are internally consistent (both cancel-order and create-order declare info.title: Jupiter Trigger Order API, info.version: 1.0.0, and server URL https://api.jup.ag/trigger/v1); the gap is not within any single spec but across the surface — nothing in the corpus tells an integrator which version to target.

Developer impact. A new consumer integrating "the Trigger API" has no documentation-derived guidance on v1 vs v2. The decision becomes either reverse-engineer from endpoint coverage (v2 has 8 endpoints vs v1's 3) or examine the rate-limit credits (both are 1 credit per call). Neither produces confidence in the choice.

Recommendation. Add a migration banner to all v1 Trigger pages with a published deprecation date. Add a "Choosing v1 vs v2" section to /trigger/index documenting which surface to target for new integrations and what backwards-compatibility v1 provides.

---

F-6 — Six Trigger v2 endpoints declare dual-scheme security (API key + JWT bearer) with undocumented semantics

Unchanged Re-check of the published text, 11 October 2026.

Category. API security metadata Affected files. Six Trigger v2 specifications: confirm-cancel, deposit-craft, order-history, update-order, vault-register, vault.

Observation. Each of these 6 specifications declares two security schemes in components.securitySchemes and references both in operation-level security: arrays:

security:
  - ApiKeyAuth: []
    BearerAuth: []
components:
  securitySchemes:
    ApiKeyAuth:
      type: apiKey
      in: header
      name: x-api-key
    BearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

Under OpenAPI 3.0 semantics, listing multiple schemes in the same security array entry means "all schemes required" (AND semantics); listing them as separate entries means "any one scheme sufficient" (OR semantics). The 6 endpoints use the former: both API key AND JWT bearer must be present. The 4 other Trigger v2 endpoints (challenge, cancel-order, create-order, verify) declare ApiKeyAuth only. The 6 dual-scheme endpoints are user-authenticated identity-bearing endpoints (vault, order-history)—the design appears to be "integrator API key for billing + user JWT for user-scoped identity"—but no narrative documentation explains the dual-scheme requirement.

Developer impact. A consumer parsing the OpenAPI spec without narrative context cannot determine whether to send one credential or both. Typed-client codegen often defaults to a one-scheme-at-a-time pattern and silently breaks against dual-scheme endpoints. A developer integrating user-authenticated flows discovers the JWT requirement at request time (via 401 response) rather than at integration design time.

Recommendation. Add a brief inline narrative on each of the 6 dual-scheme endpoints explaining: (a) why both schemes are required (user identity + billing accounting), (b) where to obtain the JWT (presumably from the /challenge + /verify flow), (c) what request header form is expected for each. Add a "Trigger Authentication" overview page at /trigger/authentication explaining the dual-scheme model.

---

F-7 — Schema definitions duplicated across endpoint specifications without cross-file reference

Unchanged Re-check of the published text, 11 October 2026.

Category. OpenAPI authoring discipline + cross-endpoint schema coherence Affected files. Six schema types across 21 occurrences.

Observation. Mintlify's inline-YAML-OpenAPI pattern places a self-contained OpenAPI specification fragment in each endpoint markdown file. Schemas shared across endpoints are copy-pasted rather than centralized:

Byte-identity confirmed via md5sum on the lend/earn schemas. The schemas are not cross-referenced via $ref: '#/components/schemas/<Name>' even though Mintlify's OpenAPI rendering supports the pattern.

Developer impact. Naive client-codegen against the per-endpoint specifications emits 21 duplicate definitions across 6 distinct concept types. Consumer codebases that generate one client module per OpenAPI spec accumulate redundant type definitions. When a vendor-side schema change happens, the duplication multiplies the surface area where the change must propagate (today: byte-identical; tomorrow: silently divergent if one file is updated and others are not).

Recommendation. Extract shared schemas to a central spec file referenced via $ref: '#/components/schemas/<Name>' cross-file. Mintlify supports the pattern. Alternative: enforce byte-equivalence of duplicated schema bodies at the doc-build pipeline (hash-and-compare).

---

Medium severity

F-8 — API-key portal hostname inconsistency — three URLs cited

Fixed Re-check of the published text, 11 October 2026.

Category. Documentation internal consistency Affected files. api-reference/transaction/submit vs other 74 endpoint specs vs /llms.txt + portal narrative pages.

Observation. The OpenAPI description field for the ApiKeyAuth security scheme cites three different URLs across documentation:

• 74 endpoint specifications: Get API key via https://developers.jup.ag/portal
• 1 endpoint specification (api-reference/transaction/submit): Jupiter API key from portal.jup.ag
• Narrative documentation + llms.txt content: https://developers.jup.ag/portal (consistent with the 74)

The portal.jup.ag outlier is a third hostname presumably DNS-aliased or redirected to the same destination, but inconsistent with the canonical citation pattern.

Developer impact. Developers consulting different documentation pages encounter three different portal URLs. Tooling that programmatically extracts the portal URL from OpenAPI metadata sees inconsistent values across specifications.

Recommendation. Align the transaction/submit specification to use https://developers.jup.ag/portal like the other 74. Add a doc-build pipeline check that asserts a single canonical portal URL across all OpenAPI description fields.

---

F-9 — Documentation-index banner positioned before H1 in every file

Unchanged Re-check of the published text, 11 October 2026.

Category. Markdown structural convention Affected files. All 248 pages.

Observation. Every page in the documentation set begins with a 3-line blockquote banner before the H1 title. The first H1 of each page appears at line 5 rather than line 1. This inverts the markdown convention where H1-at-top is the structural idiom, and creates a consistent visual + structural offset across the entire corpus. Combined with F-1's host-correctness issue, the banner is doubly problematic: structurally displacing AND host-leaking.

Developer impact. Plain-markdown readers see boilerplate before content. Anchor-link offsets shift across every page. Documentation extractors and search indexers that emphasize the top-of-page content prioritize the banner over the actual page title.

Recommendation. Relocate the documentation-index reference into a per-page footer or an inline <Tip> block AFTER the H1. Decouple the banner from the structural top-of-file position so the H1 leads the file.

---

F-10 — Singleton /tx/v1 host-path for the Transaction Submission API

Partly fixed Re-check of the published text, 11 October 2026.

Category. URL convention coherence across product surfaces Affected files. api-reference/transaction/submit.

Observation. The Transaction Submission endpoint declares server URL https://api.jup.ag/tx/v1—the only specification in the documentation using the /tx path prefix. All other product surfaces use one of /swap, /trigger, /recurring, /lend, /prediction, /price, /tokens, /portfolio, /send, /studio, with the full product name. The pricing table at /portal/plans lists /tx/v1/submit under a "Transaction" billing surface; rate-limit policy at /portal/rate-limits mentions /submit has its own dedicated bucket. So tx IS a product surface, just one with a single endpoint and an abbreviated path prefix that breaks the convention everywhere else.

This file also carries the outlier portal URL (F-8), making it the highest per-spec anomaly density in the corpus.

Developer impact. A consumer reasoning about product surface from path prefix (the convention everywhere else) sees tx as an outlier requiring special handling.

Recommendation. Either rename the host-path to https://api.jup.ag/transaction/v1/submit to match the convention, or add a top-level /transaction/index page explaining that tx is a product alias for transaction-submission.

---

F-11 — Price API V3 declares bare host as server URL, breaking the per-product path-prefix convention

Unchanged Re-check of the published text, 11 October 2026.

Category. OpenAPI server-URL declaration convention Affected files. api-reference/price.

Observation. The Price API specification declares server URL https://api.jup.ag (no path prefix) while all 77 other specifications declare https://api.jup.ag/<product>/<version>. The Price API's actual endpoint is GET /price/v3 (confirmed in narrative documentation and recipe examples), but the OpenAPI fragment splits this between the bare-host server URL and the operation path /price/v3. This contradicts the convention where the server URL contains the product-and-version prefix and the operation path is the sub-resource path.

Developer impact. Consumer typed-client codegen that strips the server URL prefix to derive product-namespace produces an empty namespace for the Price API. Cross-product URL-resolver helpers must special-case Price.

Recommendation. Align the Price API specification: server URL https://api.jup.ag/price/v3, operation path / or /quote. Match the convention used by Swap, Trigger, Recurring, Lend, Prediction, Tokens, Portfolio, Send, Studio.

---

F-12 — Prediction Market API is BETA across the entire surface without published GA target

Unchanged Re-check of the published text, 11 October 2026.

Category. Product-lifecycle policy Affected files. 13 pages across /prediction/* and /api-reference/prediction/*.

Observation. Every page in the Prediction Market API surface declares a BETA notice. Sample text:

"The Prediction Market API is currently in beta and subject to breaking changes. If you have feedback, reach out in Discord."

No GA target date is published; no breaking-change advance-notice window is committed; no auto-migration tooling is promised. The single 2026-04 changelog entry confirms that breaking changes are landing (markets[].metadata.* moved to top-level on 2026-04-10; minimum order amount increased from $1 to $5 on 2026-04-14)—both with deadline-driven enforcement, both with no migration tooling published.

Developer impact. A consumer building against a BETA surface accepts that breaking changes are possible but expects guidance on when GA happens, what migration support is offered, and what versioning policy will apply at GA. None of these are documented.

Recommendation. Publish a /prediction/beta-policy page declaring: (a) target GA date or "BETA indefinitely; commit to N-day breaking-change advance notice", (b) advance-notice window (e.g., 30 days), (c) auto-migration tooling (if any—a request-shape linter would close the loop on the 2026-04 changelog entries), (d) versioning policy at GA.

---

F-13 — 107 endpoint reference pages absent from llms.txt — 43% of API reference surface invisible to LLM agents

Unchanged Re-check of the published text, 11 October 2026.

Category. LLM-substrate completeness Affected files. llms.txt + 107 endpoint reference pages.

Observation. The mirror combines two URL sources: llms.txt lists 141 URLs; sitemap.xml lists 219 URLs; the union after dedup is 248 URLs. The gap—107 URLs in sitemap but not in llms.txt—is exclusively under /api-reference/{lend,portfolio,prediction,recurring,send,studio,swap,tokens,trigger}/*: individual per-endpoint reference pages.

llms.txt enumerates concept docs and section index pages but skips the per-endpoint API reference pages. An LLM agent that treats llms.txt as authoritative discovery surface for Jupiter's documentation misses 43% of the API reference content—every CRUD operation, every endpoint-specific parameter, every per-endpoint schema.

Developer impact. AI-tooling consuming llms.txt as authoritative discovery (which is its purpose) sees Jupiter's documentation at 57% completeness. Manual cross-check against sitemap is required to fill the gap.

Recommendation. Either enrich llms.txt to enumerate per-endpoint reference pages alongside concept docs, or publish a separate /llms-api.txt companion that enumerates per-endpoint pages. Coordinate with the Mintlify platform team if the omission is a default-template behavior.

---

F-14 — Sitemap.xml regenerated 6 days before mirror date but uses the legacy host across all 219 URLs

Fixed Re-check of the published text, 11 October 2026.

Category. Host-migration coordination — sitemap-specific Affected files. sitemap.xml.

Observation. The sitemap's <lastmod> timestamps range from 2026-01-26 to 2026-05-22; the most recent regeneration is 2026-05-22, 6 days before the mirror date. All 219 <loc> entries use the legacy host dev.jup.ag; zero use the canonical host developers.jup.ag. The docs-build pipeline IS actively regenerating sitemap.xml, just regenerating it against the wrong host.

This is the same root cause as F-1 (banner template host) but a distinct visible artifact. A SEO crawler reading sitemap.xml sees a freshly-regenerated index of legacy URLs and reasonably treats them as canonical.

Developer impact. Search-engine indexing happens against the legacy host. Cross-channel discoverability split persists.

Recommendation. Update the sitemap-generation step in the docs-build pipeline to emit canonical-host URLs. Add a CI assertion that every <loc> uses the canonical host.

---

F-15 — Changelog <Danger>Action Required</Danger> notice 14 days past enforcement still phrased as "upcoming"

Fixed Re-check of the published text, 11 October 2026.

Category. Changelog temporal hygiene Affected files. changelog/index.

Observation. The changelog entry for May 2026 announces:

"A breaking change is planned for Thursday, May 14, 2026 at 4:00 AM UTC / 12:00 PM SGT. Update Trigger V2 integrations that craft price-order deposits before enforcement."

The mirror date is 2026-05-28—14 days after the enforcement deadline. Either the enforcement happened (and the changelog wasn't updated to past-tense or moved to "Past enforcements") or the enforcement was deferred (and no follow-up note exists). A reader cannot determine the current state from the changelog alone.

Developer impact. A consumer reading the changelog today to decide whether the breaking change is still upcoming or already enforced finds no authoritative signal. Defensive coding (add orderType + orderSubType to all Trigger v2 deposit-craft requests proactively) is the safe path; the changelog doesn't surface this.

Recommendation. Convert past-deadline <Danger>Action Required</Danger> notices to past-tense form (<Info>Past enforcement: 2026-05-14</Info> or similar) once the deadline passes. Add a doc-build pipeline lint that flags <Danger> notices with past dates.

---

F-16 — Fifteen broken internal links across the corpus

Could not check Re-check of the published text, 11 October 2026.

Category. Link integrity Affected files. Cross-cutting; broken-link targets include /api-reference/swap/v1/quote, /api-reference/swap/v1/swap, /api-reference/ultra, /build, /docs/send, /docs/studio/create-token, /order, /price/v3, /swap/v1/add-fees-to-swap, /tokens/organic-score, /tokens/v2, /ultra, /ultra/add-fees-to-ultra, /ultra/index, /ultra/manual-mode.

Observation. A broken-link sweep over Markdown links of the form ](/path) finds 15 distinct missing targets. The largest cluster is the /ultra/* family (5 links), which ties to F-2 (Ultra surface absence). The /api-reference/swap/v1/* cluster (2 links) suggests a deprecated v1 Swap API surface that was referenced in narrative docs but not migrated when v1 reference docs were retired. The /docs/* cluster (2 links) suggests a dropped path-prefix convention from an earlier docs architecture.

Developer impact. Each broken link is a dead-end for a reader trying to follow a documentation thread. Cumulatively, 15 broken links across narrative docs signals docs-team capacity strain or absent link-checking in the build pipeline.

Recommendation. Add a link-validation step to the doc-build pipeline; fail build on broken internal link. For the /ultra/* cluster, redirect to /swap/migration/ultra-to-order (the migration stub). For the /api-reference/swap/v1/* cluster, redirect to /api-reference/swap/v2.

---

Low severity

F-17 — llms-full.txt is 1 MB — strategy divergent across vendor ecosystem

Unchanged Re-check of the published text, 11 October 2026.

Category. LLM-substrate strategy Affected files. llms-full.txt.

Observation. The bundled full-content file is 1021 KB. The "every page concatenated into one document" strategy contrasts with sibling Mintlify vendors that publish 38 KB curated agent-onboarding snippets. Neither approach is wrong but the absence of platform-consensus means an LLM agent budgeting context window for vendor-doc ingestion cannot generalize across vendors. Jupiter's strategy is read-once-cache-locally-friendly; alternative strategies are fit-in-context-window-friendly.

Developer impact. AI tooling has to special-case Jupiter's bundle size: download once, cache aggressively, parse offline rather than streaming into context.

Recommendation. Publish a brief llms-full.txt-strategy note explaining the choice and recommending consumption pattern (e.g., "consume once at agent boot; cache aggressively"). Coordinate with platform vendor on an emerging convention if possible.

---

F-18 — Lock and Perps sections have minimal content depth relative to navigation prominence

Unchanged Re-check of the published text, 11 October 2026.

Category. Documentation completeness Affected files. lock/index (1 file total) + perps/* (5 files total).

Observation. The lock/ section contains a single index page; Lock has no API reference under api-reference/lock/*. The perps/ section has 5 pages (index + 4 account-shape pages: custody, pool, position, position-request) but no integration guide and no Perps API reference. Both surfaces appear in top-level navigation alongside Swap (18 files), Lend (45 files), and Prediction (7 files + 24 reference files). The content depth gap is sharp.

Developer impact. A consumer encountering Lock or Perps from navigation and trying to integrate finds product marketing without integration spec.

Recommendation. Either expand content depth (publish API reference for Lock; publish integration guide for Perps) or demote from top-level navigation to a "Coming Soon" sub-section with target dates.

---

F-19 — Pervasive Mintlify JSX wrappers in every product-section file

Unchanged Re-check of the published text, 11 October 2026.

Category. Renderer portability Affected files. Cross-cutting.

Observation. JSX components <Tip>, <Steps>, <CodeGroup>, <Frame>, <Update>, <Accordion>, <Card>, <Columns>, <Note>, <Danger>, <Info> permeate the corpus. Mintlify renders these natively at the live docs site; any plain-markdown reader, mirror ingestion, or LLM context-window paste sees the raw JSX.

Developer impact. Developers reading docs offline (mirror, LLM ingestion, plain-markdown reader) see uninterpreted JSX wrappers. Content inside the JSX is still readable but the structural intent (warning vs tip vs step-by-step) is lost.

Recommendation. If platform-portable rendering is a goal, coordinate with Mintlify on a graceful-degradation export. Alternative: consumer-side parser that strips JSX wrappers if rendering offline.

---

F-20 — Migration pages are stranded — source surfaces partially absent from documentation

Unchanged Re-check of the published text, 11 October 2026.

Category. Documentation architecture Affected files. swap/migration/{ultra-to-order, metis-to-build, metis-to-meta-aggregator}.

Observation. Three migration pages exist in swap/migration/. The Ultra source surface is entirely absent (F-2). The Metis source surface (referenced via /api-reference/swap/v1/*) is partially broken-link (F-16). The migration pages describe "how to migrate from X" where X is no longer documented.

Developer impact. A new consumer arriving at the migration pages encounters a "migrate from X" instruction without context for what X is.

Recommendation. Each migration page should link back to a brief "what is the source product and why it's being deprecated" stub, OR fold migration content into the destination product's docs as an "Upgrading from <previous>" section.

---

F-21 — Legacy host returns 200 + 301-redirect rather than 410 Gone

Unchanged Re-check of the published text, 11 October 2026.

Category. Host-retirement policy Affected files. Cross-cutting (server-side behavior).

Observation. The legacy host https://dev.jup.ag returns HTTP 200 followed by a 301 redirect to https://developers.jup.ag/docs/ (per curl probe). It is not 410 Gone, not 404, not a soft-error. Google and Bing have indexed both hosts; cached external links to either host are served valid content; the docs-build pipeline regenerates artifacts (sitemap, banner) against the legacy host without surfacing the migration as a build-time concern.

Full retirement of the legacy host requires a multi-quarter migration: first publish a deprecation timeline; then transition to 301-permanent with Link: rel="canonical" headers; eventually transition to 410 Gone after the cache-window closes.

Developer impact. Until the legacy host is retired, host-coordination findings F-1, F-9, F-14, F-16 continue to surface. SEO and agent-ecosystem channels see inconsistent canonicity across an extended window.

Recommendation. Publish a host-migration timeline. Commit to 301-permanent + Link: rel="canonical" on legacy-host responses. After the published cache-window (typically 3-6 months), transition to 410 Gone.

---

Conclusion

Jupiter's API documentation is functionally substantial: 248 pages covering 10+ product surfaces, 78 inline OpenAPI specifications, 5 hands-on guides with linked-out demo apps, and comprehensive portal/rate-limits/setup content for developer onboarding. The corpus mirror integrity is excellent (zero fetch failures, zero documented 404s in the substrate fetch log).

The 21 findings catalogued above are documentation-quality issues, not API-design issues—the underlying APIs work; the documentation around them has accumulated rough edges that introduce avoidable friction for developers integrating across the Jupiter product ecosystem.

The two CRITICAL items (F-1 host-banner + sitemap migration coordination; F-2 Ultra surface billable + docs absent) likely share a single root cause each. F-1 stems from a docs-build pipeline configured against legacy infrastructure—fixable in one pipeline change. F-2 stems from a product-lifecycle decision (deprecate Ultra in favor of Swap V2) that propagated to the migration stub but not to the rate-limit/billing surface—fixable by either restoring docs or removing billing.

The HIGH-severity items concentrate on cross-product consistency. The Jupiter API ecosystem has grown to 10+ independently-evolved product surfaces with their own naming conventions, version-numbering schemes, security models, and OpenAPI authoring patterns. Consolidating per-surface conventions toward a unified policy would materially reduce per-developer integration overhead and would likely simplify Jupiter's own documentation maintenance burden by reducing the per-surface authoring divergence over time.

The remaining MEDIUM and LOW items are individual improvements that compound over a developer's integration experience: an inconsistent portal hostname, a banner displacing the H1, a singleton host-path, a missing version target, an LLM-index coverage gap. None is blocking; each is cheap to fix; cumulatively they signal documentation-team capacity and care.

A particularly strong note on Jupiter's recipes (/guides/how-to-*): the recipes are written as curl + javascript snippets with substantive code externalized to git-versioned demo apps at github.com/jup-ag/api-examples/*. This is a strong pattern—it offloads end-to-end testing to consumers who clone the demo repos and verify in their own environments, rather than leaving propagated-bugs in the docs themselves. Worth keeping.

We hope this review is useful. Happy to clarify any specific finding, discuss prioritization, or revisit specific surface areas in more depth.

---

Independent documentation review prepared by Ondřej Dvořák / Pukapasoft. © 2026 Pukapasoft. Findings IDs are opaque sequence numbers internal to this report. V3 — 2026-05-31 — correction pass: F-3 title count fixed (15 → 14); F-5 retracted a non-existent create-order spec inconsistency (v1/v2-coexistence finding unaffected); F-2 reduced to directly-verifiable Jupiter facts. Severity and recommendation of every finding unchanged.