How to automate Amazon load imports into a TMS using N8N

N8N is an open-source workflow automation platform that lets you connect systems, APIs, and databases through a visual drag-and-drop editor with the option to write JavaScript when the logic gets more complex. It runs on your own infrastructure, with no dependency on external clouds. For logistics data processed at any meaningful scale, that distinction matters.

This article covers what N8N is, why we chose it, and how we used it to solve a specific problem: a transport management system (TMS) client who was manually entering Amazon freight loads one by one, every day.

What is N8N?

N8N is a workflow automation platform built around visual connector blocks. Each block does one thing reads a file, calls an API, runs a piece of code, sends a Slack message. You wire them together in sequence and you have a workflow. The integration library covers Google Workspace, Microsoft 365, AWS, Slack, standard REST APIs, and most common databases.

Two things separate it from alternatives like Zapier or Make.

First, it’s open-source and can be self-hosted. If your company has data residency requirements, or you’re running enough automation volume that per-request pricing starts to hurt, owning the infrastructure changes the economics entirely. A cloud automation tool charging per execution gets expensive fast when you’re processing thousands of loads per month.

Second, it’s genuinely usable by developers. Non-technical people can build simple automations without code, but when you need real logic – data transformation, error handling, loops, conditional branching – you can write JavaScript directly in a code block. That’s unusual in this category of tools.

N8N vs Zapier vs Make – key differences

N8N makes sense when you have data residency requirements or need logic that goes beyond simple if-then rules. Zapier and Make win on simplicity for standard, linear automations between popular tools.

The problem: Amazon doesn’t have an API

One of FireTMS’s clients a logistics TMS platform with 14,000 active users across 10 countries and over 8.5 million orders processed, manages freight loads sourced through Amazon’s carrier platform. The constraint that drove everything: Amazon has no public API for freight data. The only way to get load information out of their system is to download a CSV export.

That CSV had everything needed to create a load in FireTMS: pickup location, delivery address, driver, cargo details, price. But FireTMS had no native CSV import. So the client had a person doing it manually. Every load. Every day.

At 100 loads per import, that’s several hours of copy-paste work daily. And at that pace, errors are inevitable a transposed digit in a price field, a wrong pickup ID, a missed required field. In a TMS, those aren’t just data problems. They become routing errors, billing disputes, and support tickets.

The client was frustrated enough to consider leaving FireTMS. That was the actual business case for building this.

How the automation works

The workflow has five stages.

Web form. N8N provides a native web form component. We built a simple form where the client uploads their Amazon CSV, enters their tax ID, and provides their FireTMS API key. Basic validation runs here, malformed files don’t proceed further.

CSV parsing. N8N reads the uploaded file through a dedicated block, but breaking it down into individual load objects requires configuring the right option and writing a piece of JavaScript code. It’s not fully native, it needs setup.

Data transformation. This is where the actual work is a typical example of a task in the area of automated data processing. Amazon uses internal IDs for pickup and delivery locations, something like „RDS2” for a specific warehouse. FireTMS needs a full address, not an Amazon code. We built a mapping layer that translates these IDs using a reference table maintained by FireTMS. Price normalization runs here too: Amazon sometimes sends zero-value loads, which we default to €0 and flag. All the transformation logic runs in about 100 lines of JavaScript inside a single N8N code block.

API calls to FireTMS. FireTMS built a dedicated API endpoint for this use case their standard API didn’t support external load creation. This is a classic case where integrating two systems requires work on both sides: we built the workflow, they exposed the endpoint. One constraint on their side: only one load can be processed at a time. We built in a 2-second delay between requests using N8N’s batching configuration. At 100 loads, that’s roughly 3-4 minutes of total processing time.

Error handling and reporting. All loads are processed sequentially. When the run finishes, the workflow routes to one of three response forms depending on the outcome.

Error handling: where most of the thinking went

If everything imports cleanly, the client sees a confirmation page.

If there are „place ID” errors, Amazon sent a location code that FireTMS doesn’t recognize, the client gets a specific message listing which IDs are unknown and a prompt to contact FireTMS to add them to their database. We also log these in a Google Sheets register with timestamps and error codes, so we can batch-send missing location IDs to FireTMS for them to add on their side.

For other errors, missing required fields, duplicates, there’s a third form with a breakdown of what failed and why.

The duplicate issue is worth explaining. Early on, if a client resubmitted a CSV containing already-imported loads, FireTMS would create duplicates. The client then had to log in and delete them manually. FireTMS resolved this by using the Amazon VRID (the load’s external ID) as a deduplication key. If a load with that VRID already exists, it’s skipped.

One thing still in progress: when 50 out of 150 loads fail, the client currently gets those errors in a form response – not the easiest to act on. The plan is to return a CSV of the failed loads with an error code column appended. The client fixes just those rows and resubmits, without touching the loads that already imported successfully.

What it delivered

Import time dropped from several hours to the time it takes to upload a file and wait 3-4 minutes for processing.

For FireTMS, the automation solved a retention problem. A large client at risk of churning – because the manual import process made the software feel incomplete stayed, because the problem was solved.

There’s also a scalability argument: if the client’s load volume doubles, processing time scales linearly with the batch delay, not with headcount. Adding a second client to the same workflow means duplicating it and swapping credentials.

What N8N doesn’t solve well

Observability is the honest limitation. N8N’s built-in execution history is good enough for debugging a single workflow with a handful of clients. It stops being adequate when you need to search across workflow runs, aggregate error patterns, or set up meaningful alerts. For a product serving many clients at scale, plan to pipe logs into an external tool from day one.

Concurrent execution on a shared server also needs explicit thought. If two users submit files simultaneously on a workflow with a 2-second delay between API calls, requests will collide. N8N doesn’t manage that automatically. For a single-client setup it’s fine; for a multi-tenant product you need a queuing strategy.

The Python runtime is still in beta. If your transformation logic is more naturally written in Python, N8N isn’t production-ready on that front yet.

The next automation on the roadmap

Amazon sends load cancellation notifications by email. Right now, someone reads those emails and manually cancels the loads in FireTMS.

The plan: N8N watches a dedicated Gmail inbox, triggers a workflow on new emails from Amazon, extracts the VRID from the message body, and calls the FireTMS cancellation endpoint. The workflow structure is already sketched out, it’s mainly a matter of getting the email parsing right and confirming API behavior before pushing to production.

Wrapping up

N8N worked here for one straightforward reason: the problem wasn’t technically complex, but it needed flexibility – combining a CSV file, an external API with rate limits, and a reasonable error reporting experience for a non-technical user. Writing this from scratch in Python would have produced the same result with higher maintenance cost and less visibility for anyone inheriting the project.

Not every automation needs N8N. But if you have a manual process that’s mostly about moving data between systems, it’s worth checking whether a few workflow blocks can replace a few hundred lines of code.

Have a similar case in your organization? Let’s talk – we’re happy to check whether N8N or another approach to IT systems integration makes sense in your context. You can also browse our case studies to see how we approach this kind of work.