Changelog

Changelog: October 2026

Changelog: October 2026
YYYY··4 min read

What shipped across Jupiter's developer APIs in October 2026. Publishable API keys make a key safe to ship in a public client, the Swap API gains Solana transaction v1, and the public Portfolio API is retired.

Breaking changes

Portfolio: the public Portfolio API is retiredBreaking

The public Portfolio API is no longer a supported public product. Its documentation and API reference have been removed, and portfolio data is now available to B2B partners only.

  • Stop depending on the public api.jup.ag/portfolio/v1 endpoints (positions, platforms, staked-jup); they are no longer documented or supported
  • There is no public replacement: portfolio data access is B2B only, with no public sign-up
  • If you integrated the public Portfolio API, treat it as unsupported and reach out through support

WTM (what this means) - The public Portfolio API was lightly used and is moving to a B2B-only model. If your app reads from /portfolio/v1, plan to remove that dependency; the endpoints may change or stop responding without further notice.

Support

Platform

Publishable API keys for public clients

API keys now come in two kinds. Existing keys are server keys and work exactly as before. A new publishable key is safe to ship in a browser, mobile app, extension, or any public client where anyone can copy it.

  • A publishable key behaves like a request with no API key: the same per-IP keyless rate limits, the same endpoints, 0 credits, and never billed. A copied publishable key grants nobody anything extra.
  • The only difference from sending no key is attribution. Publishable-key requests are logged under your organisation, team, and key, so they appear in your analytics, and your organisation is passed to Swap routing so org-specific fees and routing still apply.
  • Create a publishable key in Portal, or convert an existing frontend key: the key value stays the same, so your app needs no change, and it takes effect in about 15 seconds. Conversion is one-way, so move any backend traffic off the key first.

WTM - A server key in a browser exposes your organisation's full rate limit and credits to anyone who copies it. Make keys that ship in a public client publishable, then delete the firewall rules you added to protect them. Publishable keys do not use your plan's rate limits or your organisation's access to protected endpoints, so keep those calls on your backend with a server key.

Swap

Solana transaction v1 support across the Swap API

You can now request Solana v1 transactions (the "larger transaction sizes" upgrade) from the Swap API. v1 raises the transaction size limit from 1232 to 4096 bytes and inlines up to 64 accounts, so routes that needed Address Lookup Tables fit without them. v1 is opt-in; v0 remains the default and is not deprecated.

  • On the Router (/build), pass transactionVersion=1 to force a v1 build. The response returns an empty computeBudgetInstructions and addressesByLookupTableAddress, plus computeUnitPrice to set on the message config along with your own compute unit limit and loaded accounts data size limit.
  • On the Meta-Aggregator (/order), pass maxSupportedTransactionVersion=1. This is a ceiling, not a force: you get v1 only when Metis wins and the order is not gasless, so read the response transactionVersion for the version you got. /execute lands either.
  • Build, deserialize, and sign v1 transactions with @solana/kit v8 or later. @solana/web3.js v1 cannot read v1 transactions.

WTM - If you hit the 1232-byte limit adding instructions to a swap, or you want to stop resolving lookup tables, opt into v1. New routing features target v1, so prefer it for new integrations.

Transaction Versions · Build · Order & Execute

YY

October 8, 2026