# JTL Amazon integration

*JTL → Amazon*

**In short:** A JTL to Amazon integration keeps JTL-Wawi and Amazon Seller Central in sync in both directions: it pushes product listings, prices, and available stock out to each Amazon marketplace via the SP-API, and pulls new orders, order items, and refunds back into JTL as sales orders and credit notes. Done properly it is not a one-off feed upload - it is a continuous, idempotent pipeline that matches your seller SKUs to the right ASIN and marketplace, keeps FBM stock buffered against overselling, respects SP-API rate limits and restricted-data (PII) rules, and confirms shipments back to Amazon so buyers see tracking on time.

## 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.

## Frequently asked questions

### Does JTL-Wawi support Amazon, eBay, and other marketplaces for order syncing?

Yes. JTL's own multichannel module, JTL-eazyAuction, connects JTL-Wawi to Amazon, eBay, OTTO Market, Kaufland, and a few other marketplaces: their orders come into the Wawi as sales orders (Aufträge), and stock and listings go back out. Channels eazyAuction does not cover natively are usually connected through JTL's SCX channel interface. For one or two marketplaces run from a single JTL instance, that is often all you need. Where you go beyond it, a managed pipeline earns its place, as the next answer explains.

### Does JTL not already have an Amazon connector with eazyAuction?

It does, and for a single Amazon.de account fulfilled through JTL it is often enough - if it covers your case, use it and we will say so. A custom managed pipeline earns its place when eazyAuction hits its limits: consolidating several seller accounts, Pan-EU FBA across multiple marketplaces, custom repricing or channel-specific pricing, feeding order data onward into a warehouse or accounting system, or listing logic that its mapping cannot express.

### How do you match JTL products to the right Amazon listing?

By seller SKU, not by ASIN guessing. Your JTL Artikelnummer (or a dedicated Amazon SKU field) is mapped to the seller SKU on each marketplace, and the SP-API resolves that to the correct ASIN and listing. Variants, marketplace-specific SKUs, and bundles are mapped explicitly up front so a product never lands on the wrong listing or gets duplicated across Amazon.de, .fr, .it, and .es.

### How do you stop Amazon overselling stock JTL has already committed elsewhere?

Stock is the single most dangerous field to sync. For FBM listings we push available quantity from JTL with an agreed safety buffer, debounce rapid changes, and treat the inventory feed as authoritative only after Amazon confirms it in the processing report. FBA quantities are owned by Amazon, so we reconcile those back into JTL rather than pushing them out. The goal is that a sale on your website never sells the last unit twice on Amazon.

### Which Amazon API do you use, and does it handle buyer data under GDPR?

The Amazon Selling Partner API (SP-API), which replaced MWS. Buyer personal data - name, shipping address, contact - is restricted data behind a Restricted Data Token, so we request it only when an order actually needs fulfilling and store the minimum JTL needs. Everything runs on cloud-native, fully EU-hosted infrastructure, and the DPA / AVV covering that data flow is part of the engagement.

### How are refunds, cancellations, and Amazon fees handled back in JTL?

An Amazon refund becomes a credit note (Gutschrift) against the matching JTL sales order, with the same items and tax treatment as the original. Cancellations before shipment release the reserved stock. Amazon marketplace fees and FBA charges come through the SP-API finance and settlement data, which we can reconcile into JTL or hand to your accounting pipeline so the payout matches the underlying orders.

## Common errors

- [Amazon SP-API: QuotaExceeded](https://seamless.engineering/errors/amazon-sp-api-quota-exceeded/)
- [Amazon SP-API: Access to requested resource is denied](https://seamless.engineering/errors/amazon-sp-api-access-denied/)
- [Amazon SP-API: InvalidInput: Invalid request parameters](https://seamless.engineering/errors/amazon-sp-api-invalid-input/)

## Related integrations

- [Amazon ↔ NetSuite](https://seamless.engineering/integrations/amazon-netsuite/): Amazon NetSuite integration
- [Amazon ↔ DATEV](https://seamless.engineering/integrations/amazon-datev/): Amazon DATEV integration
- [JTL ↔ DATEV](https://seamless.engineering/integrations/jtl-datev/): JTL DATEV integration
- [Shopify ↔ weclapp](https://seamless.engineering/integrations/shopify-weclapp/): Shopify weclapp integration
- [Shopware ↔ SAP Business One](https://seamless.engineering/integrations/shopware-sap-business-one/): Shopware SAP Business One integration
- [BigCommerce ↔ NetSuite](https://seamless.engineering/integrations/bigcommerce-netsuite/): BigCommerce NetSuite integration

## Browse by system

- [All JTL-Wawi integrations](https://seamless.engineering/integrations/jtl/)
- [All Amazon integrations](https://seamless.engineering/integrations/amazon/)

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact