Designs

A design is a customer’s filled-in copy of a template: the published template version they used, everything they entered, and, when it is for a product, the blank and placement it goes on. Under Designs, the studio lists them newest first. A design’s page shows its proof beside its details, and below them its print files, each with its orders.

Making a design in the studio

A design usually comes from a customer, through your storefront or a designer link. Someone in your workspace allowed to create designs can also make one from a template, for a sample, a one-off for your own shop, or a test print of a blank: New design in the template’s details. It starts from the template’s published version as published, its fields at their defaults, and Edit before saving opens the designer to change them first.

A design you make there is committed as a customer’s is, and you can approve its proof in the same step, make its print file and place its order. Through the API, a commit with "approve": true is approved as it is made, by whoever committed it; that needs the grant that approves designs.

Standing designs for fixed products

Not every product is filled in by a customer. A standing design is your workspace’s own design for a fixed product, such as the same picture on a mug sold a hundred times: a template version as its author left it, on a blank and placement, at one print size, with nothing of a customer’s or an order’s.

Your server, or a connected store, finds or creates one with POST /v1/designs/standing, naming the template version, the blank and placement, and the size. The same request again answers the same design, so a store can ask on every sale; one template sold on several products is one standing design per product side. A rejected or deleted standing design is not found again, and the next request makes a new one. A connected store finds only the standing designs it made itself, never your server’s or another store’s.

A standing design is never approved on its own: send "approve": true to approve it, which needs the grant that approves designs. It can be ordered on every sale without a reorder, and every order reuses its print file (see Print files). GET /v1/designs?standing=true lists only standing designs, and standing=false only the rest.

Two products on the same template, blank, placement and size share one standing design unless the request names a key, your own name for the product (such as product-123): each key keeps its own design.

To lay one size of one product out by hand, hand out a correction link for its standing design with "adjustLayout": true (POST /v1/designs/{id}/correction-links), ordered or not. The designer opened with it lets your merchant move and scale every layer within the print area, and nothing else. Approving gives a proof token; send it as proofToken to POST /v1/designs/standing, with the same template version, blank, placement, size, variant and key, and you get a standing design made from that layout. Keep its id for that size. The design it was laid out from is not changed, and asking without proofToken finds it again, which is how the size goes back to following the template.

Committed designs change only by correction

A design comes into being when it is committed. It is checked against its template’s rules as it is committed, and a design that breaks one is refused. After that it changes only when your shop corrects it, and only until it has been ordered. The time it was committed is when it was made, and a correction never changes it.

The print size a design is committed at is kept with it, so the printshop cuts the size that was bought. So is the printshop that will make it.

On a blank whose print areas change with its size, such as a sweater whose XL front is wider than its S, a design also keeps the size of the item it was made for, and is printed at that size’s print area. A commit names it, by a variant of the blank or by the size itself, and one naming neither is refused. A customer may preview and proof before choosing, at the blank’s reference size. An order for another size than its design’s is refused, and designs made before the blank had sizes keep its reference size.

Repeat

A design may lay its template as a tile, again and again across the print area, as on a sleeve, an all-over hoodie or wrapping paper. It is the design’s choice, sent as repeat with its values when it is validated, proofed and committed, and kept with it: a correction keeps it, and the job ticket carries it. Any print area can be tiled, and so can a design on no blank.

• mode: grid lines the tiles up, brick moves every other row along by half a tile, halfDrop moves every other column down by half a tile, and scatter strews copies of the tile at random places, turns and sizes, never overlapping.
• size: the tile’s width as a percentage of the print area’s width, above 0 and at most 100. The tile keeps the template’s shape, and is never drawn under 10 mm on a side.
• seed: which arrangement a scatter draws. Another seed is another arrangement of the same tile.

The tile carries the template’s background picture, drawn in every tile. A background colour backs the whole print, the gaps between a scatter’s copies included. The shopper crops the background picture on the tile at the centre of the print, and the crop prints the same in every tile. A scatter has no tile at a fixed place, so the background picture cannot be cropped while the design scatters.

A design that repeats prints at any size up to the placement’s largest; the template’s ratio tolerance is not checked. A tile so large that a picture in it prints below the minimum resolution is a warning, like any low-resolution picture, never a refusal.

A designer link may offer a repeat: the modes its shopper may pick, what the design starts as, and whether they may change it or place the design once instead. A design made through the link is made with the link’s start unless the shopper picked within what it offers; a link offering none places its designs once.

Proofs

A proof is a preview of a design rendered by Pixonaut rather than by the customer’s browser. It is what a customer approves before buying: the designer’s live preview is fast, but the proof is the picture of what will be printed.

When the storefront names the product the design is for — a blank and one of its placements — the proof is fitted to that placement, and the design made from it is recorded against the same blank and placement. A placement that does not exist is refused rather than proofed against the template’s own shape.

The storefront can also name the colour or size the customer previewed the proof on, and the view it was shown in. The proof keeps them, and an order’s page names them under the customer’s approved design. They are for showing only: the order says its own variant, which is the one made. On a blank whose print areas change with its size, the variant also sizes the proof.

On a blank whose print areas change with its size, a design keeps the size it was made for: its commit names a variant of the blank or the size itself, and an order of another size is refused.

A proof is shared through a link that expires. It is the way to show a finished design to someone outside your workspace. A proof link cannot be used to fetch the print file, and a print file link cannot fetch a proof.

If you send proofs before a customer has paid, turn on Watermark proofs under Settings in the studio. Proofs rendered from then on carry a line of text repeated across the whole image, so a proof cannot be used as finished artwork: the name of the brand the proof’s page is drawn in, or text of your own. Beside the switch you set its size, opacity and density, and a preview shows the mark as the next proof will carry it. Proofs already shared stay as they were. Print files are never watermarked.

Approving and rejecting

A committed design waits for your shop’s decision. Approving a design is approving its proof: the picture the customer was shown is what gets made, so the studio says so. A correction renders a proof of the corrected design, which is then the one approved. It shows a design’s status as one of:

• Awaiting proof approval — committed, not yet decided.
• Proof approved — it can be printed, and can no longer be rejected.
• Proof rejected — it is never printed. This cannot be undone.

Your shop usually approves through the API once the customer has paid, with its secret key or a connected store’s integration key. Anyone in your workspace allowed to can also Approve or Reject a design in the studio.

Waiting before approving

An approval can wait. Set Wait before approving (days) in the studio, or send the number of days through the API, and the design is approved automatically when the wait is over. Until then it can still be rejected, which gives a customer a window to change their mind.

How a design was approved

A design records how it was approved:

• Proof approved by your shop or the customer — someone in your workspace, your secret key, a connected store, or the customer on a proof link that may decide approved it. The audit log says which.
• Proof approved automatically when its review time ran out — a wait ended.

How the customer agreed

Your shop can say how its customer agreed when it approves: by adding the design to their cart, by ticking a box, or on a proof page, with when they agreed and your own reference, such as the order line. The design keeps it, and the approval’s audit log entry carries it, so a dispute can be answered from the record. A customer who approves on a proof page link that may decide is recorded as agreeing on that proof page. Correcting the design, asking for changes or rejecting it clears it with the approval.

What approving sets off

Approving decides what gets made, and nothing more: it prints nothing and orders nothing. Your shop prints and orders an approved design when its own flow says to, for example once the order is paid, and anyone in your workspace allowed to can do the same in the studio.

Letting the customer decide

A proof page shows a customer the proof of one design, through a link you hand them; it works for 30 days unless you choose otherwise, and you can withdraw it. A link that may decide lets the customer approve the design, ask for changes, or reject it there. Approving through it, like your own approval, prints and orders nothing. Only someone allowed to approve designs, your secret key, or a connected store can hand out a deciding link, which shows your branding, and the audit log names the link and who handed it out for each decision made through it.

When a customer asks for changes, their words are shown on the design’s page and everyone in your workspace is notified. The design stays awaiting approval, and a waiting approval is cancelled. Correct it, or decide it, and the request is closed. The correction’s proof then shows on the same proof page, and the customer decides it there as they decided the first. A page left open while you corrected the design decides nothing until it shows the new proof.

Asking the customer where it goes

An address capture page asks a customer who a design is for and where it should be delivered, through a link you hand them; it works for 14 days unless you choose otherwise, and you can withdraw it. The customer sees the design’s proof, gives a name and an address, and can change them until the design is ordered. The page takes no payment and places no order.

The design’s first order takes what the customer gave as its recipient and shipping address. An order whose request names its own recipient or address uses those alone, and the customer’s answer is dropped. A reorder never takes it: after the first order, the order is the record of where the item ships.

Nothing waits for the answer: an order placed before the customer has answered goes without it, so hand out the link before you order.

Anyone allowed to place orders, your secret key, or a connected store can hand out an address link. The design’s page shows the address given to anyone allowed to see orders; anyone allowed to edit orders can remove it, for example when the customer asks you to erase it. Rejecting a design removes it.

Correcting a design

A customer’s typo can reach approval before anyone reads it. Until a design has been ordered, someone in your workspace allowed to approve designs can correct it: Edit design in the studio changes its text, and the API takes any value a commit takes.

A correction is held to the same template rules, keeps the size that was bought, and sends the design back to Awaiting proof approval. Nothing is printed or ordered until it is approved again. A print made before the correction shows the old text and is never ordered; print the corrected design again once it is approved. The studio warns before editing an approved design. A correction, and restoring an earlier text, renders a new proof of what the design now says, which the design’s page and its proof page show; earlier proofs are kept while the design can still be restored to them, and released once it is ordered or rejected.

Every version of a corrected design is kept. History on the design’s page lists them, newest first, and says which one has a print file; Customer’s choices lists the texts, pictures and colours the version on show holds, under the template’s labels. The API reads any version, with those choices, with GET /v1/designs/{id}/revisions/{revision}, and a print says which version it shows. Until the design is ordered, an earlier version can be restored: it becomes the newest version, as a correction would, and the design goes back to awaiting proof approval.

Once a design has been ordered it is what was made, and can no longer be edited. Duplicate design makes a new design from it, awaiting proof approval on its own, which you can correct and approve. The new design keeps the order details from your shop and records which design it came from.

Every correction, restore and duplicate is in the audit log; a restore names the version it brought back.

Order details from your shop

When your server commits a design, it can attach order details for the printshop — a material, a shipping method — as its own JSON object. Pixonaut keeps it with the design and hands it on with the order without reading it. Only a secret key or a connected store’s integration key can attach it. The studio shows it under Order details from your shop.

A printshop can require some of these details. A commit lacking one is refused, except for details known only once there is an order, such as where it ships: those are asked for when the order is placed.

Designs that are never bought

A shop that commits a design when it goes into the cart ends up with designs for carts that were abandoned. Your server can give a design its own reference when it commits it, such as the cart line, as externalRef, and move it to the order line once the design is bought; moving it leaves the design’s approval as it was. GET /v1/designs?externalRef= finds the designs holding a reference.

A design that is not approved and has never been printed can be deleted with your secret key, or by a connected store with its integration key. It is gone from every list, its links stop working, and its proof and pictures are released. No rejection is recorded, so the customer is told nothing. A design that has been printed is kept, even if it was corrected back to awaiting approval since.

Erasing what the customer put in

When a customer asks you to erase their personal data, your server, or a connected store with its integration key, can erase what they put into any of their designs, approved and printed ones too: the text of every field they filled in and every picture they uploaded, in every version of the design, with their request for changes and their delivery address. The design stays, as the record of what was made, and nothing more is printed, ordered or corrected from it. Its pictures go at once, and its print files once no order still being made needs them. The fulfilment payload is your shop’s and is not erased. Erasing personal data has the details.

A proof link commits once: committing it again is refused, naming the design the first commit made. To make retries safe, send an Idempotency-Key header with a commit, a print or an order: sending the same request again within a day answers with what the first one made, and makes nothing new.

Related

• Print files — what an approved design becomes.
• Design to order — the requests involved.