Supplier integration guideLevel 4
Start here
Before you build
Specifications
After you submit
Level 4 · Optional · Partial
Level 4 — Web2Print and production artwork.
Customer artwork arrives at your production team validated and production-ready, instead of arriving as an email attachment somebody has to prepare.
Level 4 unlocks TronDesigner. Products already carried on the network are available to it immediately, including their updates, so a supplier who is live at Level 1 has most of the input in place already.
This document describes the confirmed integration model. Field-level naming is still being finalised and every provisional clause below is flagged — treat a flagged name as a working name, never as a feed contract.
- Document
- SPEC-L4-004
- Revised
- 8 September 2026
- Depends on
- Level 1 + print data
What has to be true first
Requires Level 1- Level 1 is activeProducts already on the network are available for Web2Print immediately, including their automatic updates.
- Your identifiers are stablePrint definitions stay linked across updates only if the codes they hang on do not move — REF-FMT-010 §4.0.
- Print and decoration data exists, or dielines doLevel 2 positions and techniques improve the result, but print areas can also come from dielines or be configured by hand — see §5.0.
Draft — whether Level 2 is a hard prerequisite
Whether Level 2 is required or merely a strong improvement is being finalised per catalogue. Treat it as strongly recommended until this clause is marked active, and confirm your own catalogue's position with the integration team before you plan around it.
Three ways it can run
The first needs no development on your side at all. The other two are where the technical work is, so this is the clause to settle before any of the rest matters.
| Model | Runs in | Work on your side | What it is for |
|---|---|---|---|
| A · Standalone | Our web application | None | The fastest path. No technical integration and no development on your side. |
| B · Embedded | Your webshop | Front-end integration | The editor as an overlay, so external customers design and proof while they are shopping with you. |
| C · ERP-driven | Your ERP or CRM | Yours | Your own sales, design or production team prepares proofs and print data from the system they already work in. |
The product data Web2Print consumes
These are the categories of data the editor reads. The names reflect the current documentation and are confirmed per supplier before an integration is built.
| Field | Type | Required at | What it is |
|---|---|---|---|
| model_id | string | L4 | The stable model identifier. Must match the Level 1 product feed. |
| variant_id | string | L4 | The stable per-variant identifier, for colour and size. Must match Level 1. |
| product_name | string | L4 | The human-readable name shown in the design interface. |
| image_refs | array | L4 | One reference per view. The constraints are in §4.0. |
| variant_attributes | object | Conditional | Colour, size or another distinguishing attribute, where the line is variant-driven. |
| dimensions | object | Conditional | Physical product dimensions. Required for scale-accurate previews on dimensional products. |
| orientation | enum | Conditional | Front, back or side. Required for multi-view items. |
| decoration_methods | array | Conditional | The available techniques, taken from Level 2 where that exists. |
| decoration_locations | array | Conditional | Named print positions. The coordinate detail is in §5.0. |
| max_decoration_size | object | Conditional | The maximum printable dimensions per location. |
| material | string | — | Affects colour rendering and which techniques are compatible. |
| production_restrictions | string | — | Notes on production constraints — a curved surface, a colour limit. |
Draft — these names are provisional
The categories are confirmed; the field names are not. Do not build an exporter against the names in this table before your catalogue's contract is confirmed by the integration team.
Image requirements
| Concern | Requirement | Notes |
|---|---|---|
| Format | JPG or PNG | A transparent background is preferred wherever the product is composited into a scene. |
| Resolution | 1000 px or more | The Level 3 reference applies as a baseline — 600 minimum, 1000 optimal, 1400 and above best, on the shorter side. Level 4 benefits from the same or higher. |
| Background | Clean | No existing logos, watermarks or overlays. Logos are added by the tool. |
| Orientation | Consistent | The same angle and framing per view type, across the catalogue. |
| Views | One per orientation | Required wherever decoration locations differ by view. |
| Colour accuracy | True to the product | Colour editing is applied to the customer's artwork, never to your base product image. |
| File naming | A documented convention | Tied to variant_id and orientation. |
Draft — the thresholds and the naming convention
The exact numeric resolution thresholds for Level 4 specifically, and the file-naming convention, are confirmed per catalogue before setup.
Where a print area comes from
Five sources, in descending order of automation. The first costs you nothing because the data already exists.
| Source | Effort | When it applies |
|---|---|---|
| Your own coordinates | None | You already hold print position data from Levels 2 and 3, and it is reused directly. |
| Dielines | Low | You can supply vector dielines or PDF templates. |
| Manual definition | Yours | Your team defines the zones themselves, in the TronDesigner back end. |
| Assisted configuration | Ours | Our team configures the areas from your images and specifications. |
| AI-assisted detection | In development | Planned for catalogues with missing or partial print data. Expected 2027. |
Draft — the units a finished area is expressed in
Whatever the source, a finished print area specifies a position identifier, a technique, width and height with a unit, rotation where it is not axis-aligned, a shape or clipping mask for a non-rectangular area, a safe zone and bleed, and which view it applies to. Whether width and height are in millimetres or pixels is confirmed per catalogue.
What happens to a customer's artwork
The sequence end to end is search, select, design, vectorisation, colour editing, cropping, proofreading, and print-ready data.
| Stage | Behaviour |
|---|---|
| Asset intake | Customer logos in almost any format are prepared for production, including vectorisation where it is needed. |
| Colour handling | Colour editing into your production colour system, confirmed per supplier. |
| Output format | Print-ready data for your production pipeline. The final delivery format — PDF, native or other — is confirmed per supplier. |
| Metadata | Order, product, print-area and technique references travel with the output, so it can be routed automatically. |
| Delivery | Depends on the deployment model in §2.0: a standalone download, delivery inside your webshop, or retrieval by your ERP. |
Validation states
| State | What it means |
|---|---|
| Accepted | Passes every check and proceeds to production output. |
| Accepted with warning | Passes with a non-blocking flag — a low-resolution logo that had to be upscaled, for instance. |
| Rejected | Fails a hard rule, such as a print area being exceeded. It has to be corrected before it is resubmitted. |
| Manual review | An ambiguous case, routed to a person before it reaches production. |
Every validation error identifies the affected product, the affected print position, the invalid or missing field, and the corrective action.
What the integration is accepted against
All eight have to hold. The last one is yours rather than ours, and it is the one that matters most.
- Test products load correctly in TronDesigner
- Variants map correctly to your Level 1 catalogue
- Images display correctly in every relevant orientation
- Print areas are positioned correctly on each view
- Every supported technique is available and selectable
- Sample artwork passes the agreed validation rules
- The output files open and are usable by your production team
- Your team has approved representative test outputs
Confirm the provisional clauses before you build
The integration model on this page is settled. The field names in §3.0, the thresholds in §4.0 and the units in §5.0 are not, and they are confirmed against your own catalogue rather than in general.
