Apparel is one of the most challenging categories to cartonize well. Items are soft, compressible, foldable, and often shipped in poly bags or tissue that never show up in a WMS item master. This guide walks Ops managers through the PCS rules that solve for those characteristics, and how to store apparel-specific packing data so those rules keep working as your catalog grows.

Each section below pairs a packing challenge with the rule that solves it, a working JSON example, and a link to the full rule documentation for deeper reference.

The single most important decision in apparel cartonization happens before any rule is written: what dimensions do you feed the API? A t-shirt on a hanger might measure 24" x 18" x 1", but folded for shipping it's closer to 10" x 8" x 1.5". Always define dimensions in the folded, as-shipped state — that's the baseline every rule below builds on.

Because folded dimensions, fold behavior, and stack behavior are rarely sitting in a WMS or item master, most apparel operations store them in a Paccurate Item List instead. An Item List lets an Ops manager maintain per-SKU packing data — dimensions, sequence, and custom properties like fold type or stackability — directly in the PCS, without asking engineering to change the integration payload. See Working with Item Lists for the full walkthrough of how matching and merging works.

A request only needs to send an identifier, quantity, and the relevant resources:

The API fills in dimensions, weight, sequence, and properties from the Item List, then applies whichever rules match those values. Everything that follows in this guide assumes that setup — matching rules against a sequence or properties value that lives on the SKU record.

Some garments can be folded more than one way depending on the box they're going into — a hoodie folded flat versus rolled, for example. alternate-dimensions gives the engine a set of options to choose from instead of a single fixed size:

The engine tests each option and keeps whichever produces the best pack. Set replaceOriginal: true when the item's default dimensions represent the unfolded or hung state and should never be used for packing on their own.

alternate-dimensions works well when you already know a garment's exact folded configurations. Most WMS cartonization instead relies on liquid fill: sum an order's total volume and find the smallest box it technically fits into. That math can look perfect on paper while suggesting a single folded shirt gets split across two disconnected pockets of space in a box — a configuration no packer at a table can actually build.

bounded-fill gives specific items that same liquid-fill flexibility while keeping the result physically real. You lock one dimension — typically whichever one matters most for that garment — and let the other two expand or compress to fill whatever contiguous space remains in the box. Nothing gets split across gaps; the item conforms to a single region, in one piece, the way a person would actually pack it.

criticalAxis behaves like freeAxes on lock-orientation: the index you provide is the dimension that stays fixed. 1 above locks the y (width) axis and lets x and z flow to fill the box. Applied to a mixed order, this pattern reduced shipping cost by about a dollar per shipment for one apparel retailer — by finding packs that were efficient and buildable at the pack station, not just efficient on paper.

bounded-fill doesn't replace alternate-dimensions — the two solve different parts of the same problem. alternate-dimensions is precise and explicit: reduce by 10%, use these exact lengths and widths, when you already know a garment's specific fold states. bounded-fill is more general: it lets an item flow into whatever space is left, which suits soft goods where you don't want to enumerate every possible folded configuration by hand. Many apparel catalogs end up using both — alternate-dimensions for a handful of known fold types, bounded-fill for the long tail of soft SKUs that just need to flex into the box. Full background on the rule is in BOUNDED FILL.

Folded dress shirts, stacked denim, and packed hats all compress when placed on top of one another — the tenth shirt in a stack doesn't add as much height as the first. compact-pattern models that compression so volume estimates stay accurate on high-quantity, single-SKU orders like replenishment shipments.

Here, every additional hat placed on top of another instance of itself (targetRefId: null) has its height reduced by 6" rather than adding its full width. compactibleAxes and compactProperties support multiple axes and multiple target items — see Stacking & Nesting for the complete option reference, including how alternating behavior works for items that compact against different neighbors.

The same doc covers internal-space, which creates a subspace inside a larger item — useful when a shoe box, garment bag, or hard-sided case has room for smaller accessories (socks, laces, care cards) to be packed inside it rather than taking up separate cube in the outer carton. It's a smaller use case in apparel than in categories like housewares, but worth knowing about if your catalog includes rigid packaging.

Apparel is almost always poly-bagged or wrapped in tissue, and that material takes up real volume that item dimensions alone won't account for. reservedSpace is a top-level, pack-level parameter — not a rule — that reserves a percentage of every box for dunnage and packaging:

A value of 0.05 holds back 5% of each box's volume, which keeps the engine from overpacking cartons that look full on paper but aren't in practice. Most apparel operations land between 0.03 and 0.07 depending on how much packaging material is used per unit.

Premium or gifted items — a branded shoe box, a jacket in its own retail carton — often can't be commingled with other SKUs. Two rules cover this:

exclude-all keeps an item out of any shared carton entirely:

pack-as-is is for items whose own packaging is the shipping carton — no overboxing at all:

Apparel frequently ships in more than one handling unit for the same SKU — a 3-pack of socks versus a single pair, or a case of the same shirt style going to a store versus an each going direct to a consumer. Rather than creating separate SKUs for every pack size, dimensionSets lets one item definition carry multiple sets of dimensions, weights, and quantity divisors:

With a total order quantity of 30, the API returns one "case" unit and 6 "each" units automatically. This is the same mechanism used for wholesale and store-replenishment orders that mix eaches and cases in a single shipment — full detail, including how the API assigns and reports the chosen dimensionSet, is in Working with Handling Units.

Apparel orders often need one packing step to happen before another — a bra-and-underwear set poly-bagged as a kit before it goes into a shipping carton, or a set of matching separates bundled together ahead of final packout. pack-sequence handles this in a single API request instead of chaining calls.

Items tagged set-bundle in sequence are packed into a KIT-BAG boxType first; that bagged kit is then reduced to a single item (reducedRefId: 1000) and packed into the outer shipping carton alongside anything else in the order. The full walkthrough — including a right-sized kit box built with boxTypeGenerators, and how to extend the pattern from carton to pallet — is in Multi-stage Packing.

Mixed apparel orders — multiple SKUs, sizes, and categories in one shipment — are sensitive to how items are sorted before packing. A few starting points:

On the box side:

Every rule above — compact-pattern, alternate-dimensions, bounded-fill, exclude/exclude-all/pack-as-is, dimensionSets, pack-sequence — can be saved as a Resource in PacManage™'s Resource Library and referenced by name instead of rebuilt in every request. Paired with an Item List holding your apparel SKUs' folded dimensions and custom properties (fold type, stack behavior, kit grouping), a client system only needs to send an identifier and quantity:

That separation matters operationally: Ops managers can update fold behavior, add a new kit grouping, or adjust reservedSpace for a new poly bag vendor entirely inside PacManage™'s Inspector — testing the change against real orders before deploying — with no engineering involvement or WMS change required.

Apparel rewards the operations teams who model it precisely. Folded dimensions, compaction behavior, dunnage, and kit logic each pull cartonization in a different direction — but stored once in an Item List and a handful of PacManage™ resources, they stop being one-off configuration and start being reusable packing logic that scales with the catalog. Start with folded dimensions and reservedSpace, layer in compact-pattern and dimensionSets as multi-packs come online, and add pack-sequence once kitting or bundled sets enter the mix.