JTL Amazon integration

What a JTL to Amazon integration actually does

JTL-Wawi is where your catalogue, stock, prices, and orders actually live. Amazon Seller Central is where a large share of your revenue is earned, in a system that speaks its own language of seller SKUs, ASINs, marketplaces, FBA versus FBM, and a strict, rate-limited API. The job of a JTL to Amazon integration is to keep those two worlds honest with each other without anyone exporting a spreadsheet or clicking through Seller Central by hand.

In practice that means two flows running continuously. Outbound: JTL pushes product listings, prices, and available stock to each Amazon marketplace. Inbound: Amazon sends new orders, order items, and refunds back so JTL becomes the single source of truth for what was sold, picked, shipped, and credited. Get both directions right and JTL-Wawi stays the operational hub while Amazon is just another sales channel it feeds and reads.

What data moves

JTL object / event	Becomes on Amazon	Notes
Article (Artikel)	Listing via Listings / product feed	Matched by seller SKU per marketplace, resolved to ASIN
Price (per marketplace)	Pricing feed	Marketplace currency and any channel-specific price
Available stock (FBM)	Inventory quantity feed	Pushed with a safety buffer to prevent overselling
Shipment / tracking	Order fulfilment confirmation	Carrier and service mapped to Amazon carrier codes
Amazon order	Sales order (Auftrag) in JTL	One order to one Auftrag; buyer address via Restricted Data Token
Amazon order item	Order line (Auftragsposition)	Seller SKU mapped back to the JTL article
Amazon refund	Credit note (Gutschrift) in JTL	Same items and tax treatment as the original order
FBA stock and fees	Reconciled into JTL	Amazon owns FBA quantities; fees from SP-API finance data

The SKU mapping, price rules, stock buffers, and carrier translations are agreed once and encoded in the pipeline. After that, nobody re-keys them.

The details that break naive syncs

A quick feed upload or a generic connector gets the happy path working and leaves the expensive edge cases for your team to discover in production:

• SKU to ASIN matching. Amazon works in seller SKUs and ASINs; JTL works in Artikelnummern. A single wrong or duplicated mapping lists a product against the wrong ASIN or splits it across marketplaces. Variants and bundles have to be mapped explicitly, not inferred.
• Multiple marketplaces and currencies. A Pan-EU seller has Amazon.de, .fr, .it, .es, and often .nl, .se, or .pl, each with its own price, currency, and listing state. The integration has to treat marketplace as a first-class dimension, not push one price everywhere.
• FBA versus FBM. FBM stock is yours to manage and must be pushed with a buffer. FBA stock is Amazon’s and must be pulled back, never overwritten. Confusing the two either oversells your warehouse or fights Amazon for control of its own inventory.
• SP-API rate limits and restricted data. The Selling Partner API is throttled per operation with a token-bucket model, and buyer PII sits behind a Restricted Data Token. A naive sync that hammers the API or caches personal data breaks quotas and GDPR at the same time.
• Order state and timing. Pending orders have no confirmed payment and no buyer address; importing them as fulfillable is a mistake. Amazon data also lags, so delta pulls keyed on last-updated need overlap and de-duplication rather than a naive since-timestamp.
• VAT and marketplace facilitator rules. Depending on marketplace and Amazon VAT Calculation Service, tax may be collected and remitted by Amazon or by you. The order data has to carry the right tax treatment so JTL and any downstream accounting stay correct.
• Partial feed failures. Amazon accepts a feed and then reports per-SKU results asynchronously. A pipeline has to parse that processing report, retry only the SKUs that failed, and never assume an accepted feed means every line succeeded.

How we build and run it

We build this as a pipeline, not a scheduled export. Outbound listing, price, and stock changes are debounced and submitted to the SP-API as feeds; inbound orders and refunds are pulled on a short interval, keyed on last-updated with overlap, and written into JTL. Every event carries a stable identifier, so a retry or a re-run never creates a duplicate order or double-books a refund - the pipeline is idempotent by design.

It runs on cloud-native, fully EU-hosted AWS infrastructure, so order and buyer data never leaves the EU, which keeps the DPA / AVV and your GDPR obligations clean. Restricted buyer data is fetched only when fulfilment needs it and kept to the minimum JTL requires.

Then we keep it running. Monitoring, alerting, incident response, and - critically - tracking Amazon SP-API and JTL changes are our responsibility under contract. When Amazon deprecates a feed type or tightens a rate limit, that is our problem to absorb, not a surprise your operations team meets during peak season. You get a named owner and an SLA, not a script somebody has to remember to run.

When this integration is worth building

If you sell on a single Amazon.de account and JTL-eazyAuction covers it, that is genuinely fine and we will tell you so. A managed pipeline earns its place when the channel gets serious: several seller accounts to consolidate, Pan-EU FBA across marketplaces, custom or channel-specific pricing, high SKU counts where overselling has real cost, or a need to feed order and settlement data onward into a warehouse, accounting, or reporting system that eazyAuction never touches. At that point the question is no longer whether you can move the data, but who owns it when Amazon changes the rules.