2.1

One slow endpoint could trip the circuit breaker for its whole integration and take every other method on that platform down with it.

An integration's circuitBreaker config accepts granularity: 'method', which keys each breaker by API method instead of by integration. A methods: string[] sibling narrows it to the listed methods. The default is unchanged, so nothing changes until you set it. CB_GRANULARITY / CB_METHODS and their per-integration variants override both without a code change.

middleware_circuit_breaker_state reported an open breaker as closed, so nothing reading the metric could tell a tripped breaker from a healthy one.

The gauge now reports 0 while a breaker is open. When an integration has more than one breaker, it reports the most degraded state among them. On @alokai/connect 2.0.1 it could only ever read 1 or 0.5.

At the versions you're on, createUnifiedExtension's parameters and the extendApiMethods object it returns aren't type-checked. The published declarations import a type from a package that isn't on npm, and the generated apps' skipLibCheck: true hides the error, so the type silently becomes any.

The declarations no longer import from an unpublished package, so they resolve in your project. Each package adds a "./dist/*" subpath export, which the declarations use to reach each other.

The Nuxt browser build has no implementation of Node's util, yet the logger it bundles imports inspect from util and calls it on a code path meant for the browser.

apps/storefront-unified-nuxt/nuxt.config.ts gains a vite.resolve.alias entry that maps util to unenv/node/util. Nuxt aliases Node builtins for the client only under experimental.clientNodeCompat, which is off by default and isn't enabled anywhere in the storefront. unenv is already in your tree as a Nuxt dependency, so you don't add it.

A vulnerability in what the shipped storefront proxy sends has been identified and fixed. Whether your own proxy.ts has it depends on how your project reached this release.

In apps/storefront-unified-nextjs/proxy.ts, the guard on the X-Frame-Options: DENY header changes from env('NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER') !== 'false' to !== 'true'. The shipped .env.example sets that variable to false, so the old condition dropped the header from every response. true is now the only value that turns the header off. New projects also get a comment on the variable in .env.example.

If you use the Cloudinary image loader, any image with a source path over 255 characters came back as a 400 and rendered nothing. Cloudinary caps public_id at 255 characters.

apps/storefront-unified-nextjs/config/image-loaders/cloudinary/cloudinary.ts gains a guard. When src.length > 255, the loader logs a warning and returns src unchanged instead of building an upload URL. The public_id is also the address Cloudinary fetches the original image from, so it can't be hashed or truncated.

The helper typed its context parameter against the commerce integration's own context. So a call from any other integration's method failed typecheck, with nothing wrong behind it.

In apps/storefront-middleware/integrations/typedApiClient.ts, context is typed with the base IntegrationContext from @alokai/connect/middleware instead of the one from @/types. Every integration context extends the base type. Two import lines change and nothing else.

When a command ran ni in a directory with no lockfile, ni stopped at an interactive prompt asking which package manager you use. integration generate hit it, because it scaffolds in a temporary directory, and a non-interactive run can't answer the prompt.

@alokai/cli 2.4.2 detects your package manager from the project root and passes it to every command it runs through ni, so the prompt can't appear. A project generated at 2.1.3 also declares "@antfu/ni": "^28.0.0" in the root package.json devDependencies, not only through @alokai/cli's own dependencies.

sapccModule accepts refreshToken.refreshTokenMethodFactory. The SDK calls it at request time with its own httpClient, the resolved baseUrl, and the computed config of the failed request, and it returns the refresh function. refreshToken.refreshTokenMethod still works but is deprecated, and the package says it'll be removed in the next major release, dated Q3 2026.

The search-bloomreach module configures searchProducts and getProductDetails with defaults for Bloomreach Discovery. @vsf-enterprise/bloomreach-discovery-api also exports createUnifiedExtension, so you can wire the extension by hand - see the Unified Search Extension guide.

The integration fills in four parameters on every API call. brUid2 comes from the _br_uid_2 cookie, url from the request headers, and refUrl from Referer. requestId is a generated 13-digit number.

The new environment option takes "production" | "staging". With "staging", every Bloomreach host - core, suggest, pathways, and pathways-email - switches to its staging- equivalent.

One basePath applies to all four Bloomreach hosts, so pointing it at staging fixed search but broke autosuggest, email widgets, and recommendations.

basePath still works on its own and logs a deprecation warning on start. If you set both basePath and environment, the middleware throws on start instead of picking one.

In the search-bloomreach module, extensions/unified/index.ts and extensions/index.ts are gone, and the extension is inlined in config.ts. middleware/index.ts re-exports the unified exports of @vsf-enterprise/bloomreach-discovery-api. The module reads BLOOMREACH_DISCOVERY_ENVIRONMENT instead of BLOOMREACH_DISCOVERY_BASE_PATH.