Hey guys,

Running into a weird issue with EU FBM orders and the VCS VAT Report.

Even though we’re sending the correct Ship From address via API for each order (e.g., shipping from Italy or Spain), the VCS report just ignores it and pulls our default German address from the account settings instead.

The weird part?

Seller Central Frontend: Shows the correct API address.

Order Reports: Shows the correct "Actual Ship From" address.

VCS VAT Report: WRONG. It’s stuck on the default Germany address.

We need the VAT report to show the actual origin for tax reasons. Has anyone found a way to force the VCS report to sync with the API data, or is this just a known Amazon bug?

Cheers.

My SP-API secret key expired a couple of days ago, and I finally got around to rotating it, but now my LWA tokens - even though I am generating brand new ones - are being rejected as expired. They're supposed to expire an hour after generation, but they are already reported "expired" as soon as they try to use one that I created just moments ago.

Does anyone know if there are any current problems with SP-API?

Please ignore the tag, I had to pick one but none were suitable.

EDIT: It just started working without me doing anything, about an hour after I rotated my secret key. A timezone issue?

Hello,

As we deliver heavy and bulk furniture the delivery to offmainland is extremaly expensive. Is there any smart way to block the delivery there? I know it cannot be done thourgh amazon set ups but maybe some trick thourgh API etc?

Thank you for the follow-up, @Seller_8hQgfj6OVZYse

I appreciate the clarification regarding Amazon’s current feedback removal policy, however I do not believe the response adequately addresses the underlying issue here.

To reiterate:

We did not misrepresent inventory

We did not switch condition states intentionally

The issue was triggered solely by an SP-API operation intended to update shipping templates

Amazon has already confirmed that:

putListingsItem replaces attributes and removes omitted values

Omitting condition_type caused listings to surface as “New”

The API returned 200 ACCEPTED

No validation warning or safeguard exists to prevent this behavior

The core concern is that there were effectively no guardrails in place for what is clearly a high-risk operation affecting live offer conditions.

At no point did the API indicate:

that condition data would be removed,

that listings could default to “New”,

or that customer-facing offer states would materially change.

For sellers operating at scale, this creates a significant platform risk.

While I understand Amazon’s position regarding reimbursement policies, it is difficult to accept that:

Amazon acknowledges the root technical cause,

acknowledges there are currently no safeguards,

and yet all operational, financial, and account-health consequences remain entirely with the seller.

This was not a case of sending incorrect inventory data. The customer experience became incorrect because Amazon surfaced the wrong condition state after processing a structurally valid request with no warnings or validation failures.

I would strongly urge the internal teams to review:

clearer SP-API documentation around destructive PUT behavior,

validation/warnings when condition attributes are removed,

protections preventing used inventory from defaulting to “New”,

and whether feedback resulting directly from confirmed platform-side behavior should be treated differently.

At minimum, I hope this thread helps prevent other developers and sellers from encountering the same issue.

Thanks again.

We’ve had the exact same issue this week and now we’ve lost Prime despite many tickets opened with seller support to state there is clearly an issue Amazons API connection or a technical issue.

No communication from the seller support team, no contact from the SFP team. Just a big suspension in our peak season.