FBA Inbound v2024-03-20: how to get USE_YOUR_OWN_CARRIER + FREIGHT_LTL for ALL shipments of a multi-FC placement (confirmTransportationOptions needs one carrier for all)?

[zzxxj216]

Using Fulfillment Inbound v2024-03-20 with self-delivery (USE_YOUR_OWN_CARRIER), FREIGHT_LTL, on a placement split across multiple FCs (e.g. 5 shipments). I'm hitting a chain of constraints with no documented way through:

1. generateTransportationOptions must include configs for ALL shipments of the placement (a single-shipment config → "shipment configuration is not provided for all the shipments of the placement option").
2. listTransportationOptions filtered by placementOptionId only returns the FIRST shipment's options (page is full, no nextToken). I must query per shipmentId (pageSize<=20) to see each shipment's options.
3. confirmTransportationOptions must include ALL shipments in one call (a per-shipment subset → "Provided shipment ids [...] do not match the shipments in the confirmed placement option").
4. All selected options in that one confirm call must use the SAME carrier, else: FBA_INB_0354 "Requested transportation options do not have the same carrier as confirmed options".

The problem: each generateTransportationOptions call returns a DIFFERENT, seemingly random subset of USE_YOUR_OWN_CARRIER carriers per shipment. The generic "OTHER" carrier (alphaCode empty / name "Other") appears only intermittently, and for some FCs only under GROUND_SMALL_PARCEL, not FREIGHT_LTL. There is often NO single carrier (named or OTHER) common to all shipments in a given generate. transportationOptionId also changes every generate, so I can't accumulate a per-shipment choice across calls.

My current workaround: re-call generateTransportationOptions repeatedly (up to ~30x) until one response happens to offer OTHER+FREIGHT_LTL for ALL shipments simultaneously, then confirm them together. This works but is slow/fragile.

Questions:

• Is there a supported way to force/select a specific shippingSolution+shippingMode (e.g. USE_YOUR_OWN_CARRIER / FREIGHT_LTL / OTHER) so all shipments get a consistent option in a single generate? (related: Feature request: Allow shippingMode and shippingSolution filters in generateTransportationOptions in FBA Inbound API v2024-03-20 #4426)
• Is confirmTransportationOptions intended to require one carrier across all shipments of a placement, or can shipments use different carriers?
• Is repeated generate-and-resample the intended approach, or is there a deterministic path? (related empty-results report: FulFillment Inbound v20240320 listTransportationOptions always returns none #4862 ; APC-LTL confirm failures: FBA Inbound - confirmTransportationOptions failing 100% of the time on APC LTL shipments since Friday Feb 28th - "ERROR: Something went wrong. Please try again later." #4656)

Region: NA (US). Thanks!

[spiohq]

There's no filter for it. The generateTransportationOptions request body only takes placementOptionId and shipmentTransportationConfigurations, and a configuration is just contact info, freight info and pallets, nothing that lets you constrain the carrier or mode that comes back. That's exactly what #4426 (the one you linked) is asking for and it's still open, so generate the whole set and pick is the only path right now. One thing from that thread worth knowing: a lot of the carriers you get back don't actually operate at the destination warehouse (rosh3000 noticed loads of CN/US/DE carriers showing up for a UK FC), since only carriers that can book a slot there are really usable. That probably feeds into why OTHER shows up so inconsistently for you.

On the same-carrier thing, the documented behavior might actually be on your side and contradict the FBA_INB_0354 you're getting. Over in #4464 someone relayed Amazon's rule from a support case: for non-partnered LTL, different carriers across shipments are supposed to be allowed, only partnered LTL has to be consistent, and SPD always has to match. That's the opposite of what the reporter there hit. Their confirm only went through once they forced everything onto one carrier (UPS FREIGHT). So either the rule and the implementation disagree or there are caveats Amazon never published. Might be worth quoting that #4464 support response in your own case to force the question.

The multiple Other carriers aren't just you either. #5076 reports the same thing, several "name": "Other" entries with no alphaCode in one listTransportationOptions response and no obvious way to tell which to confirm. Also unanswered.

One concrete thing on the resample loop. If you're firing the generate calls in parallel across placement options, don't. In #4541 someone reproduced it reliably: back-to-back generateTransportationOptions calls on the same plan before the prior ones finish make the earlier ones fail with the generic "something went wrong", and once that happens you start getting the "pallet and freight info has not been provided" warning on the retry even when nothing changed in the request. Running them strictly sequential, one operation fully resolved before starting the next, was the only thing that stopped it for them. If your 30x loop overlaps at all that could be inflating your failure rate on top of the resampling itself.

I haven't found a documented deterministic path anywhere, so your read looks right that resample-until-aligned is the de facto approach rather than an intended one. Honestly the most useful move is probably pushing on #4426 and getting Amazon to reconcile that #4464 support statement with the actual FBA_INB_0354 behavior, since that contradiction is the root of the whole carrier alignment mess.

[zzxxj216]

Thanks — this is exactly the map of the minefield I needed.

A few data points back, in case they help others:

Resample-until-aligned does work, with strictly sequential calls. Waiting for each generateTransportationOptions operation to fully resolve before the next: a 2-shipment placement usually aligns OTHER+FREIGHT_LTL within 2–5 generates; a 5-shipment placement took us 12 generates; a 10-shipment placement never aligned (~70 generates before we gave up and switched to a 2-FC placement). Per-shipment, OTHER+LTL shows up in roughly 50–80% of generates, so alignment probability decays fast with shipment count.

Can confirm the #4541 behavior. We hit the "pallet and freight info has not been provided" warning exactly after overlapping operations on the same plan (a diagnostic script running alongside a submission, plus a killed mid-flight operation). Since enforcing one in-flight operation per plan, no more generic failures.

On the carrier-consistency contradiction: we'll open a support case quoting the #4464 support statement (non-partnered LTL supposedly allows per-shipment carriers) against the FBA_INB_0354 we observed, and report back here.

Upvoted #4426.

[AlexTavarian]

Hello, following up on #4464 , did you ever get a reply from Amazon support? I am running into the same problem here.

Thank you.

[zzxxj216]

I haven't received any official reply so far, but for now, most people are using the shared-warehouse model, picking fewer warehouses, and combining it with sampling to complete my tasks.