What's New in Infigo | July 2026

Infigo storefronts now support multi-factor authentication (MFA), giving administrators the ability to enforce a second verification step at login for any customer role. Three verification methods are supported: email one-time links, time-based authenticator app codes (TOTP), and FIDO2/WebAuthn hardware or platform security keys. MFA can be set as required for some roles and optional for others, with administrators able to configure each method independently.

A trusted device feature lets users skip repeat MFA challenges for a configurable number of days after verifying a device (0 days by default, until an administrator sets a trust period), reducing friction without compromising security. MFA itself ships disabled by default on all storefronts, new and existing, so administrators can review and configure required and optional roles before switching it on.

Related Academy content

• Login & Registration – how MFA fits into your storefront's login and registration flow.

Storefront Management access used to be all or nothing: anyone who could reach it saw every storefront on the platform and could add any type of binding. Three new permissions now allow a much narrower grant.

The three permissions are "Storefront Management - Current storefront only", "Storefront Management - Allow to create Domain", and "Storefront Management - Allow to create Alias".

"Current storefront only" gives a role access to Storefront Management for its own storefront and nothing else. It takes the place of the full Storefront Management permission rather than sitting on top of it. A role that still holds the “full” permission keeps access to every storefront.

The two "Allow to create" permissions govern whether a role can add Domain-type or Alias-type bindings, and can be applied independently. One point is worth knowing before you decide what to ask for: a role holding neither is treated as unrestricted and can add both types, so a restriction is expressed by allowing the type you want rather than by removing both.

Admins managing large product catalogues with many attribute values previously had to create attribute combinations one at a time or use the Import/Export workflow to add them in bulk. There was also no guard against creating duplicate combinations manually, which could cause data inconsistencies.

A Generate button has been added to the Attribute Combinations section on Product Variant and Product Group pages. Clicking it opens a popup listing all eligible attributes (text-type attributes excluded). Select the attributes to include, confirm, and the platform creates every missing combination in one operation. Existing combinations are skipped; generation is additive only.

Duplicate prevention now applies at manual creation time as well: attempting to create a combination with the same attributes and values as an existing one is blocked with a user-facing error. A new Max Generated Attribute Combinations setting in Limitation Settings lets administrators cap how many combinations can be generated in a single operation, from 1 up to 1,000 (default 1,000). Newly generated combinations are created with a default stock quantity of 10,000 and backorders disabled, so admins can still adjust stock, SKU, or pricing on individual combinations afterward.

PrintIQ and Infigo now support two-way synchronisation of company and contact records: PrintIQ companies map to Infigo departments, and PrintIQ contacts map to Infigo customers, in either direction. Each of the 4 sync directions:

• PrintIQ Companies → Infigo Departments
• PrintIQ Contacts → Infigo Customers
• Infigo Customers → PrintIQ Contacts
• Infigo Departments → PrintIQ Companies

is controlled independently, and all are off by default.

When a matching record already exists, the sync updates it rather than creating a duplicate. Records are processed individually and in pages, so one problematic record never blocks the rest of a sync run. When PrintIQ activates a customer, Infigo marks the matching customer active and sends the "Customer Set As Active" email automatically.

A built-in test mode with configurable per-run limits lets you validate the setup safely before fully enabling it.

Google is permanently retiring the Content API for Shopping. This is the API Connect: Google Merchant has always used to sync product listings to Google Shopping. This will be retired on 18 August 2026. To keep product sync working beyond that date, the Infigo plugin for Google Merchant now supports a parallel sync path using Google's replacement Merchant API.

The new path is switched on per storefront and is off by default, so the legacy sync keeps working exactly as it does today until you choose to migrate. Migrating involves a short one-off setup in Google Merchant Center alongside a few new plugin settings; once complete, products continue to sync with the same titles, prices, images and attribute combinations you see today.

A detailed step-by-step migration article is available, since this involves both storefront configuration and steps inside Google Merchant Center itself.

• New "Use new Google Merchant API" toggle, off by default
• One-time developer registration linking your Google Cloud project to your Merchant account
• Optional diagnostic tool to confirm which products Google currently holds for your storefront

Two gaps in how the storefront handles inaccessible content have been closed. Previously, a visitor without permission to view a category saw a blank page, and an unpublished product or category silently redirected to the homepage. Both dead ends with no explanation.

Now, permission-restricted content shows an Access Denied page, and unpublished products, categories or blog posts show a "This content is not available" message, each with a clear return-to-homepage link. Both pages ship with sensible default wording and can be fully customised through the Editable Content admin area.

• Access Denied page for content restricted by access permissions
• "This content is not available" page for unpublished items
• Both editable from Admin > Editable Content
• Non-existent pages now correctly return a 404 response

Infigo lets authorised staff send a template-driven email to an individual customer without leaving the platform. A shared Send Email popup is available from the customer edit pages in the admin area, and from the Manage Users page on the storefront. The sender picks one of your message templates, the subject is pre-filled from that template and stays editable, and all the usual store, customer and account placeholders are resolved automatically before the email is queued.

Two new control permissions decide who can do this: one for the admin area and one for the storefront, so the two entry points can be granted independently.

A new Customer Context checkbox on each message template controls which templates appear in the popup. It is off by default on every existing template, so nothing changes until you deliberately opt a template in.

• Two new permissions: Admin area. Send email to customers, and Manage Customers. Send email.
• One shared Send Email popup used by both the admin pages and the storefront Manage Users page.
• Optional free-text note delivered through the %CustomMessage% token, which resolves to nothing if left blank.

A new control permission separates the ability to impersonate a customer from the ability to edit their record. Staff with applicable permissions can search, filter, and list customers, and use the Impersonate action to log in as a customer and place an order on their behalf, but they cannot view or use any of the customer edit controls.

The Edit button and the customer edit form are hidden for staff who hold only this permission, and direct navigation to a customer's edit page is blocked. Existing role weighting still applies, so a member of staff can only impersonate customers whose role sits below their own - the same rule that already prevents impersonating a higher weighted admin.

Staff who already hold full customer management rights are unaffected: they keep both the Impersonate and Edit actions exactly as before.

• New permission, not granted to any role by default.
• Grants search, filter, and impersonate; denies all customer-editing actions.
• Edit button hidden and edit URL blocked for impersonate-only staff.
• Existing role-weight rules still govern who can be impersonated.

Ship-by-weight rate tiers previously matched only by country and weight band, and had to be entered one row at a time. Rate configuration now supports much finer control, and can be managed in bulk.

Each rate tier can now optionally be filtered by state or province and by a postcode pattern, with an execution order to break ties when more than one tier matches equally well. The entire rate table can be exported to a spreadsheet, edited offline, and re-imported — including large tables, with validation that stops the whole import if any row has a problem. Two new checkout messages can also be configured to tell customers when their order's weight falls outside your configured rate ranges.

• Optional state/province and postcode-pattern matching per rate tier
• CSV export/import with row-level validation and batch delete
• Configurable maximum and minimum weight messages at checkout
• Existing country-only rate tiers continue to work unchanged

The Connect Flow plugin's data format control has been simplified. Previously, outgoing order data format was determined by a combination of a checkbox and a separate XSLT setting, with inconsistent logic between API and Hotfolder/FTP delivery. This is now a single, deterministic "Data format type" dropdown with three options: JSON, XML, or XSLT.

The incoming webhook endpoint now accepts both JSON and XML status update payloads, not just XML. The plugin's admin instructions section also gained download buttons for previewing example order data and testing your configuration against a specific order. All existing configurations are migrated automatically to the new dropdown value on deployment, so no manual changes are required.

When an operator uploads replacement output files for a job (correcting artwork after production) customers can no longer trigger a reorder for that job. This closes a gap where a reorder could recreate an order using the original, now-superseded files rather than the corrected version.

The reorder option is automatically hidden on both the account order list and the order details page for affected jobs, and any attempt to reorder via the API returns a clear error explaining that the output has been replaced. This applies automatically and needs no configuration.

Existing orders are unaffected, and jobs without replaced output behave exactly as before.

Finnish (fi-FI, Suomi) has been added to the platform's available languages, with a complete set of translations covering the storefront interface.

The language is registered as unpublished, so it appears in the admin panel's Languages management section but stays invisible to storefront customers until an administrator enables and publishes it.

See the article below for the steps to enable it, and for the full list of languages you can activate the same way.

Gathering the paperwork for a production run used to mean visiting orders one at a time. The Shared Print Operations page now has a Downloads menu that works across everything you have selected, so you can collect the documents for a whole batch of orders in a single file. Alongside the combined Job Ticket downloads that were already available, you can now produce combined Packaging Slips and combined Invoices, each as either a merged PDF or a ZIP of individual files.

Because these files can get large, every combined download is now prepared as a background task. You can carry on working while it builds, and you are notified when the finished file is ready to collect. The same background processing has been applied to the download actions on the Order Details page. Packaging Slips and Invoices exist once per order, so they are de-duplicated automatically, and cancelled jobs are excluded from combined Job Ticket downloads.

A new global limit, Maximum combined documents, controls how many documents a single combined download may contain. It ships with a default of 50. If you select more orders than the limit allows, you are told how many to remove before anything is generated.

Admin users can now jump directly from an order to its related print jobs in Shared Print Operations with a single click. The new View Related Jobs button on the Order Details page opens Shared Print Operations in a new browser tab, with the order pre-applied, every filter set to show all results, and the correct product type tab pre-selected based on the order's contents. No configuration is required.

Related Academy content:

• Shared Print Operations — monitoring and managing production jobs, filtering by product type and status, and finding print-ready output.
• Managing placed orders as part of the print team

The Relevant Orders page in My Account has been redesigned with a modern, interactive data table with search, sort, and pagination. The table shows orders assigned to your department that are still pending or in processing, so department members can focus on orders that need action rather than a full order history. Department members can edit order notes and mark orders as shipped, with a confirmation step to help prevent accidental changes. Two admin settings have also been renamed for clarity.

The platform's "Quantity Below – Store Owner" email notification was previously triggered only when stock was controlled at the product variant level. Products using attribute combination stock control were not covered, requiring manual monitoring.

A new "Notify admin for quantity below" threshold field is now available on each attribute combination. This is a separate setting from the existing product variant threshold and is not inherited automatically, so it must be set explicitly on each combination you want to monitor.

When a customer order reduces a combination's stock below its configured threshold, a dedicated notification email is sent to the store owner. The email uses a new template with tokens specific to attribute combinations, including the affected attribute values, current stock quantity, and direct admin links to both the combination and its parent product variant.

Existing combinations default to a threshold of 1; set a combination's threshold to 0 if you don't want it to trigger notifications.

MegaEdit's text tool previously offered only left, centre and right alignment. A new Justify option has been added, giving customers a fourth way to lay out text directly in the editor. Stretching each line to fill the full width of the text frame, evenly spaced between both margins.

Justify works consistently across the on-screen canvas, the generated PDF, and MEX import/export. Two optional controls, Justify Min Spacing and Justify Max Spacing, let you limit how far word spacing is allowed to expand. Justify and Fit to Box cannot be used together, which the editor enforces automatically.

• New Justify text alignment option in MegaEdit
• Optional word-spacing limits in Advanced Options
• Last line of each paragraph stays left-aligned by design

[[SCREENSHOT: justify_text_alignment.png]]

Orders placed through the Infigo API or via a Megascript automation can now specify exactly which payment method should be used. Previously, this field was always left blank, so integrations had no way to route an order through a particular payment provider.

When a payment method system name is included in the order placement request, it is forwarded through the order processing pipeline and recorded on the order. If the field is omitted, the order is placed with the same default behaviour as before. The change is fully backward-compatible and requires no changes to existing integrations.

This is useful for integrations and automations that need accurate payment routing and reporting, such as Megascript-driven order placement or custom API clients.

Previously, a customer's carrier preference selected at checkout only reached the Flexlink production system, through dedicated order fields. Storefronts using CERM, NetSuite, Radius, or LabelTraxx had no equivalent dedicated fields, so the carrier choice never reached those systems.

The carrier preference is now formatted as a standard text entry and appended to the free-text comment or notes field each of these systems already accepts. Existing comment text is preserved, and orders without a carrier selection are completely unaffected. No configuration is required.

Storefronts using the Avalara AvaTax integration can now enable a more accurate way of calculating the tax rate applied to product lines. The previous approach read an already-rounded value returned by Avalara and used it directly as the rate; the new, optional calculation instead derives the rate from the taxable amount and rate for each tax jurisdiction, preserving full decimal precision.

This is most useful for orders that span multiple tax jurisdictions, where the extra precision reduces the chance of a rate drifting slightly from what Avalara reports. The setting lives in the AvaTax plugin's admin configuration and is off by default, so no existing storefront sees any change in behaviour until it is explicitly turned on.

A detailed configuration article is available with the exact steps to enable this option.

• New optional setting: "Use more accurate tax calculation" in the AvaTax plugin settings
• Off by default, per storefront
• Can be reverted at any time without a redeployment

Connect: PrintIQ previously had no way to pass payment details through to PrintIQ when a quote was accepted, which made it difficult to reconcile orders against payment gateway transactions from within PrintIQ. A new, optional capability closes that gap.

A new universal placeholder resolves, per payment provider, to the most appropriate transaction reference that provider stores against the order, so the value sent for reconciliation is always the right one, whichever payment plugin was used.

The capability is disabled by default, so no existing storefront is affected until it is explicitly enabled.

Infigo now delivers your storefront's front-end resources more efficiently through two complementary improvements to how scripts and stylesheets reach the browser. Both are applied automatically and require no admin configuration.

• Optimised script delivery — instead of loading many individual JavaScript files on each page request, related scripts are grouped into named bundles, compressed during the build process, and served as a single optimised file in production. This reduces the number of network connections a page needs.
• Stylesheets delivered first — the shared page head now places all stylesheet references before any script tags, so the browser discovers and downloads your page styles as early as possible and can render a fully styled page without waiting on scripts.

Together these changes improve how quickly pages become visible and usable, particularly on mobile devices and slower connections. Your storefront's appearance and behaviour are unchanged, and styles still apply correctly for visitors who have JavaScript disabled.

The Infigo plugin system has been modernised to use a more efficient loading process. Plugins across the admin area now load faster, and every plugin consistently displays its logo, including plugins that previously had none at all.

This update covers the full range of plugin types, including address providers, shipping, tax, discount rules, and Connect/MIS integrations. No configuration is required, and your existing plugin settings are unaffected.

Descriptive attributes have now been added across all API response and request models within the API documentation, covering the product, order, customer, catalog, quote, and editor domains.

The result is a self-describing API reference where every endpoint, field, and enumeration carries an accurate, plain-language description. The reference is generated automatically in OpenAPI 3.0 format directly from the codebase, so it stays accurate as the API evolves. Developers integrating with the storefront API can now work directly from the reference without needing to request additional documentation or contact support for field-level clarification.

The reference is available from every storefront via the built-in API Explorer (/services/api), which links through to the full, always-current API documentation for your platform instance.

No configuration is required. The improved documentation is available automatically in the platform API reference.