FBA inbound is one of those processes that stays manual long after it should, because each individual shipment is only mildly annoying. Someone opens Seller Central, works out what to send, re-enters quantities that already exist in the ERP, compares the shipping options, downloads the labels, finds the right printer and walks them to the floor.
None of that is difficult. It is just repetitive, it happens on every replenishment, and every step is a place where the data in Seller Central drifts from the data in your own system.
What the manual process actually costs
The visible cost is time, and it is the least interesting part. Three other costs matter more.
The first is re-entry. Your ERP already knows what you have, where it is and how it packs. Typing a subset of that into another system by hand produces a second version of the truth, and when the two disagree nobody can say which is right without checking the physical stock.
The second is inconsistent decisions. Choosing a shipping plan involves comparing options, and when a person does that under time pressure they do it differently on different days. The cheapest option is not always chosen, and nobody can reconstruct afterwards why a particular plan was picked.
The third is the gap between the plan and the pallet. Labels are generated against what the plan says is in each carton. If the carton is packed differently, the discrepancy is discovered at the Amazon fulfilment centre rather than at your dock, and that is an expensive place to find out.
The automated flow
Built properly, the whole sequence runs from the data you already hold. There are five steps.
Shipment plan creation. Inbound shipment plans are built from your own inventory data rather than re-entering it in Seller Central by hand. The integration knows what you have and what needs replenishing, so the plan is generated rather than assembled.
Choosing the shipping plan. Where options are returned, the lowest-cost plan that meets your requirements is selected according to rules you set, rather than whoever is at the screen comparing them that morning. The decision becomes consistent and reviewable.
Carton labeling. Carton labels are generated to match Amazon’s inbound requirements, tied to what is actually packed rather than what was assumed at planning time. This is the step that closes the gap described above, and it only works if your carton data is real.
Shipping label generation and download. The shipping labels for the inbound shipment are produced and downloaded as part of the same flow, rather than as a separate manual trip into Seller Central after the plan is confirmed.
Routing files to the warehouse. The generated carton and shipping files reach the warehouse floor automatically, rather than a person locating and printing them manually. This is the least glamorous step and the one that removes the most day-to-day friction.
The result is that a replenishment becomes a decision rather than a procedure. Someone approves what is going; the system does the rest.
What has to be in the ERP first
This is where inbound automation projects succeed or stall, and it has little to do with the API.
Accurate inventory. The shipment plan is built from your inventory position, so that position has to be correct, including the distinction between what is on hand, what is committed and what is already in transit. If your stock figures need a manual sense-check before anyone trusts them, automating on top of them propagates the error faster.
Real carton data. You need to know what goes in a carton, how many units, what the carton weighs and what its dimensions are. Plans and labels both depend on it. Where this is estimated at pack time by whoever is building the pallet, there is nothing stable for the integration to work from, and this is the most common blocker we see.
A single product identity. Your SKU, the ASIN and the FNSKU all have to resolve to the same product reliably. Where that mapping is maintained in a spreadsheet, it is the first thing to move into the system.
Getting these right is ERP work rather than API work, which is why it belongs in custom ERP development rather than being treated as part of the integration. It is also work that pays off independently of whether the inbound automation ships.
Where this sits alongside other SP-API work
Inbound is one operation among many on the same API surface. Orders, inventory, reports, fulfilment and automated repricing via approved APIs all run through SP-API, and they share authentication, rate limiting and error handling.
That matters for sequencing. If you are going to integrate several of these, building the shared foundation once is better than building inbound as a standalone connector and then rebuilding the same plumbing for orders. We cover the broader surface in Amazon SP-API integration.
For a US consumer electronics brand, FBA inbound automation runs inside the same ERP that holds the orders, inventory and shipping, alongside EDI for Amazon’s wholesale program and API integrations for other channels. Keeping it in one system is what makes the inventory position single-valued, which is the precondition for all of it.
Plan for the API changing
One practical caution. Amazon revises its inbound operations and deprecates older versions over time, and the inbound area has seen more change than most. An integration built against a current version will need updating, and a project plan that treats the integration as finished at go-live is understating the commitment.
Check the current API version and the current inbound requirements before you build, and treat label and pack requirements as a live specification rather than something you learned once. The same applies to prep and labeling rules, which vary by category and change: check the current spec rather than assuming what was true at a previous onboarding still holds.
Build it so that the version-specific parts are isolated. When an operation changes, you want to be updating one adapter rather than tracing the change through your replenishment logic.
Where to start
If inbound is currently manual, the useful first step is not an API call. It is checking whether your carton data and inventory position are good enough to build on, because that answer determines whether this is a short project or a longer one.
From there, automating shipment plan creation first gives the most immediate relief and exercises the data quality honestly. Labels and warehouse routing follow naturally once plans are being generated from real data.
We build this as Amazon FBA inbound automation inside the ERP, so the plans, labels and inventory all come from the same records. If you want to work out whether your data is ready for it, get in touch with how your inventory and carton information are held today.
Common questions
What usually blocks an FBA inbound automation project?
Carton data. Shipment plans and labels depend on knowing what is in each box and what it weighs. Where that is estimated by hand at pack time, the automation has nothing reliable to build from.
Does automation remove the need to review shipping plan options?
It removes the manual comparison, not the decision. The rules for which plan is acceptable are yours to set; the integration applies them consistently rather than leaving them to whoever is at the screen.
Will an inbound integration keep working as Amazon changes its APIs?
Not without maintenance. Amazon revises inbound operations and deprecates older versions over time, so check the current API version and plan for periodic updates rather than treating it as finished.