Boxzooka, the Secaucus, New Jersey fulfillment operator with facilities on both coasts, connected to AIMS360 across the full warehouse document set. When Boxzooka reuses one bill of lading across several pick tickets, AIMS360 groups them into a single consolidated shipment rather than pretending they left separately.
Five pick tickets go out on one trailer under one bill of lading. Most systems record five shipments, because that is what the pick tickets say. AIMS360 records what actually left: a single consolidated shipment. That difference is worth reading about, because it decides whether your freight cost per order means anything and whether the advance ship notice matches the truck.
Boxzooka reuses a single bill of lading across multiple pick tickets when they move on the same trailer. AIMS360 reads that and groups those pick tickets into one consolidated shipment, so the shipment record in the ERP matches the physical movement rather than the paperwork that preceded it.
It sounds like an accounting nicety. It is not. Three things break when an ERP records five shipments for one truck.
One freight charge has to be spread across five recorded shipments, so either it lands on one of them and distorts that order's margin, or somebody allocates it by hand every week. Neither produces a cost per order you would make a decision on.
An advance ship notice is meant to describe what is arriving on a conveyance. Five notices for one truck is not what the receiving dock is expecting, and receiving discrepancies are how chargebacks start.
The carrier invoices one movement. Your system shows five. Somebody in accounts payable now owns a matching exercise that should not exist.
Consolidating the shipment does not merge the orders. Each pick ticket keeps its own customer, its own lines and its own invoice. The grouping happens at the shipment layer, which is where it belongs.
Worth being straight about one thing: this depends on Boxzooka reusing the bill of lading in the first place. It is warehouse behavior that AIMS360 reads and handles correctly, not a switch you turn on in the ERP. If you move to a warehouse that issues a separate BOL per pick ticket, there is nothing to consolidate.
The full warehouse document set runs live, in both directions.
| Document | Direction | What it carries |
|---|---|---|
| 832 | AIMS360 to warehouse | The product catalog, delivered by API on this connection. Style, color, size, UPC and description reach the warehouse before the goods do |
| 940 | AIMS360 to warehouse | The ship order, serving as order or pick ticket depending on a system setting, carrying the pick number and the customer purchase order |
| 943 | AIMS360 to warehouse | Inbound advice. What is arriving from production or another location and what to expect on the container |
| 944 | Warehouse to AIMS360 | The receipt, posting against the open purchase order or return line |
| 945 | Warehouse to AIMS360 | Shipment confirmation with carton detail, weights and tracking, and the bill of lading that drives consolidation |
| 947 | Warehouse to AIMS360 | Inventory adjustment. Damages, cycle count corrections and found stock |
| 846 | Warehouse to AIMS360 | The inventory snapshot, so the two positions can be reconciled rather than trusted |
This integration is not purely file based and not purely API. The catalog goes across by API, while other documents move as files. That combination is normal in warehouse integration and it is usually the right answer, because the two transports are good at different things.
An API suits the catalog, where you want a new style to land immediately and you want a rejection to come back with a reason attached. Files suit high volume transactional traffic, where batching is efficient and a failed file can be corrected and reprocessed rather than lost. A connection that insists on one transport for everything is usually doing so because of a platform limit rather than a design decision.
What matters to you is not the transport. It is whether a failure is visible and recoverable. On this connection a failed file stays in place for correction rather than being dropped, and a rejected API call returns a reason.
Last reviewed 15 August 2026 by the AIMS360 integrations team.
Integration status reviewed against the AIMS360 production configuration for this partner. Company facts checked against boxzooka.com in August 2026 and attributed to the publisher rather than stated as our own.
Attributed to their own site rather than repeated as fact.
| What they publish | Detail |
|---|---|
| Company | Boxzooka eFulfillment LLC, trading as Boxzooka Fulfillment and Global Ecommerce, founded 2014 |
| Head office | Secaucus, New Jersey |
| Facilities | Four US facilities: Secaucus New Jersey, two buildings in Middletown Pennsylvania, and Henderson Nevada. Other city pages on their site are market pages rather than warehouses |
| Coverage | An east and west coast network, which is what shortens transit on a national consumer base without splitting your inventory across two vendors |
| Apparel handling | Garment on hanger storage available, polybagging and packaging, routing guide adherence, department store and boutique workflows. Tagging and steaming are not published |
| Channels | Ecommerce and direct to consumer, retail and wholesale distribution with EDI, subscription boxes, Amazon FBA and FBM prep, and Seller Fulfilled Prime |
| Value added | Kitting and assembly for both DTC and B2B, custom packing, monogramming, embroidery, engraving and inserts |
| Returns | Identify, relabel and repackage |
| International | Customs and import tariff handling, duty drawback and tax recovery |
| Warehouse system | A proprietary system. They do not name a third party WMS vendor |
| Performance | Their Pennsylvania facility page publishes 100 percent on time receiving, 99.8 percent on time shipping and 99.9 percent inventory accuracy. Facility specific, their figures, not independently verified |
| Not published | Square footage per facility, staff count, client count, named carriers, and certifications |
Ownership changed very recently. On 28 July 2026 a private equity firm announced a recapitalization taking majority control of Boxzooka, with the founder moving to chairman and the existing president becoming chief executive. That is public information and it is not a criticism: recapitalizations often bring investment. It does mean that if you are signing a multi year fulfillment agreement in the next few months, ask about facility plans, pricing structure and account team continuity, and get the answers in the contract rather than in a meeting.
Square footage is not published first hand. Directory listings carry figures per facility. Boxzooka's own site does not, and we are not going to repeat directory numbers as though they were verified. If capacity matters to your decision, and for a growing brand it should, ask for it in writing.
Yes, and the full warehouse document set is live in both directions: catalog, ship orders and inbound advice going out, receipts, shipment confirmations, inventory adjustments and inventory snapshots coming back. The connection is mixed transport, with the catalog moving by API and other documents as files.
It is one shipment record covering several pick tickets that physically left on the same trailer under one bill of lading. It matters because freight is charged per movement, not per pick ticket. If your ERP records five shipments for one truck, the freight cost has to be allocated by hand, the advance ship notice does not describe what is arriving at the dock, and the carrier invoice will not match your records. AIMS360 reads the reused bill of lading from Boxzooka and groups the pick tickets into one shipment, while each order keeps its own customer, lines and invoice.
Yes. Boxzooka publishes facilities in New Jersey, Pennsylvania and Nevada, and in AIMS360 each one is a warehouse on the same stock record. Inventory templates decide what each location can sell and routing decides where an order ships from, so a west coast consumer order does not cross the country because that is where the default warehouse happens to be.
Usually both, and a vendor insisting on one for everything is often describing a platform limit rather than a design choice. APIs suit low volume, high urgency traffic such as a product catalog, where you want immediate delivery and a rejection reason. Files suit high volume transactional traffic, where batching is efficient and a failed file can be corrected and reprocessed. The question worth asking is not which transport, it is whether a failure is visible and recoverable.
They publish retail and wholesale distribution with EDI alongside their ecommerce work, including routing guide adherence and department store workflows. On the AIMS360 side the retailer documents stay with AIMS360: the 850 comes in and the 855, 856 and 810 go back on the retailer's spec. The carton detail on the 945 from the warehouse is what the 856 is built from, and on a consolidated movement that notice describes the truck rather than the paperwork.
They publish garment on hanger storage as available, and polybagging and packaging as standard. They do not publish tagging, ticketing or steaming, so if your product needs pressing or retailer ticketing at the warehouse, ask directly rather than assuming, or look at a warehouse that publishes those explicitly. Our Jet Distribution page covers a warehouse that does.
Bring several orders going to one destination. We will send the ship orders, take the confirmation back on one bill of lading, and show you the single shipment it produces.
