FBA Inbound - confirmTransportationOptions failing 100% of the time on APC LTL shipments since Friday Feb 28th - "ERROR: Something went wrong. Please try again later."

[MetaMan2023]

@puppsupr

There has been a known issue with random failures confirming APC LTL shipments that produced the following error during the "confirmTransportationOptions" (CTO) stage:

'operationProblems' => [
{
'message' => 'ERROR: Something went wrong. Please try again later.',
'severity' => 'ERROR',
'code' => 'InternalServerError'
}

This error would be random and clear -- but since Feb 28th, 100% of our attempts to ship APC LTL fail with this error (NOTE: APC UPS works no problem and we have successfully created APC LTL in the past, including Feb 25th). We have opened cases and given various "ideas/theories" of what could be wrong -- we believe we have ruled them all out. This is what we have been told and/or tested:

#1: "Transportation Options Timing Out" - There is a 20 minute time out on transportation options. We have made sure that start to finish on a plan is done well within this window. The error still occurs.

#2: "You need to set a delivery window" - Delivery windows are only required if a pre-condition flag is set, and it seems on APC LTL that this flag is never (or rarely?) set. Regardless, we have tested both setting a DW and not setting a DW and the error still occurs. (support also confirmed our transportation option did not require it). Also, when we test USE YOUR OWN CARRIER LTL, if we don't set a DW we get a very specific error message stating we must set a DW which we don't get with APC LTL.

#3: "getInboundOperationStatus is being called too quickly/often" - we have been told that if you call GIO too fast/repeatedly that it can cause random errors. We have eliminated this issue by waiting 20+ seconds after calling CTO and the error still occurs.

#4: That it could be related to certain SKUs or combinations - we have tested at least 15 combinations of SKUs including single SKUs this weekend - every single one failed at the CTO stage. We ARE able to ship via APC UPS for the same SKUs.

#5: "It was due to our contact settings in the plan/shipment" - We made sure that our contact information was identical in all steps that require it.

#6: That it has to due with a specific center or # of splits (5 splits or 1 split) - We have tested various single centers and various 5 center options, all failed with the same error.

#7: That maybe some combination of calls was confusing the system -- for example we were calling GTO on various placements within the plan to compare pricing, etc. We have avoided this issue by testing doing the limited # of calls to complete a shipment.

#8: That it has to do with a specific carrier -- we have tested many different carriers and all failed.

#9: We have tested USE YOUR OWN CARRIER - LTL as well as APC UPS and they work fine. So this is specifically related to APC LTL.

Interesting notes:

• Is there something about Fridays/Weekends? While we have had random failures on week-days, on Friday Feb 21st in the afternoon we had failures and on Monday things worked fine. Then on Friday Feb 28, we had failures in the afternoon. Coincidence or is it something related to business days of availability?

• When the CTO fails, it seems that you can't fully cancel the plan -- we can rename it but it stays in "Working" status on the Shipping Queue page.

• It seems when CTO fails, the status of the shipment is kind of mixed. Seller Central says the shipment was created, yet still has a "Create Shipment" button -- and when you click "Create Shipment", it says we have not completed the 4 required steps in the API for the process to complete. It's kind of like the CTO partially completes but then fails in the middle -- leaving the plan/shipment in semi-complete status.

• BEFORE we call CTO, we can call "generateTransportationOptions" (GTO) successfully, over and over and get updated quotes/options. However once the CTO failure happens, GTO gives a new error stating "pallet and freight info has not been provided". We are making the exact same call to GTO both before and after the CTO failure. This is the error received when calling GTO AFTER CTO fails. Basically once CTO fails it "ruins" the placement and the entire process has to be started over.

'operationProblems' => [
{
'message' => 'WARNING: Since pallet and freight info has not been provided, we may not be able to produce PCP-LTL options as part of GenerateTransportationOptions for the following shipment IDs: [sh-XXXX]',
'severity' => 'WARNING',
'code' => 'BadRequest'
},
{
'message' => 'ERROR: Sorry, something went wrong. Please try again, or refresh the page.',
'severity' => 'ERROR',
'code' => 'FBA_INB_0115'
}

Regardless of the cause, the most frustrating thing is that the error message is useless -- it provides no guidance or explanation of the problem. This issue has been reported months ago at this point and is still going on -- and seems to be getting worse.

I have also spent countless hours building complex debugging log tools so that I can provide detailed call logs to Amazon to troubleshoot... and countless hours actually running tests, which probably take 10+ minutes each of just sitting staring at a screen. I've probably sent Amazon 10-15 detailed logs of this issue at this point.

This is unacceptable, it's costing sellers significant money and needs to be resolved ASAP.

[garply1]

@MetaMan2023 have you had any luck at all with the partnered apc ltl since posting your exhaustive list of "ideas/theories". we have pallets backing up on the dock. I guess we will have to flip them to spd. ridiculous.

[MetaMan2023]

@MetaMan2023 have you had any luck at all with the partnered apc ltl since posting your exhaustive list of "ideas/theories". we have pallets backing up on the dock. I guess we will have to flip them to spd. ridiculous.

Unfortunately, no.

My contact has gone silent about 2 weeks ago -- zero communication, zero acknowledgement of the issue.

I have an open case I started back on 2/27 about these issues -- here is the most recent history:

3/1-3/3 - I sent a detailed list (similar to above) along with 4 full test logs.

3/4 - I received a response asking for the logs in a different format so they could read some data that was cut-off in the PDFs

3/7 - "I am still waiting for an update from the technical team and will update you once we hear back from them."

We performed an APC LTL test again yesterday and same failure ("Try again later").

For now we are either using APC UPS or are booking our own LTL shipments ("Use your own carrier") -- which it turns out are cheaper FYI though more of a hassle. There are shipping consolidation companies that can quote from multiple carriers. The downside is you lose the protection if something gets damaged in transit, and if there is a shipping issues you have to kind of resolve it yourself.

One other option is "Amazon Freight", not to be confused with APC LTL. It's another department in Amazon that I think uses their trucks to move freight around both for FBA and for other purposes. Currently they only do FTL, however I believe at the end of March they are rolling out LTL to everyone (we are hoping to try it then). You book with them similar to booking freight yourself.

It's pretty clear that the API team either (A) has no idea what is causing the issue or (B) knows but doesn't have the resources, or it's too complex to fix. I can't understand why they aren't just straight up with everyone. It's costing us hundreds of dollars a shipment.

It would be great if we can get more people to visually respond to this thread with anecdotes, updated testing information etc. The more people we can get discussing this the more likely it will be taken seriously. I'm actually shocked how little discussion there is on this.

[garply1]

thanks @MetaMan2023. we opened a ticket yesterday and are waiting to hear back. "amazon freight" partnered is what we want and what we are working with. i'll let you know what we find out

{
  "carrier": {
    "name": "Amazon Freight LTL",
    "alphaCode": "AMZX"
  },
  "carrierAppointment": {
    "startTime": "2025-03-21T00:00Z",
    "endTime": "2025-03-21T23:59Z"
  },
  "quote": {
    "cost": {
      "amount": 606.99,
      "code": "USD"
    },
    "expiration": "2025-03-10T14:57Z"
  },
  "preconditions": [],
  "shipmentId": "shecd69782-2c9e-49a7-8950-1e0d025d4fdx",
  "shippingMode": "FREIGHT_LTL",
  "transportationOptionId": "to51e9df3a-43f0-4908-a6e4-dc0b0ac10d63",
  "shippingSolution": "AMAZON_PARTNERED_CARRIER"
},

[MetaMan2023]

I just received an update from a contact that the API team identified a bug in a recent code rollout -- they said the bug was clearing the "available date" and they believe it was causing the APC LTL failures. I am asking for clarification on when this fix was or is being rolled out, but it sounded like it was fixed sometime in the last 24 hours.

We are going to test shortly. @garply1 maybe see if it goes through now.

[MetaMan2023]

@garply1

False alarm... problem is NOT fixed. We just had another test APC LTL shipment failure and our contact is reporting that they are communicating with other teams to find the root cause.

Issue has been going on for nearly 2 weeks now. Stay tuned.

[garply1]

@MetaMan2023 - we are still waiting for an answer on this. please let us know if you hear anything.

March 11, 2025 at 02:49:49 PM EDT
ID 17397167341
Thank you very much for providing additional information.
I reviewed the examples provided, and I was unable to identify a resolution for the error. I have contacted the API owners to get more details about the error. I will follow up with this team, and provide you with an update once I have more details.
I appreciate your patience.
Thank you for selling with Amazon

[MetaMan2023]

@garply1

Unfortunately the only update I have on this is a cryptic confusing answer from the Amazon API team. It had a lot of acronyms and seemed to blame another department for the issue... from what I can decipher from the message:

• The issue has to do with a different department or platform API that provides pricing based on the data sellers provide
• The platform is giving LTL offers when it should be providing errors (with error guidance) and this is causing the later issues
• The FBA API team does not have any interest in fixing the issue
• The FBA API team provided no guidance on what sellers can do to resolve the error -- meaning they have not said "make sure to include XXX information in your request". So I am unsure if this is something that is even fixable by sellers making a different request or providing different info.

The whole thing is so confusing, it's been going on since Feb 28th -- and the system worked before that... so something changed on Feb 28th.

I also have a separate case open where they keep saying they are working and investigating... so that is even more confusing. One group says it's being looked into, the other says basically "tough luck, not our problem and we are not going to fix it". The "tough luck" response makes no sense, as the system worked prior to Feb 28th (at least it only failed intermittently vs. 100% of the time).

Need a clear, coherent answer of what the cause is and what the resolution options are or are not.

[garply1]

@MetaMan2023 adding the "optional" freightInformation to the ShipmentTransportationConfiguration worked for us.

"freightInformation": {
"declaredValue": {
"amount": 8362,
"code": "USD"
},
"freightClass": "FC_175"
},

Here is the response from Amazon:
/*
I can confirm that we have identified the root cause of the confirmTransportationOptions failure. The issue occurs because the system requires both Pallets and Freight information for LTL options. While your request included pallet information, it was missing the freight details, which caused the system to encounter a null pointer exception when attempting to process the ship date value during confirmation.

Our development team has created a task to address this issue. In the meantime, to successfully process your LTL transportation options, you will need to include both Pallet and Freight information in your GenerateTransportationOption API call.
*/

@MetaMan2023 - thanks for staying active. it helps when we post our issues and results

[MetaMan2023]

@MetaMan2023 adding the "optional" freightInformation to the ShipmentTransportationConfiguration worked for us.

"freightInformation": { "declaredValue": { "amount": 8362, "code": "USD" }, "freightClass": "FC_175" },

Here is the response from Amazon: /* I can confirm that we have identified the root cause of the confirmTransportationOptions failure. The issue occurs because the system requires both Pallets and Freight information for LTL options. While your request included pallet information, it was missing the freight details, which caused the system to encounter a null pointer exception when attempting to process the ship date value during confirmation.

Our development team has created a task to address this issue. In the meantime, to successfully process your LTL transportation options, you will need to include both Pallet and Freight information in your GenerateTransportationOption API call. */

@MetaMan2023 - thanks for staying active. it helps when we post our issues and results

Interesting -- did you test just providing "amount" or "freight class" by itself (vs. both) and did it work with just one or the other?

Another question: Have we ever been required to enter freight class or declared amount when using only the Seller Central interface or did Amazon just calculate it using internal data? Our use of APC LTL was limited in the past when we used the Seller Central interface so I cannot remember.

-John

[garply1]

@MetaMan2023 - we had to pause our LTL testing. The LTL truck driver is showing up to get these shipments (prior testing 2-3 weeks ago) even though the order and shipping charges have been cancelled. We have used cancelInboundPlan and seller central. Seller central shows the order has been cancelled. It is not cancelled and its a PIA to get reimbursed. I'll let you know

[HaHaVip123]

Recently, confirming TransportationOptions has been frequently called ERROR: Sorry, something went wrong. Please try again, or refresh the page

[garply1]

Adding FreightInformation with freightClass only works. We leave declaredValue null

[HaHaVip123]

这是来自QQ邮箱的假期自动回复邮件。   您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。