> For the complete documentation index, see [llms.txt](https://docs.atomyx.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.atomyx.io/atomyx-submit/implementation/implementation-patterns/label-upload-portal-pattern.md).

# Label Upload Portal Pattern

It is a strong fit where the brand wants to keep the ordering experience in its own storefront, while using Atomyx Submit as the artwork submission and editing layer.

### Typical architecture

A common setup includes:

* one or more e-commerce websites
* Atomyx Submit used through API-created submission sessions
* Atomyx Prepare for preview generation, editing, and preflight
* callback communication back into the e-commerce platform

In this model, the storefront creates the submission session and redirects the customer into the Atomyx Submit flow.

### Typical end-to-end flow

1. The customer reaches the upload step during ordering
2. The e-commerce platform creates a submission session through the API
3. Product-specific parameters are passed into the session
4. The customer is redirected into the Atomyx Submit portal
5. The customer uploads artwork
6. A preview is generated
7. The customer adjusts the artwork on the canvas if needed
8. The customer completes the submission
9. Atomyx Submit calls the configured callback URL
10. The e-commerce platform receives the result and continues the order flow

### Why this pattern works

This pattern works well because:

* the storefront keeps control of the ordering journey
* one portal setup can support multiple product lines or storefronts
* product rules can be passed per session
* the submission experience remains consistent even across different sites

### Common design decisions

#### API-created sessions

The ordering platform creates sessions server-side and controls what the portal should display and enforce.

#### Portal redirect model

The portal focuses on file submission and editing, while the parent site continues to own the broader buying experience.

#### Server-side PDF manipulation

Customer interactions may look like canvas editing, but the actual PDF changes are applied server-side through Atomyx Prepare.

#### Callback-based completion

The ordering platform receives completion data asynchronously through a callback URL, which helps decouple the systems cleanly.

### Benefits of this pattern

Typical benefits include:

* one reusable submission platform across multiple storefronts
* consistent PDF handling and preview behaviour
* cleaner separation between commerce and file processing
* easier rollout of new product types using parameterised sessions

### Best fit

This pattern is a strong fit for:

* label printers
* packaging businesses
* web-to-print platforms with multiple storefronts
* businesses that want to keep their own front-end experience but avoid building PDF tooling from scratch


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.atomyx.io/atomyx-submit/implementation/implementation-patterns/label-upload-portal-pattern.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.