Load planning inside your own ERP and TMS — a use case for the API and shared teams
Distribution & logistics technology
A use-case guide for Distribution & logistics technology teams to apply to their own operation — not a specific customer story. The workflow and ContainerMath features shown are real; the figures illustrate what this use case typically targets rather than results measured from one account.
A use-case guide for distributors and 3PL technology teams: once load planning is a repeatable, high-volume step, it belongs inside the systems people already work in. This walks through calling ContainerMath's packing engine from an ERP, TMS or CRM through the REST API, and giving a whole team one shared workspace of boxes, items, pallets, vessels and saved plans.
The challenge
When load planning is occasional, a standalone tool is fine. When it's a step in every order — hundreds a week — copying cargo out of the ERP into a separate planner and the plan back again becomes the bottleneck, and each planner keeps their own box sizes and presets so results drift between people. A scaling distributor or 3PL needs load planning to happen where the order already lives, and every planner to work from the same data. This guide shows how the API and shared team workspaces close that gap.
Before vs. after
- 1Copy cargo between systemsOrder data was exported from the ERP or TMS, re-entered into a separate planning tool, and the result copied back — by hand, per order.
- 2Plan outside the system of recordBecause planning lived apart from the order, the load plan and the order could drift out of sync between the two tools.
- 3Everyone keeps their own presetsEach planner maintained their own box sizes, pallet specs and vessel list, so two people planning the same cargo could get different answers.
- 4Re-solve at every volume stepAs order volume grew, the manual copy-in/copy-out step scaled linearly with it — the process couldn't keep up.
- 5No shared historySaved plans lived on individual accounts, so a repeat lane one colleague had already solved wasn't visible to the next.
- 1Call the engine from your stackThe REST API runs the same packing engine from inside your ERP, TMS or CRM, so a load plan is generated as part of the existing order flow.
- 2Keep planning at the orderCargo goes to the API and the plan comes back in-system, so there's no copy-in/copy-out and nothing to drift out of sync.
- 3Share one team workspaceAn organization holds boxes, items, pallets, vessels and saved plans in common, so every planner works from the same library.
- 4Scale without more re-keyingBecause the plan is produced programmatically, growing order volume doesn't add manual planning steps.
- 5Reuse saved plans across the teamRepeat lanes reload a shared saved plan, so work one colleague did is available to the next.
Inside ContainerMath: the parts they used
The results
- Load plans are generated inside the ERP, TMS or CRM through the API instead of a separate tool.
- Planning stays at the order, removing the copy-in/copy-out step and the drift it caused.
- A shared team workspace gives every planner the same libraries and saved plans.
- Growing order volume no longer adds manual planning steps.
Stop guessing in spreadsheets. Build a 3D load plan with live CBM and payload.
Try ContainerMath free →- From container plan to filing-ready export documents without retyping the shipmentExport documentation & trade compliance
- From 4 days in Excel to minutes: how a national manufacturer automated container planningManufacturing
- Quoting container space in minutes — a use case for freight forwarders & 3PLsFreight forwarding & 3PL
ContainerMathThe industry standard for 3D container cargo packing and loading plans. Optimize layouts, maximize volume, and reduce shipping overhead.
Built by Backrock Studios