Connected by API, not EDI. Pick tickets reach Bergen on export, shipments come back with carton level SSCC detail, and AIMS360 builds the retailer 856 from it. Inbound POs and receipts run as CSV.
AIMS360 connects to Bergen Logistics through Bergen's REX11 web services API. A pick ticket reaches the warehouse the moment you export it, the API answers the call with an accept or an error, and shipped orders come back over the same API on a schedule you set, as often as every five minutes, carrying the carton level detail AIMS360 uses to build the retailer 856. Inbound purchase orders and receipts run as CSV. Nothing in the connection is an X12 envelope, and the retailer still gets a fully conformant advance ship notice.
AIMS360 calls Bergen's REX11 web services API directly. When you export a pick ticket, AIMS360 makes the call and Bergen accepts it or returns an error on the spot. There is no file to drop, no FTP folder, and no scheduled pickup for the warehouse to miss. On the way back, AIMS360 pulls shipped pick tickets over the same API on a schedule you control, as often as every five minutes, and turns each one into a shipment with carton level detail.
The API is configured inside AIMS360 under System Settings, Bergen Warehouse: choose API as the integration method, enter the web address and credentials Bergen issues to your account, and select API version 3. If you fulfill from more than one Bergen location, say the United States and Canada, each location gets its own credentials. No middleware, translator or connector subscription sits between the two systems.
| Direction | What travels on the call |
|---|---|
| Pick ticket to Bergen | Bill to and ship to addresses, ship via and service level, billing option, payment terms, order type, and every line by UPC or by style, color and size. Packing notes, VAS notes and shipping notes ride along as special instructions, and order line notes land on the line item, up to 2,000 characters each. |
| Shipped pick ticket back | Carton by carton: what is packed in each box, the tracking number per carton, weights, the shipping charge Bergen billed, and the SSCC on each carton label. That carton structure is what lets AIMS360 build the 856 without anyone re-keying it. |
| Styles to Bergen | New styles are pushed into Bergen's warehouse system from AIMS360. Styles that already exist at Bergen are linked on a mapping screen by style number, description or both, with colors by code or description. Price and availability date can be updated after the first push. |
Two timing facts, because "API" gets used loosely in this category. Bergen's own API documentation states that pick tickets are not created in its warehouse system in real time, and that they are typically available within 30 minutes of a successful call. And the return trip is a pull, not a push: AIMS360's automatic import can run as often as every five minutes, up to 148 runs a day, and Bergen's guidance is every 15 to 30 minutes during working hours. So a pick ticket exported at 9:00 is typically in Bergen's system before 9:30, and a carton packed at 2:00 is in AIMS360 on the next import run, with an error message attached to anything that failed along the way.
| Message | Direction | Transport | What it carries |
|---|---|---|---|
| 940 | AIMS360 to Bergen | REX11 web services API | The ship order, serving as order or pick ticket depending on a system setting, with the pick number, the customer purchase order and an order type Bergen uses to route the work |
| 945 | Bergen to AIMS360 | REX11 web services API | Shipment confirmation carrying carton level detail, weights, tracking per carton, shipping charge and the SSCC on each carton |
| 832 | AIMS360 to Bergen | REX11 web services API | Style master. New styles pushed to Bergen's system, or existing styles mapped to AIMS360 records |
| 943 | AIMS360 to Bergen | CSV, delivered by FTP | Inbound advice. The vendor purchase orders Bergen should expect on the container, exported from the AIMS360 warehouse module |
| 944 | Bergen to AIMS360 | CSV | The receipt Bergen produces after putaway, imported through the AIMS360 Import Receipts module against the open purchase order or return line |
A hybrid connection like this is normal and usually the right answer. The API carries the traffic where you want an immediate result and a reason attached to any rejection: orders out, shipments back, styles across. Files carry the inbound side, where a container is planned days ahead and a failed file can be corrected and reprocessed rather than lost.
AIMS360 can run a retailer's EDI drop ship program end to end without a person in the loop, and the Bergen API is one of the three connections that switches that on. The retailer's 850 purchase orders download and import on a schedule. Pick tickets are created and sent to Bergen over the API. Shipped data comes back over the API. AIMS360 generates the 856 advance ship notice and the 810 invoice and syncs them to the retailer. The AIMS360 support documentation is explicit that the Bergen API path needs no additional setup steps to take part in this automation.
Three conditions apply. The automation is for drop ship orders only, so bulk ship to DC and cross dock orders still run through the normal pick, pack and ASN steps. It requires the Multi Warehouse feature. And it runs on AIMS360's own EDI service, since AIMS360 has to see the 850 arrive and the 856 leave to close the loop. The retailer side of the workflow is on the EDI drop ship page.
Retailer EDI and warehouse integration are two different jobs, and only one of them has to be EDI. AIMS360 runs the retailer side itself: the 850 purchase order comes in, and the 855 acknowledgement, 856 advance ship notice and 810 invoice go back on that retailer's routing guide spec. The warehouse side is separate, and it runs on whatever the warehouse can do. API, CSV, tab delimited, XML, flat file, or real X12 if they have it.
We describe the warehouse messages using the X12 numbers, 940, 943, 944, 945, 947, 832 and 846, because that is the shared vocabulary of the industry and everyone knows what a 940 means. It is not a statement about the file format. Bergen is the clearest example on our list: three of those messages travel as API calls, two travel as CSV, and not one of them is an EDI envelope.
| The assumption | What is the case |
|---|---|
| Our 3PL has no EDI, so we cannot automate fulfillment | The warehouse connection can be API, CSV, tab delimited, XML or flat file. EDI capability at the warehouse is optional |
| If we use a 3PL we lose retailer EDI compliance | Retailer EDI stays in AIMS360 and is unaffected by where the goods sit. The warehouse never touches a retailer document |
| A 940 means an EDI file | A 940 means a ship order. How it travels is a transport decision made per warehouse |
| We need an EDI provider as well as the ERP | AIMS360 is the EDI. There is no separate translator or subscription in between |
| Modern ecommerce 3PLs are ruled out because they only have an API | An API is easier to integrate than EDI, not harder. It is the warehouses with neither that are the problem |
If your ERP insists the warehouse must be EDI capable, your shortlist quietly shrinks to warehouses that have already built EDI, which rules out a large share of modern ecommerce 3PLs for a reason that has nothing to do with how well they pick, pack and ship.
This is the most valuable mechanism in any 3PL integration and almost nobody explains it, so here it is in order.
Bergen packs the carton and assigns it an SSCC, the serial shipping container code that uniquely identifies that carton and appears on the GS1-128 label the retailer's dock will scan.
The shipment confirmation returns not just "shipped" but the full carton structure: which units are in which carton, the weight, the tracking per carton and the SSCC.
The advance ship notice is a nested structure, shipment to order to carton to item. It cannot be built from a shipped quantity. It can only be built from the carton detail, which is exactly what came back.
The SSCC on the physical label matches the SSCC in the electronic notice. The carton is received without a discrepancy, which is where chargebacks come from.
One setting decides whether step 2 works. AIMS360 offers two ways to take shipped pick tickets back from Bergen. Finalize Pick Tickets is the summary version: total carton count, total weight, one tracking number and the shipping cost. It is fine for orders that will never need an ASN. Shipment Processing replicates the shipment carton by carton with per carton identifiers and tracking, and it is the required setting for any EDI order, because it is the only one that gives the 856 its carton structure. Pick the wrong one and the shipment still imports, but the notice cannot be built from it.
Take any step out and the chain breaks. A warehouse that returns only a shipped quantity cannot support a compliant ASN no matter how good your ERP is. When you are evaluating warehouses, the question is not "do you support ASN", because everyone says yes. It is "what carton level detail do you return on shipment confirmation, and does it include the SSCC."
Last reviewed 4 September 2026 by the AIMS360 integrations team.
Integration mechanics reviewed against the AIMS360 support documentation for the Bergen API and Bergen's REX11 Web Service API documentation. Company facts checked against bergenlogistics.com and its parent company's published material, and attributed rather than stated as our own.
Most of the work in a Bergen implementation is data hygiene rather than connectivity. These are the pieces that have to be right.
| Item | What AIMS360 does | Why it matters |
|---|---|---|
| Product matching | A line with a valid 12 digit numeric UPC is matched on the UPC, and style, color and size are ignored. Without a UPC it matches on the AIMS360 style, color and size codes | A clean UPC file makes matching one field wide. A missing or duplicated UPC is the usual cause of a rejected line |
| Ship via cross reference | Bergen's codes for UPS, FedEx and USPS come pre loaded and are linked to the matching AIMS360 ship via codes. Other carriers and services are added from Bergen's published service list | The service on the pick ticket has to be one Bergen recognizes, or the order cannot be rated and shipped |
| Billing type | Prepaid, third party and collect billing are configured per shipping service, including customers who ship on their own carrier account | Retailer routing guides often require freight billed to the retailer's account. That is a setting, not a step at ship time |
| Payment terms | Every AIMS360 payment term is mapped to one of Bergen's five: Pending, Net, CC, COD or Wire | A COD order has to leave the warehouse as COD for the carrier to collect. Bergen cannot know that unless the term travels with the order |
| Order type | AIMS360 sends Dropship for EDI drop ship orders and Wholesale for everything else. Bergen can hard map Web, Retail or Cross Dock from the five character AIMS360 customer account code, for example treating your Shopify account as Web | Bergen routes packing and labeling by order type, so the mapping is agreed with your Bergen representative during implementation |
| Prepaid orders | A pick ticket for a prepaid customer needs a prepayment on the order or a credit card pre authorization, which holds funds for 30 days, before it can be exported | Bergen ships and returns the freight charge and tracking, then AIMS360 invoices and charges the card for the full amount including freight |
| Multiple locations | Each Bergen facility is configured on its own with its own API credentials and is another warehouse on the same AIMS360 stock record | Inventory templates decide what each location can sell and routing decides where an order ships from |
All of this lives in the 3rd Party Shipping area of AIMS360 and is documented step by step in the AIMS360 support center. Implementation runs it with you. The Bergen side is a call to your Bergen representative for credentials, the service list and the order type mapping.
When a unit is found damaged at Bergen it does not disappear from the count, and it does not sit in sellable inventory waiting to be allocated to a customer who will never receive it. It moves to a ghost location: a position that exists in the record but is not available to sell. The unit stops being promised to anyone and stays visible, so damages remain a number you can act on rather than shrinkage you find at the next count.
Attributed to Bergen and to its parent company rather than repeated as fact.
| What they publish | Detail |
|---|---|
| Company | Bergen Shippers Corp., trading as Bergen Logistics, founded 1998 and headquartered in North Bergen, New Jersey |
| Ownership | Elanders AB, a publicly traded Swedish group, acquired 80 percent in November 2021. Bergen operates as part of that group |
| Footprint | 18 locations published on their own site across the United States, Canada, the Netherlands, Sweden, Germany, the United Kingdom, Singapore, India, China, Brazil and Mexico |
| Team | Around 800 employees, published by the parent group for the 2025 financial year |
| Apparel handling | They describe themselves as experts in garment on hanger, and publish custom embroidery and branded packaging. Ticketing, steaming and pressing are not published on their own site |
| Channels | Omnichannel and ecommerce fulfillment, and subscription box fulfillment which they put at more than 20 million boxes a year into the US and Canada |
| Cross border | Freight forwarding with customs clearance, and bonded warehousing for duty deferment |
| Warehouse system and API | Their site presents their platform as CloudX Systems. The integration surface AIMS360 connects to is the REX11 web services API, a SOAP and XML interface Bergen has published since at least 2015 with versioned production endpoints. AIMS360 runs on version 3 |
| ERP partners they list | Their partnerships page names several apparel ERPs as integration partners. AIMS360 is not on that page at the time of this review, even though this connection has been in production for years. If you are evaluating Bergen and asking them about ERPs, ask about AIMS360 by name |
| Leadership | Charles Ickes was appointed chief executive in March 2024 |
| Not published | Square footage, customer count, certifications, named carriers and retailer compliance programs. Directory sites carry square footage figures Bergen does not publish, so we are not repeating them |
A naming note: this is Bergen Shippers Corp. in North Bergen, New Jersey. It is unrelated to Norwegian companies carrying the name of the city of Bergen, and unrelated to other trucking firms operating out of Bergen County.
Bergen does not create pick tickets in real time on its side. The API accepts the call immediately and returns any error immediately, but Bergen's documentation says the pick ticket is typically visible in its warehouse system within 30 minutes rather than instantly. Plan cutoff times around that, not around the API response.
An inbound advice cannot be cancelled or replaced through the connection. Once a 943 has gone to Bergen there is no method in the AIMS360 integration to void or amend it. The process is to contact Bergen, have them void it in their warehouse system, and then retransmit. Raise inbound advices when the shipment is firm.
Cancelling a released pick ticket is a manual step. It is a conversation with the warehouse rather than a button in AIMS360, which is true of most warehouses on our list.
Returns do not travel through the connection. Return authorizations and credit memos are created in AIMS360 by hand. There is no return export or import on the Bergen connection today.
The 947 and 846 are not part of this connection. Bergen's API can serve inventory queries, but the AIMS360 integration does not consume them. Stock adjustments and physical counts come in through the standard AIMS360 import templates using data from Bergen's portal, and scheduled reconciliation is arranged with Bergen directly.
Yes. AIMS360 connects to Bergen's REX11 web services API directly, with no middleware in between. Pick tickets go to Bergen as API calls, shipped pick tickets come back as API calls with carton level detail, and styles are pushed to Bergen's system or mapped to existing records over the same API. Inbound purchase orders and receipts run as CSV. It is live in production and listed on the AIMS360 3PL integrations hub.
The pick ticket is handed to Bergen the moment you export it and the API returns an accept or an error on that call. Bergen's own documentation says the pick ticket is then typically in its warehouse system within 30 minutes. Shipped pick tickets are pulled back by AIMS360 on a schedule you set, as often as every five minutes, with Bergen recommending every 15 to 30 minutes during working hours. The fully automated version of that loop is on DTC and 3PL fulfillment automation.
No. AIMS360 performs the retailer EDI itself, so the 850 comes in and the 855, 856 and 810 go back on the retailer's routing guide spec regardless of what the warehouse can do. The warehouse connection is separate and runs on whatever that warehouse supports: API, CSV, tab delimited files, XML, flat files, or real X12 if they have it. Bergen Logistics is the clearest example, exchanging no X12 at all while the retailer still receives a conformant advance ship notice. The retailer side is covered on the EDI for retailers page.
Yes. The Bergen API is one of three connections that enable AIMS360's drop ship automation. With it on, the retailer's 850 orders download on a schedule, pick tickets are created and sent to Bergen, shipped data returns over the API, and the 856 and 810 are generated and synced without manual steps. It applies to drop ship orders only, requires the Multi Warehouse feature, and runs on AIMS360's EDI service. See EDI drop ship for the retailer workflow.
The 856 is a nested structure: shipment, then order, then carton, then item. It cannot be assembled from a shipped quantity. The warehouse has to return which units are in which carton along with the SSCC on the physical GS1-128 label, and the ERP has to consume that structure and map it to the retailer's spec. Bergen returns carton level SSCC detail on the shipment confirmation and AIMS360 builds the notice from it, so the code the dock scans matches the code in the notice. In AIMS360 that requires the Shipment Processing setting rather than Finalize Pick Tickets. The document is explained on the EDI 856 page.
Not "do you support ASN", because the answer is always yes. Ask what carton level detail comes back on shipment confirmation, whether it includes the SSCC, and whether it is returned per carton rather than per order. A warehouse that returns only a shipped quantity cannot support a compliant notice however good your ERP is, and that gap produces receiving discrepancies and chargebacks months after go live. The label side is covered under UCC-128 label printing.
API credentials and web address from Bergen in AIMS360 System Settings, one set per Bergen location. Ship via codes cross referenced, with UPS, FedEx and USPS pre loaded. Billing type per shipping service. Every payment term mapped to one of Bergen's five. Styles pushed to Bergen or mapped to records already in its system, ideally with a clean 12 digit UPC on every SKU. And Shipment Processing chosen over Finalize Pick Tickets if you have EDI retailers. Implementation walks through all of it, and Multi Warehouse covers the location setup.
They move to a ghost location rather than being written off or left in sellable stock. The unit stops being available to allocate, so you are not selling goods that cannot ship, and it stays visible, so damages remain a number you can act on rather than shrinkage found at the next count. The ghost location is another position on the AIMS360 stock record under Multi Warehouse.
Not through the connection. There is no method in the AIMS360 integration to void or replace an inbound advice once it has gone across. Contact Bergen, have them void it in their warehouse system, and retransmit. Raise inbound advices when a shipment is firm rather than speculatively. Other partner connections and their limits are on the 3PL integrations hub.
They publish 18 locations across North America, Europe, Asia and Latin America, plus freight forwarding with customs clearance and bonded warehousing for duty deferment. In AIMS360 each facility is configured with its own Bergen API credentials and is another warehouse on the same stock record, so inventory templates decide what each location can sell and routing decides where an order ships from. Adding a country is adding a location, not a system. That is the Multi Warehouse model.
Bring a retailer order and a routing guide. We will export the pick ticket to Bergen over the API, take the carton detail back, and show you the advance ship notice it produces with the SSCC codes matching the labels.
