VTEX Release Notes

Bug Fix

Versioned Authenticator routes for My Account B2B Buyer Portal (PR: #3398)

FastStore now uses versioned Authenticator API routes for password reset flows. The password reset and authentication start requests now include the v1 segment in the API path, following the expected Authenticator route format.

Stores using FastStore My Account password reset should upgrade to v4.4.0 to avoid issues when unversioned Authenticator paths are deprecated. No configuration changes are required, and no deprecation date has been set at this time.

Improvement

CMS aware cms-sync command (PR: #3406)

The faststore cms-sync command now supports stores using the CMS. Previously, these stores had to run schema generation and upload commands separately. Now, the command identifies the store's CMS setup and automatically runs the appropriate sync flow.

For stores using the CMS, the command includes schema generation and upload in the sync process. It also checks the VTEX CLI version and verifies the authenticated VTEX account before running schema generation.

Stores using the CMS should upgrade to v4.4.0 and run faststore cms-sync instead of separate schema commands. Stores using the Headless CMS (legacy) integration see no workflow change.

Localization feature (Closed Beta)

Sync Intelligent Search locale with URL on navigation (PR: #3405)

FastStore now keeps Intelligent Search queries aligned with the active URL locale during client-side navigation.

Previously, stores using the Localization feature (Closed Beta) could experience stale locale data after switching locales or using browser back and forward navigation. This could cause Product Listing Pages, search results, or shelves to display product information in the wrong locale.

With this update, FastStore derives the search locale from the active route and prioritizes the locale selected in the URL. This helps ensure product names and slugs update correctly after a locale switch.

Stores with localization.enabled should upgrade to v4.4.0 and verify that Product Listing Pages, search pages, and shelves are accessible under locale-prefixed URLs. No configuration changes are required.

CMS-backed My Account for B2B Buyer Portal pages (PR: #3354)

My Account for B2B Buyer Portal pages can now use CMS content. Previously, these pages relied on hardcoded English copy and could not be customized.

This update adds CMS content types and section schemas for My Account for B2B Buyer Portal pages, including profile, orders, order details, user details, security, and unauthorized access. If CMS content is available, My Account for B2B Buyer Portal pages render the published content. If CMS content is empty or unavailable, pages continue to render with default English content.

Merchants can use the CMS to localize labels, reorder sections, and customize order status badges. Stores with localization.enabled should upgrade to v4.4.0 and run the faststore cms-sync in the terminal.

i18n support for My Account for B2B Buyer Portal navigation (PR: #3400)

My Account for B2B Buyer Portal routes now preserve the active locale during navigation and server-side redirects.

Previously, private My Account routes could drop the locale prefix when users navigated between account pages or were redirected on the server side. For example, a user could be redirected from /pt-BR/pvt/account/orders to /pvt/account/orders.

With this update, My Account links, filters, pagination, order details, and server-side redirects preserve the active locale. Price and date formatting also follow the locale from the current route.

Stores with localization.enabled and path-based bindings should upgrade to v4.4.0 and verify My Account navigation, redirects, and formatting under locale-prefixed URLs.

Original source

The new Intelligent Search API v1 is now available for headless integrations at /api/intelligent-search/v1/*. It replaces Intelligent Search API (Legacy) at /api/io/_v/api/intelligent-search/* with HTTP caching, lower latency, and explicit context parameters.

What has changed?

Here is a summary of the key differences between Intelligent Search API (Legacy) and Intelligent Search API v1. See the sections below for full details.

HTTP caching

Responses from most endpoints now include a Cache-Control header, enabling CDN and browser caching for public sales channels. This reduces origin load and improves storefront response times.

Always read the Cache-Control header at runtime to determine cacheability. Don't hardcode cache durations in your integration.

Exceptions:

• Responses containing sponsored products (VTEX Ads) are not cached, preventing ad impressions from being served from a shared cache.
• Private sales channel responses: not cached.

Explicit context: No segment cookie

Intelligent Search API (Legacy) relied on the VTEX segment cookie to fill in locale, sales channel, regionalization, and marketing context. Intelligent Search API v1 does not read the segment cookie. All context must be passed explicitly as query parameters or facets in the URL path.

If your store uses Delivery Promise for headless stores, the following parameters were previously passed via the segment facets string and must now be passed as explicit query parameters on GET Search products (v1), GET List filters for a search (v1), and GET Get pickup point availability for Delivery Promise (v1):

• country, zip-code, and optionally coordinates (buyer's address, the fundamental parameters)
• deliveryZonesHash and pickupPointsHash (pre-computed alternative for faster lookup; hashes expire and require a specific renewal flow, so always have the address available as a fallback)
• pickupPoint

New URL structure

The IO prefix has been removed, underscores in path names have been replaced by hyphens, and /v1 has been added to the path.

New endpoint: Get product

A new GET Get product (v1) endpoint is now available for product detail pages (PDP). Given a known identifier (product ID, slug, EAN, SKU ID, or reference), it returns a single product without going through the search pipeline, resulting in lower latency and better cache-hit rates than GET Search products (v1).

New data returned in product search

Intelligent Search API v1 returns additional and corrected data in products[].items[] on the following endpoints:

• GET Search products (v1) (previously GET Get list of products for a query)
• GET Get product (v1) (new)

Fields that previously returned incorrect or empty values, such as isKit, modalType, and images[].imageText, now return correctly, potentially resolving a known issue.

What needs to be done?

For a step-by-step migration checklist, see Migrating to Intelligent Search API v1.

All new headless integrations must use Intelligent Search API v1.

Intelligent Search API (Legacy) remains available for existing integrations, but its endpoints will be deprecated in a future announcement. We recommend migrating existing integrations as soon as possible.

To access all performance and reliability improvements in Intelligent Search API v1, headless integrations should use the REST API directly. Integrations using Search GraphQL aren't recommended for headless implementations and should be migrated to Intelligent Search API v1.

Related resources

• Intelligent Search API v1
• Intelligent Search API (Legacy)
• Migrating to Intelligent Search API v1

Original source

The Activity Flow SDK for mobile now supports customer interaction event tracking (click, view, and impression) in React Native and Flutter apps. This aligns the mobile SDKs with the web script, so you can measure the full engagement funnel (rendered → seen → clicked) for any component in your app, not just page views and ad events.

What has changed?

Previously, mobile apps supported only page views and ad events. Customer interaction tracking was available on the web via the Activity Flow script.
Now, React Native and Flutter apps support click, view, and impression tracking.

React Native

• Click tracking: Use the new useClickObserver hook to capture tap interactions. It returns an afHandlePress callback to call in your press handler.
• View tracking: Use the new useViewObserver hook to detect when a component is at least 50% visible for 1 second. It returns an afViewRef that can be attached to the target view.
• Impression tracking: Use the new useImpressionObserver hook to record when a component is rendered, regardless of viewport visibility. It re-fires only when the tracked attributes change.

Flutter

• Click tracking: Use the new addClickListener extension method on any widget to capture tap interactions.
• View tracking: Use the new addViewListener extension method to fire a view event when the widget is at least 50% visible for 1 second (per IAB standards). It fires once per app session.
• Impression tracking: Use the new addImpressionListener extension method to record when a widget is built and rendered in the widget tree.

What needs to be done?

To implement interaction event tracking in your app, see the related guides:

• Installing Activity Flow in React Native apps
• Installing Activity Flow in Flutter apps

Original source

What has changed?

FastStore WebOps now provides a self-service interface to change the GitHub organization and repository associated with your project. This feature streamlines the process of moving FastStore projects between organizations or repositories, eliminating the need to open support tickets for repository migrations.

The Integrations tab in the FastStore WebOps dashboard now includes a Git Provider section to configure the GitHub organization and repository associated with your FastStore project.

Before, moving a FastStore project to a different GitHub organization or repository required opening a ticket with VTEX Support and providing detailed information, including repository IDs, installation IDs, and account details. The process involved multiple manual steps and coordination with the Support team.

Now, you can change your project's connected repository directly from the WebOps dashboard. The Git Provider card allows you to:

• Change the GitHub organization: Switch your project to a different GitHub organization by clicking Change account and selecting the target organization.
• Change the repository: Move your project to a different repository within the same organization by selecting the target repository from the dropdown.

Why did we make this change?

This change simplifies the repository migration process and gives developers more control over their FastStore project configuration.

What needs to be done?

The feature is available to all FastStore projects using WebOps that meet the required permissions (Owner role in VTEX Admin and Admin role in GitHub repositories).

For FastStore projects hosted in the vtex-sites organization, open a ticket with VTEX Support to move your project to your account's GitHub organization.

To change your Git Provider configuration:

1. In your VTEX Admin, go to Storefront > FastStore WebOps and navigate to the Integrations tab.
2. In the Git Provider card:
   • To change organizations: Click Change account under Account/Organization, select the target organization on GitHub, grant repository access, and select the target repository in WebOps.
   • To change repositories in the same organization: Select the target repository from the Repository dropdown.
3. Click Save to apply your changes.

The repository change feature isn't available for private GitHub instances. The WebOps dashboard won't display the option if your project is connected to a private GitHub instance.

Learn more in the guide Moving your FastStore project to a new GitHub repository.

Original source

Starting July 1, 2026, the VTEX Ads API metrics object, returned in campaign, ad group, and ad responses, will include new fields that break down performance by attribution type and expose halo effect data. Additionally, the roas field will reflect a consolidated click-and-view attribution model across all ad formats.

What has changed?

The following fields have been added to the metrics object across campaign, ad group, and ad responses:

Conversion breakdowns

• conversions_click: Number of conversions attributed to clicks
• conversions_view: Number of conversions attributed to views

Conversion rate breakdowns

• conversion_rate_click: Conversion rate attributed to clicks
• conversion_rate_view: Conversion rate attributed to views

ROAS breakdowns

• roas_click: ROAS attributed to clicks
• roas_view: ROAS attributed to views
• roas_halo: ROAS attributed to halo effect purchases
• roas_overall: Overall ROAS combining all attribution types

Halo effect metrics

• halo_revenue: Revenue generated from halo effect purchases
• halo_orders: Number of orders from halo effect purchases
• halo_items: Number of items from halo effect purchases

The roas field will reflect a consolidated click-and-view attribution model across all ad formats.

What needs to be done?

• If your integration reads the roas field for Sponsored Products campaigns, expect higher values starting July 1, 2026. The increase reflects the addition of view-attributed revenue, not a change in ad performance.
• Optionally, update your dashboards or analytics pipelines to consume the new granular fields (roas_click, roas_view, roas_halo, roas_overall, conversion_rate_click, conversion_rate_view) for attribution-level breakdowns.
• No action is required to receive the new fields: they are returned automatically in existing API responses.

Learn more about the VTEX Ads metrics change in the announcement: New ROAS calculation methodology for Sponsored Products.

Original source

This release introduces storefront password protection and QuickOrder file upload through the VTEX Order Entry Service (OES), along with fixes for My Account authentication, password reset routing, and GraphQL BFF error status propagation. It also migrates Partytown to the maintained @qwik.dev package. See the sections below for details and upgrade notes.

Follow the instructions in Updating the CLI package version to upgrade to v4.3.0 and keep your store up-to-date with the following improvements.

Features

Password Protection (#3276)

FastStore now ships a password-protection flow for gated storefront access. The change adds middleware that validates a secure session cookie, a /api/fs/password-protection/unlock endpoint that verifies passwords and returns a safe redirect URL, and a login page for protected environments. WebOps settings continue to drive which domains require authentication. The CLI also removes localization-based proxy filename toggling from dev and build commands.

Merchants can restrict preview URLs and production domains to authorized users, reducing accidental public exposure during development and launch. Upgrade your store to v4.3.0 and configure password protection in FastStore WebOps to enable the storefront login flow.

File upload via Order Entry Service (OES) (#3334)

QuickOrder file upload now uses the VTEX Order Entry Service instead of a rigid CSV parser.

• @faststore/api adds GraphQL operations (uploadFileToOrderEntry, startOrderEntryOperation, orderEntryOperation, orderFormItems) and VTEX commerce client methods for the OES flow.
• @faststore/core introduces useOrderEntryUpload, useOrderEntryOperation, useOrderFormItems, and the orchestration hook useOrderEntry.
• @faststore/components adds a Processing state to FileUploadStatus with a configurable processingStatusText label.
• SearchInput is refactored to use the OES-backed flow end-to-end, and the legacy useCSVParser hook and useBulkProductsQuery are removed.

Stores using QuickOrder file upload can accept more file formats and benefit from server-side parsing with AI-assisted extraction. The UI flow remains upload → processing → drawer, but processing is now distinct from upload. No configuration changes are required beyond upgrading your store to v4.3.0 and republishing CMS content if you customize processingStatusText in the Navbar schema.

Bug Fixes

Propagate upstream error status instead of always 500 (#3379)

The GraphQL BFF at /api/graphql previously returned HTTP 500 for all errors because masked GraphQLError instances hid the nested FastStoreError that carries extensions.status. The handler now unwraps masked errors via recoverFastStoreError and returns the upstream status (for example, 400 for invalid shipping postalCode). Non-production responses include structured extensions.type and extensions.status; upstream messages are omitted in production.

API consumers and debugging workflows now receive accurate HTTP status codes instead of generic 500 responses. The storefront SDK still builds errors from response.status before reading the body. Upgrade your store to v4.3.0 and review any custom error handling that assumed all BFF failures were 500.

Order Entry header authentication fix (#3395)

After #3381 removed the withAutCookie helper, the Order Entry Service client methods introduced in #3334 still referenced the helper, breaking builds and file upload requests. The five orderEntry methods now use the same withCookie header pattern as other authenticated commerce calls, preserving multipart/form-data for file upload.

Stores using OES-backed QuickOrder file upload should upgrade to 4.3.0 together with #3334. No separate configuration is required.

Dependencies updates

Migrate Partytown to @qwik.dev (#3394)

@faststore/core replaces @builder.io/partytown@^0.6.1 with @qwik.dev/partytown@^0.14.0, following the official Partytown package relocation. Runtime behavior is unchanged: the CLI still runs partytown copylib at predev / prebuild and loads static assets from /~partytown/partytown.js.

After upgrading to v4.3.0, re-run faststore dev or faststore build so public/~partytown/ is regenerated. No store configuration changes are required.

My Account for B2B Buyer Portal (Closed Beta)

Forward auth token only via account-scoped cookie (PR: #3381)

Logged-in shoppers were redirected to /pvt/account/403 when accessing FastStore My Account because @auth-protected GraphQL queries forwarded the VTEX ID token twice—via the account-scoped cookie and a duplicated top-level header. The platform rejected the duplicate with 401 even for valid sessions. This PR standardizes authenticated VTEX requests on the account-scoped cookie pattern used elsewhere in @faststore/api.

Stores with experimental.enableFaststoreMyAccount enabled should regain access to My Account routes after upgrading. No configuration changes are required.

Use authenticator route for set password (#3380)

The My Account Reset password flow in useSetPassword now posts to /api/authenticator/pub/authentication/classic/setpassword instead of the deprecated /api/vtexid/pub/authentication/classic/setpassword endpoint. The account name is passed explicitly via the an query parameter, sourced from the hook argument with a fallback to config.api.storeId. The request method, credentials, form body, and success/error toast mapping remain unchanged.

Stores using FastStore My Account security settings should verify the password reset after upgrading. No configuration is required.

Original source

The VTEX Admin order details page now displays custom order data for all stores. Merchants and store operators can view store-level custom fields (customFields) and per-app payloads (customApps) directly from the order details page and print view, with no additional setup required.

What has changed?

Previously, this feature was available in open beta and required stores to contact VTEX Support to enable it. Now, custom order data is available to all stores by default. When an order contains customData, both the order details page and print view display the information in collapsible groups, one for custom fields and one for app payloads.

Why did we make this change?

In order to give all merchants and store operators a complete view of order information without leaving the VTEX Admin, we made custom data visibility generally available. This eliminates the need to rely on API calls or manual enablement to access order-level custom data.

What needs to be done?

No action is required. Custom order data is now automatically visible in the order details page and print view of the VTEX Admin for all stores that have customData attached to their orders.

Original source

This release brings targeted improvements across performance, localization, session handling, and CLI reliability. Highlights include faster PLP image loading and SSR behavior, fixes for localized routing and session hydration, and Windows-specific CLI import normalizations. See the sections below for details and upgrade notes.

Performance

Image preloading for Product Listing Pages to improve LCP score (PR: #3348)

Image preloading for Product Listing Pages to improve LCP score (PR: #3348)

ProductListingPage now injects a preload link for the first product card image on the page, and ProductGrid sets fetchPriority: 'high' on the first row of product images (up to 4). ProductCard also forwards the fetchPriority prop to the underlying image component.

This improves the Largest Contentful Paint (LCP) score on mobile by prioritizing the first product image load. No public API changes — fetchPriority is additive via imgProps on ProductCard.

SSR ProductGallery and reduced CLS (PR: #3349)

SSR ProductGallery and reduced CLS (PR: #3349)

ProductGallery is now server-side rendered by replacing the previous React.lazy dynamic import with a static import. Additionally, useScreenResize was updated to use an isomorphic useLayoutEffect so screen-size flags are set synchronously before the first paint.

This eliminates Cumulative Layout Shift (CLS) on PLP first paint. Note that ProductGallery is no longer lazily loaded, so the parent bundle may grow slightly in exchange for a reduced layout shift.

PLP first-page refetch anchored to page-load time (PR: #3350)

PLP first-page refetch anchored to page-load time (PR: #3350)

The first-page refetch decision for PLP queries now uses a per-mount client-side page-load timestamp instead of the server build time. This prevents an unnecessary client-side refetch immediately after SSR hydration and preserves the SSR-injected cache. The 5-minute refetch window is maintained but is now anchored to the user's session (page open time).

Bug fixes

Session refresh bypassed on localhost (PR: #3325)

Session refresh bypassed on localhost (PR: #3325)

Adds a shared isLocalHost utility and uses it to bypass the cross-origin refresh-token flow on localhost in both the useRefreshToken hook and the /pvt/account/403 getServerSideProps logic.

This prevents an always-failing refresh POST from triggering logout when developers manually inject a VtexIdclientAutCookie_ cookie while running the app locally. Behavior on non-local hosts is unchanged.

packageManager field stripped from generated .faststore/package.json (PR: #3335)

packageManager field stripped from generated .faststore/package.json (PR: #3335)

The CLI now builds .faststore/package.json without leaking the upstream packageManager or exports fields, and injects the store root's volta config when present. The CLI also now always prints tool stdout/stderr on failure (no need for DISCOVERY_DEBUG).

CLI createNextJsPages errors no longer block discovery.config copy (PR: #3356)

CLI createNextJsPages errors no longer block discovery.config copy (PR: #3356)

The CLI initialization flow now catches errors thrown by createNextJsPages so that a failure to create Next.js pages/APIs no longer prevents copying the store's discovery.config into the .faststore folder. This is an internal error-handling fix with no breaking changes.

Windows URL resolution fixed in CLI (PR: #3337)

Windows URL resolution fixed in CLI (PR: #3337)

Normalizes module URLs used by @faststore/cli when loading user/project configs, plugins, and discovery files. This fixes dynamic import failures on Windows caused by Windows-style (C:/) ESM paths. CLI commands, including build, dev, start, cache, cms-sync, i18n, and test, are affected. No changes for macOS/Linux users.

For Windows users:

• If you haven't seen any import/path errors, do nothing.
• If you experienced failures (errors like module-not-found or dynamic import errors when running those commands), upgrade @faststore/cli to version 4.2.0 and re-run the command.

Pages backed by CMS silently missed content beyond the first batch (PR: #3282)

Pages backed by CMS silently missed content beyond the first batch (PR: #3282)

ContentService.getPage now follows the CMS scroll token when calling listEntries, replacing a single API call with a loop that accumulates all entries across paginated responses before passing them to fillEntriesWithData.

Stores using the CMS data source will now receive all entries for a content type that span multiple pages (previously, only the first batch was returned).

SlideOver uses dynamic viewport height on mobile (PR: #3333)

SlideOver uses dynamic viewport height on mobile (PR: #3333)

Updated SlideOver styles to use 100dvh (dynamic viewport height) in addition to 100vh for non-bottomSide variants. This is a CSS-only fix that prevents bottom content (such as the Locale Switcher) from being cropped on mobile browsers where the browser chrome affects the effective viewport height. Desktop behavior is unchanged.

Image loader error at VTEX assets (PR: #3363)

Image loader error at VTEX assets (PR: #3363)

Corrected how the image loader handles VTEX asset URLs so images served from VTEX assets are loaded reliably. This is a backward-compatible bug fix with no API or configuration changes.

Flex alignment standardized in component styles (PR: #3357)

Flex alignment standardized in component styles (PR: #3357)

Replaced bare start/end flex alignment keywords with flex-start/flex-end in LocalizationSelector/styles.scss, OrganizationDrawer/section.module.scss, and Toast/styles.scss to remove autoprefixer warnings and ensure consistent behavior across browsers. No visual changes expected.

Localization feature (Closed Beta)

Locale validation fixed for disabled localization and private routes (PR: #3358)

Locale validation fixed for disabled localization and private routes (PR: #3358)

validateLocaleForHostname now imports the merged discovery.config (not just the default config), short-circuits when storeConfig.localization?.enabled is false, and skips validation for routes under /pvt/.

This fixes 404 errors on SSR pages after upgrading to FastStore v4 when localization is disabled (the default setting). Private authenticated routes under /pvt/ — such as /pvt/account and organization account pages — are no longer blocked by hostname-based locale validation. No developer action is required beyond upgrading.

Localization race condition on session hydration (PR: #3281)

Localization race condition on session hydration (PR: #3281)

Seeds the client session store with the URL-derived locale, currency, and sales channel at module load time, and installs a one-shot locale corrector to prevent stale IndexedDB-hydrated sessions from overwriting the URL-derived locale.

This fixes visible flickering in the LocalizationSelector on first load and reduces two ValidateSession mutations to a single URL-aligned call. No public API changes.

Original source

FastStore now supports the experimental useIsGiftFromOrderForm flag, giving stores a more reliable way to detect gift items in the cart.

What has changed?

Previously, FastStore determined whether a cart item was a gift by checking if its price was zero (item.price === 0). With this change, you can now configure FastStore to use the isGift field directly from the VTEX Order Form item.

Behavior useIsGiftFromOrderForm: false (default) useIsGiftFromOrderForm: true Gift detection method Checks if item.price === 0 Reads item.isGift from the Order Form

Why did we make this change?

Some stores configure gift items in the VTEX Order Form directly without setting their price to zero. In these cases, the price-based detection would fail to identify the items as gifts, causing them to be displayed and totaled incorrectly in the cart. This flag provides a more accurate alternative for stores that rely on the Order Form's isGift field.

What needs to be done?

This is an opt-in experimental feature. To enable it in your store, follow the instructions in Handling gift items in the cart.

Original source

New batch inventory endpoints (Beta) in the Logistics API

May 22, 2026

The Logistics API now includes a new batch inventory operations endpoints designed for high-throughput inventory updates. These endpoints let you submit large volumes of inventory data through a CSV file and track the processing asynchronously, making them ideal for full inventory refreshes and bulk synchronizations.

This feature is in early access, which means that we are working to improve it. If you want to use this feature, please contact our Support Center.

What has been added?

Four new endpoints are now available in the Logistics API, under the Batch operations section:

• POST Create batch inventory job: Creates a new batch inventory job and returns, in the response, both the batchId and a pre-signed URL for uploading the CSV file,that are required for the following step (CSV upload). The batch remains in AWAITING_UPLOAD status until the CSV is uploaded and committed.
• POST Commit batch inventory: Confirms that the CSV upload is complete and triggers the asynchronous processing of the batch. The batch status transitions to QUEUED.
• GET Get batch inventory status: Retrieves the current processing status and progress information for a batch job, including row counts, error counts, and processing stages.
• GET Get batch inventory errors: Returns a pre-signed URL to download a CSV report with all rows that failed processing, along with error codes and messages.

Why did we make this change?

The existing inventory endpoints remain optimized for low-latency, per-SKU updates, ideal for real-time or incremental inventory changes. However, for scenarios that involve millions of SKUs or require full inventory synchronizations, the new batch endpoints offer a scalable, asynchronous alternative. You do not need to choose between them: both methods can be used together within the same account, depending on the context and business needs.

With this new capability, you can:

• Update large volumes of inventory data in a single operation using CSV files with the batch endpoints, while continuing to use the per-SKU endpoints for more granular or real-time updates.
• Reduce the number of API calls and avoid rate limits when synchronizing inventory at scale.
• Track processing progress and inspect errors through dedicated status and error report endpoints.

What needs to be done?

No changes are required for existing integrations. The previous inventory endpoints remain fully supported and operational.

If you would like to start using the new batch operations endpoints, please see our comprehensive Batch inventory updates guide for step-by-step instructions. You can also refer to the Logistics API reference for detailed endpoint information. Early access is available — contact our Support Center to get started.

Original source

The route for sending payment information via vtexvault.com has been updated. All integrations that have already adopted the route announced in the Mandatory migration to vtexvault.com for "Send Payments" request release note must be updated to use the new route format.

What has changed?

The previous release note introduced the vtexvault.com domain for sending payment information, using the account name as a query parameter:

https://api.vtexvault.com/api/payments/transactions/{transactionId}/payments?an={accountName}

The route has been updated so the account name is now part of the subdomain, as in the example:

https://{accountName}.vtexvault.com/api/payments/transactions/{transactionId}/payments

After September 1, 2026, if you send payment data to any route other than http://{accountName}.vtexvault.com/api/payments/transactions/{transactionId}/payments, the system will block the request, return a 404 - Not Found status code, and interrupt the purchase order flow.

What needs to be done?

Update your payment integration to use the new route format before September 1, 2026:

Method From To POST https://api.vtexvault.com/api/payments/transactions/{transactionId}/payments?an={accountName} https://{accountName}.vtexvault.com/api/payments/transactions/{transactionId}/payments

If you have not yet migrated from the legacy routes (myvtex.com, vtexcommercestable.com.br, vtexpayments.com.br), migrate directly to the route https:/{accountName}.vtexvault.com/api/payments/transactions/{transactionId}/payments before September 1, 2026. For the full list of deprecated routes, see the original release note.

The endpoint behavior remains the same: a successful request returns an empty body with status code 201 - Created. If your implementation relies on payment details in the response, call the Get payment details endpoint after sending the payment.

Original source

Password protection is in closed beta, which means that only selected customers can access it. If you're interested in implementing it in the future, contact our Support team.

FastStore WebOps now includes password protection, allowing you to restrict access to your preview environments and the production domain using basic authentication. This feature enables merchants to protect internal testing environments, staging builds, and production domains from unauthorized access during development or initial launch phases.

What has changed?

Previously, preview deployments and production domains were publicly accessible once deployed. Now, you can enable password protection in the Settings tab to require username and password authentication before accessing these environments.

Why did we make this change?

This feature enhances security by allowing you to:

• Protect preview environments during development and testing phases.
• Control access to production domains before official launch.
• Prevent unauthorized or accidental access to staging and QA environments.
• Ensure internal testing environments remain private.

What needs to be done?

To enable password protection:

1. Access your FastStore WebOps dashboard and navigate to the Settings tab.
2. Find the Password protection section.
3. Enable password protection for preview environments or your production domain by toggling the corresponding switch.
4. Enter a Password that users will need to authenticate with.
5. Save your settings.

When password protection is enabled, users will see a basic authentication dialog when accessing the protected environment's URL. They must enter the configured password to proceed.

For detailed instructions, see the Password protection section in the FastStore WebOps - Dashboard guide.

Remember to share the password with authorized users through a secure channel.

Original source

We added support for displaying custom order data inside the VTEX Admin so you can view store-level custom fields and app-specific information directly from the order details page.

What has changed?

Before, custom data attached to orders in OMS, including store custom fields (customFields) and per-app payloads (customApps), was only accessible through API calls. Now, when custom data exists on an order, both the order details page and print view inside the VTEX Admin display the information in collapsible groups, one for custom fields and one for app payloads. The data is only rendered if the order contains customData.

Why did we make this change?

In order to give merchants and store operators a complete view of order information without leaving the VTEX Admin, we developed custom data visibility in the order details page and print view.

What needs to be done?

To view custom order data in the VTEX Admin, contact VTEX Support and request this feature for your account.

Original source

VTEX marketplaces now forward native paymentData to seller orders, for both VTEX and external sellers. This replaces the previous approach, which relied on custom fields in customApps to propagate payment information, as described in the Orders API: support for NT 2025.001 fields release note.

The new approach uses native VTEX payment fields, ensuring that data such as tid, authId, and nsu is consistently available and reducing custom logic in seller integrations.

What has changed?

Previously, seller orders created from marketplace sales contained placeholder payment information. Now, VTEX sellers receive native paymentData, which includes the actual payment details from the marketplace transaction. The paymentData field is returned by the Get order endpoint.

External sellers integrated through the Fulfillment flow now receive payment information in the Authorize fulfillment endpoint payload.

This feature is also backward compatible. Therefore, integrations that relied on the previous paymentSystemName = "Assumed value by affiliate 00" behavior can now detect marketplace-assumed payments with transactionId = "PAYMENT-FROM-AFFILIATE". This allows gradual migration without breaking existing flows.

What needs to be done?

For early access, contact VTEX Support and request this feature for your account.

Original source

FastStore v4 is now available, introducing important updates to how storefronts are built and managed. This release brings architectural improvements, performance optimizations, and new capabilities such as native localization (beta), along with a new standard for project dependencies, including the Next.js upgrade, enabling a more modern and consistent development environment.

What has changed?

Package updates

FastStore v4 centralizes the management of core dependencies such as Next.js within @faststore/cli. to ensure consistency across projects, reduce dependency conflicts, and improve long-term maintainability.

• Next.js is now internally managed and updated to version 16.
• Node.js runtime updated (Node 24).

GraphQL performance improvements

FastStore v4 improves GraphQL performance through caching, resulting in faster data fetches and a more consistent storefront experience. As part of this update, GraphQL is now an explicit project dependency.

Localization feature (Closed Beta)

FastStore v4 introduces native localization integrated with the CMS. This feature enables scalable global storefronts with localized experiences and centralized content management.

Key capabilities include:

• Multi-locale content management.
• Multi-locale catalog and support for multiple currencies (trade policies/sales channels).
• Default locale fallback behavior.

This feature is currently in closed beta. If you're interested in using this feature in your store, contact the VTEX Support team.

Why did we make this change?

By standardizing dependency management and runtime environments, this release reduces conflicts and simplifies maintenance. The introduction of native localization enables teams to build and manage global storefronts more efficiently.

What needs to be done?

To start using FastStore v4, you must review and update your project. To do that, follow the instructions in Upgrading FastStore to v4.

Original source