Sell wholesale on JOOR, run the business in AIMS360. Styles, linesheets, customers and true open-to-sell go out over JOOR's own API, and wholesale orders import back automatically. Negative inventory and dated work in process included, so what a buyer sees is what you can actually ship.
AIMS360 talks to JOOR through JOOR's own API. Styles, linesheets, customers and true open to sell go out, wholesale orders come back and import automatically, and availability carries the detail that matters in wholesale: negative immediate stock and work in process with its delivery date.
Talk to us about JOOR Book a demoYes, and it is a native, first-party integration. AIMS360 wrote it against the JOOR API and maintains it inside the product, so there is no connector to license and nothing sitting in the middle. AIMS360 appears on JOOR's technology partners page alongside the systems they integrate with directly.
Styles and linesheets, customers, and open to sell inventory are sent from AIMS360 to JOOR. Wholesale orders written by reps and buyers come back into AIMS360 as live orders, automatically where auto import is switched on, validated on the way in so nothing lands missing terms, a ship via or a sales rep.
The part brands notice most is the inventory detail. AIMS360 sends negative immediate quantities where you are oversold and work in process with its expected delivery date, so a buyer picking a later ship date in JOOR sees what you can genuinely commit rather than a hopeful number.
JOOR supports two routes, and they are not equivalent. JOOR's own integrations page sets both out: an API integration, where your system posts customer, style and inventory data and pulls orders back, and a flat file route using Excel, TXT or CSV files with orders dropped to an FTP or SFTP folder, which JOOR positions for smaller businesses without an ERP.
Both get described as "integrated with JOOR" on a vendor's website. Here is what the difference actually looks like day to day.
| What AIMS360 usesJOOR API integration | The other routeFlat file, spreadsheet or FTP | |
|---|---|---|
| How data moves | Direct API calls between AIMS360 and JOOR. | Excel, TXT or CSV files uploaded or dropped in a folder. |
| Who built it | AIMS360, natively. Nothing to license, nobody in the middle. | Often a middleware vendor or outside integrator, billed separately. |
| Inventory detail | Open to sell by size and warehouse, including negatives and dated work in process. | One quantity column, accurate as of whenever the file was built. |
| Styles and linesheets | Created and updated from AIMS360, with linesheet, season and delivery dates. | Re-uploaded as a spreadsheet every time the line changes. |
| Orders | Import into AIMS360 as live orders, validated, with bulk fixes for missing fields. | Land in a folder and get re-keyed or bulk imported by hand. |
| Failure mode | Per-order validation messages, an export status in JOOR, and logs in AIMS360. | A malformed file fails quietly until someone notices. |
To be fair about it: the flat file route is a perfectly reasonable answer for a brand with no ERP and a short line. It stops being reasonable the moment inventory accuracy starts costing you money.
A good share of the people searching for a JOOR integration are not really searching for JOOR. They are searching for a way to attach JOOR to whatever they already run: a JOOR and NetSuite connector, a JOOR and Dynamics 365 integration, a JOOR connector for a system that was never built around style, color and size.
That search usually ends at middleware, and middleware works. It is also a third product with its own licence, its own release cycle and its own support queue, sitting between the ERP you run today and your line sheet.
AIMS360 is an apparel ERP with the JOOR connection built in, written against the JOOR API and maintained as part of the product. One vendor for styles, inventory, orders and the connection between them, and one number to call when a season is going live and something is not showing up.
Where the JOOR connection is not part of the ERP you run today, a connector platform goes in between, with its own pricing and its own roadmap. Every JOOR or ERP release becomes a compatibility question for a vendor who answers to neither, and every sync problem starts with working out whose problem it is: your ERP vendor, the connector vendor, or JOOR.
Three flows out, one back, all over the same API connection.
By style or by style-color, with sizes, wholesale and retail prices, fabric content, country of origin, minimum order quantity and your JOOR description. Linesheets are created in AIMS360 with season, year and delivery dates.
Wholesale accounts exported with currency, bill to and ship to, matched to JOOR connections by customer code so their orders route back to the right account without anyone rekeying it.
OTS by size and by mapped warehouse, negatives included, plus work in process carrying its delivery date. You choose which warehouses go over and whether future goods are included, so you control exactly what the market sees.
Orders written on the JOOR site or iPad app download and import as live AIMS360 orders, with discounts, order and event types, terms, ship via and sales rep carried through.
This is where an apparel ERP earns its place. Most connections publish a quantity. AIMS360 publishes what you can commit to, which is a different number and occasionally an uncomfortable one.
Open to sell is stock plus work in process minus orders, so an oversold style is genuinely negative. AIMS360 sends that negative by default, because it is what keeps the rest of the maths honest.
Production going over carries its expected delivery date, so JOOR shows immediate goods separately from future goods and a buyer choosing a later ship date sees availability as of that date.
Order against a future date on an oversold style and the negative immediate quantity is deducted from the incoming production, so the number a buyer commits against is one you can actually ship.
Why this matters more than it sounds. AIMS360 can send negatives as zero instead, and some brands ask for it because a negative looks untidy. The cost is that JOOR then shows the full incoming production as available, when part of it is already spoken for. The tidy number is the one that causes the cancellation.
Every AIMS360 warehouse maps to a JOOR warehouse by name, so a brand running East Coast, West Coast or a third-party logistics warehouse can publish availability per location rather than one pooled figure. Names are not case sensitive, and a warehouse can be left unmapped deliberately.
You select which warehouses go over and whether work in process is included, so you decide how much of the future line is visible to buyers and when.
No rekeying, and no spreadsheet round trip. Orders written on the JOOR site or the iPad app come into AIMS360 as customer orders ready for allocation, picking and invoicing. If you also sell through other B2B and B2C channels, they all land in the same order book.
JOOR orders can download and import on their own through the AIMS360 B2B and B2C automatic order import, or be pulled manually when you want to look before you commit.
Orders are validated before import. Anything missing terms, ship via or a sales rep is flagged, and the missing values can be applied across a whole batch from the import screen rather than order by order.
An order carrying a PO number already on file for that customer raises a warning before it lands, so a buyer resubmitting a number does not quietly become two orders in your system.
Where a buyer changes an order after import, cancelling it in AIMS360 allows the updated version to be re-downloaded from JOOR, provided nothing has been allocated, picked or shipped yet.
Discounts carry through, and order and event types map across so trade show, road and pre-season business stays separated in your reporting.
An order source column marks JOOR orders in AIMS360, and JOOR shows a success status once an order has imported, so a missing order is visible from either side.
Three things worth saying plainly, because finding them out mid-season is worse.
Linesheets are create, not edit. AIMS360 creates new linesheets and assigns styles to them. It does not edit linesheets built on the JOOR website, and those linesheets are not visible inside AIMS360. Core styles that live on for years are usually better added to a linesheet in JOOR directly.
Making a style inactive does not remove it from JOOR. Use Delete Products from JOOR on the exported styles view. The same applies to new colorways: they need to be sent before they appear.
Sales rep users are created by JOOR support. Each rep needs the same three character code in JOOR as in AIMS360, and reps are assigned to connections on the JOOR side. Worth doing before your first order import rather than during it.
Everything runs from Modules, Third Party, JOOR:
Your API key, general settings and inventory options. Running more than one JOOR connection is a matter of adding another site and assigning divisions to it, which is how multi-brand businesses keep separate JOOR accounts on one ERP.
Warehouses matched by name, and automap or manual mapping where styles already existed in JOOR before the API was switched on, so nothing gets duplicated.
Customer and style export by style or by style-color, linesheet creation with season and delivery dates, batch description updates, and delete products from JOOR.
Inventory by warehouse with or without work in process, and order download and import with validation, duplicate PO checks and re-download.
Yes. AIMS360 has a pre-built, first-party integration with JOOR built on JOOR's own API. Styles, linesheets, customers and open to sell inventory are sent from AIMS360 to JOOR, and wholesale orders written in JOOR import back into AIMS360. AIMS360 appears on JOOR's technology partners page.
It is native. AIMS360 wrote the integration directly against the JOOR API and maintains it as part of the product, so there is no separate connector to license and no integration platform such as Celigo or Boomi sitting between the two systems. Brands searching for a JOOR connector to bolt onto a different ERP are usually shopping for exactly that kind of middleware, which adds a second subscription, a second release cycle and a second support queue.
JOOR supports two routes. The first is an API integration, where your system posts customer, style and inventory data to JOOR and pulls orders back. The second is a flat file route, where customer and inventory data are uploaded as Excel, TXT or CSV files and orders are exported to an FTP or SFTP folder, which JOOR positions for smaller businesses without an ERP. AIMS360 uses the API route, so open to sell by size and warehouse is calculated in the ERP and posted to JOOR, and orders come back as live orders rather than a file someone has to rekey.
Open to sell is published from AIMS360 to JOOR, and most brands publish at least daily and again after a batch of orders taken outside JOOR, so buyers are looking at current availability. Because AIMS360 calculates open to sell centrally, what reaches JOOR is the real number: negatives where you are oversold, and work in process carrying its delivery date, rather than a flat quantity.
Yes. AIMS360 can download and import JOOR orders automatically through its B2B and B2C automatic order import, and orders can also be downloaded on demand. Imported orders are validated first, so anything missing terms, ship via or a sales rep is flagged and can be corrected in bulk on the import screen before the order is committed.
Yes. Each AIMS360 warehouse is mapped to a JOOR warehouse by name, and availability is published per location, so a brand running a 3PL alongside its own warehouse can publish each separately. Brands not using multi-warehouse keep the JOOR default warehouse, whose name must not be changed. One limitation worth knowing: inbound orders are created against the default warehouse on the AIMS360 customer template rather than the warehouse named on the JOOR order.
Yes, and by default it does. Open to sell is stock plus work in process minus orders, so a style oversold on immediate goods carries a negative number. Sending that negative is what keeps future availability honest: when a buyer orders against a later delivery date, the oversold immediate quantity is netted off the incoming work in process. AIMS360 offers an option to send negatives as zero, but it makes future availability look larger than it really is.
Yes. Work in process is sent with its expected delivery date, so JOOR shows immediate inventory separately from future inventory and a buyer choosing a later ship date sees what will actually be available then. AIMS360 tracks what it has already sent and updates only the work in process entries that have changed, because the JOOR API has no single replace call for future inventory.
AIMS360 creates new linesheets in JOOR with a name, season, year and delivery dates, and assigns styles to them during a style export. It does not edit linesheets built on the JOOR website, and those are not visible inside AIMS360. A new linesheet only reaches JOOR when at least one style is exported against it. Core styles that stay available for long periods are usually better added to a linesheet in JOOR directly.
Yes. Where styles already exist in JOOR before the API is switched on, AIMS360 uses automap or manual mapping so it knows which JOOR products correspond to which AIMS360 styles, rather than creating duplicates. Existing JOOR styles can also be exported from JOOR and brought into AIMS360 through the style import template.
Yes. A brand can set up more than one JOOR site in AIMS360, each with its own API key, which is how multi-brand and multi-division businesses run separate JOOR connections from a single ERP. Where multiple connections exist, divisions are assigned per connection rather than using the all divisions option.
Yes. Where a brand sells in multiple currencies in JOOR, the same currencies are enabled in AIMS360 and orders import in the correct currency. Currency is a required field on both the customer export and the style export.
Where the JOOR connection is not part of the ERP you run today, connecting the two usually means adding an integration platform or a connector built by an outside vendor. That becomes a third product with its own licence, release cycle and support queue, and three vendors to sort out between when something stops flowing. AIMS360 is an apparel ERP where the JOOR connection is part of the product, so one vendor is accountable for styles, inventory, orders and the connection between them. Get in touch if you want to compare that honestly against what you are running today.
JOOR is a digital wholesale platform used by apparel, footwear and consumer brands to present digital linesheets, take wholesale orders from retail buyers, and run trade show and appointment selling. It handles the selling; AIMS360 handles inventory, production, warehouse, EDI and financials behind it.
We will walk through how your linesheets, open to sell and wholesale orders would actually flow, including how negatives and work in process reach buyers, and tell you honestly where the edges are, including the parts that are not automatic.
Get in touch Book a demo
