A product editor is a configuration and file-generation engine, not only a checkout widget. Teams use it to build branded quotes and visualizations and to feed manual ERP orders, generating the vectorized production file as a discrete, callable step when the deal is real rather than only at online checkout. The visual, the configuration and the production file all come from one source.
Most people meet a product editor as the thing a customer clicks before checkout. That is one use, and it is the obvious one. But a growing share of real usage happens before any purchase exists: a sales rep building a branded visualization to win a deal, a quote that needs a realistic mockup, an order that will be entered by hand in an ERP after a conversation. In some accounts, the majority of editor usage never passes through an online checkout at all.
If you treat the editor purely as a checkout widget, you leave most of its value on the table. This article lays out how to use it for quotes, visualizations and internal workflows, how to retrieve the production files when there is no online sale, and how it fits an ERP-driven back office. It is written for teams integrating FastEditor whose sales process is not a simple web checkout.
On this page
Underneath the customer-facing surface, the editor does three things that have nothing to do with a shopping cart: it configures a product to its real production spec, it processes uploaded artwork into a print-ready state, and it generates a production file and proof from that. A checkout is just one event that can trigger the last step. Once you see the editor as a configuration and file-generation engine, the checkout stops being the only doorway to its output, and a lot of sales and operations workflows open up.
The table shows the common patterns, all built on the same engine.
| Use case | How the editor fits | What you retrieve |
|---|---|---|
| Direct online checkout | Customer designs and buys in one flow | Order plus production file |
| Sales quote | Rep builds a configured, branded mockup to send with a price | Visualization and proof, file on demand |
| Internal visualization | Team creates a realistic preview for a customer conversation | Shareable visual, project data |
| Manual ERP order | Deal is entered in the back office after agreement | Production file pulled into the ERP |
What unites these is that the visual, the configuration and the eventual production file all come from one place. The effort spent making a quote look right is not thrown away when the deal closes; it becomes the order. That is a different economic model from a design tool that produces a pretty picture you then have to rebuild in prepress. The full path from a configured project to a production file is described in the FastEditor integration lifecycle.
The practical question this raises is: if there was no online checkout, how do you get the vectorized artwork and the production file? The answer is that file generation is a discrete, callable step, not a side effect of a purchase. You trigger it when you need the files.
That distinction matters because generating production files is real work, so a system should let you decide when it happens rather than forcing it to coincide with a sale that may be entered elsewhere. For a quote that closes, you request the files at the point you need them for production. For a visualization that is only ever a sales aid, you may never generate them at all. Either way, the project data and the processed artwork are addressable through the API, so nothing you built in the editor is trapped behind a checkout that never happened. How to encode a full configuration compactly for this kind of handoff is covered in virtual SKUs.
The pattern in one line
Configure and visualize in the editor, share the quote or mockup, then generate the production file on demand when the deal is real, whether the order itself is placed online or entered by hand in your back office.
Many B2B teams will never move their order entry into a web checkout, and they should not have to. The editor fits alongside an ERP rather than replacing it. The visual and configuration step happens in the editor, the commercial order is created in the ERP after agreement, and the two are connected through the API: the ERP pulls the project data and production files it needs, so the manual order carries the correct automated artwork.
This is the same integration surface used for web-to-print, just driven by a back office instead of a storefront. The general approach is in how to integrate a web-to-print editor via API, and the architecture question of running the editor headless is in headless personalization. The point is that quoting, visualizing and production file generation are available to any workflow that can call an API, not only to a web checkout. You can map your own sales process against the editor in a Studio demo.
Yes. The editor is a design and file-generation engine, not only a checkout widget. A sales team can build a branded visualization or quote in it, share it with a customer, and generate the production file when it is needed, even if the actual order is entered manually in another system such as an ERP.
File generation is a discrete step that can be triggered when you need the files, rather than only at the moment a customer checks out. That lets you retrieve the vectorized artwork and production file for a project created as a quote or visualization, and feed it into your internal workflow independently of an online purchase.
Because the quote and the production file come from the same source. A visualization built in the editor already contains the correct product configuration, print area and processed artwork, so when the deal closes there is no re-drawing and no second tool. The work done to win the quote is the work that produces the order.
Yes. Many teams use the editor for the visual and configuration step, then create the actual order in their ERP or back office. The editor's API lets you pull the project data and production files into that system, so the manual order and the automated artwork stay connected.
More articles in Developers & API.
