New FBA Inbound API v2024-03-20 - Why is the new API so painfully slow, and any plans to speed it up?

[MetaMan2023]

We are trying to implement the new inbound API -- it's a struggle... the old API v0 requires maybe a handful of calls at most. With I believe one or two calls you can create a shipment enough so you can complete in Seller Central (using Convert to STA).

The new FBA Inbound API, in comparison, requires I estimate 20-30 calls to complete a shipment (when you take into account the operation status checks). It is PAINFUL to operate. Just to get to Step #3 takes 1.5 to 2 minutes of waiting... and waiting... and waiting. It makes debugging and testing extremely difficult -- and when the issue is on Amazon's side (for example last evening the API started getting random failures), it makes it very hard to determine what is going on as every code tweak takes such a long amount of time to re-test.

Are there any plans to speed it up? If so what is the timeline.

[puppsupr]

Thank you for your feedback. Amazon recognizes the challenges in latency. Efforts are already underway to optimize response times and streamline workflows. These improvements are prioritized, and updates will be shared as they progress.

[MetaMan2023]

@puppsupr

Thank you for for responding. It's great to hear that is on the plan

In a large operation, the latency on the new API (3-5 minutes) makes it very hard to manage, troubleshoot as well as get all available information to determine the most cost effective option. It seems the biggest struggle are the post calls that require status checks -- the status checks typically take 15-30 seconds. Also when certain sections of our UI require multiple call steps, it's hard to tell whether something is "stuck" vs. Amazon is just having an internal delay.

[MetaMan2023]

@puppsupr

Just some feedback on speed -- we were running some internal tests of our new system today and the system seems to be operating slower today than in our prior tests a few days ago. We were trying to get Transportation options and delivery windows on a single placement options that was going to 5 centers.

Our process is to get a list of the 5 shipments, then request the transportation and delivery window options for all 5.

It took an extremely long time today to just do one placement options to 5 centers/shipments... I would say about 5 minutes.

There were like 5 other placement options as well -- which we were not pulling this information for.

Is it possible the system is getting slower now that more people are using the new system after the 20th? The extended time makes it extremely hard to test or use effectively.

[MetaMan2023]

Wondering if anyone else can supply data from their tests -- this is new timing data since Dec 20th:

This was on Dec 27th, around 1:30 PM EST

All times are approximate based on a few runs, This is for a single SKU shipment

• Generating initial plan = approximately 1 minute
• Generate placement options for plan = about 1.5 minutes (one run 1:20, one run 1:50)
• Generate Transport for the 5 centers placement option = 4:10
• Generate Transport for the 2 center placement opinion = 1:45
• Generate Transport for the 1 center placement option = 1:10

It seems roughly 50 seconds per "Shipment" to generate transport+delivery window options.

So if you assume that to get the appropriate full costs and make a decision, you need to generate transport options for 5 + 2 + 1 = 8 shipments, that's over 6.5 minutes + 1 min to generate plan + 1.5 mins for the placement options. NOTE: We need to generate transport options for at least one of each shipment center split QTY (5/2/1) so we can make sure we are getting the best price.

Then you have to confirm the placement and transport -- we are approaching 10 minutes of waiting time start to finish to generate a shipment using the new API for a single SKU -- that's with no time to modify the plan (if we decide to add some items) which means we have to re-run the above. It also does not include time to generate transport options for all of the placement options that are provided by Amazon (though in reality those would not be cost effective in most situations as those centers are further away.

Pre December 20th, while it was still very slow it did seem to take less time. Also concerning this is for a single SKU shipment. Will it get slower for larger # of SKUs?

[JimMcKenzieSmith]

When you say "Generating initial plan = approximately 1 minute", just to be clear, you are talking about the createInboundPlan api operation? Correct?

[MetaMan2023]

@JimMcKenzieSmith

Sorry I should have been more descriptive -- I was discussing general "sections" of creating a shipment.

For the first part I defined as "Generating initial plan = approximately 1 minute" this includes:

• createInboundPlan
• generatePackingOptions
• listPackingOptions along with "listPackingGroupItems"

This above is a minimum I believe of 4 main calls + all of the calls to check the operation status... it runs about a minute. If there are many packing options/groups it can take longer.

Basically everything you need to do to get to the point where you would do the next big step, generatePlacementOptions.

[JimMcKenzieSmith]

FWIW, we have not seen those three operations take a full minute. So, I'm not sure why you'd be seeing that. I would say, maybe 15-20 seconds. You might be doing higher quantity than us, so maybe that's the difference? Maybe test it with low quantity. Or, maybe you are getting throttled? Maybe your IP is throttled?

As for generate placement options and generate transport, unfortunately we're not there yet.

I've had a ticket open with Amazon regarding an internal server error on the SetPackingInformation for almost 3 weeks now, with no resolution in sight. We have not been able to ship items for one of our clients. The UI is even broken. We cannot get shipping labels. I've heard/seen a few others with internal server errors. So my guess is that their engineering backlog is overwhelmed with bugs/issues related to FBA Inbound API v2024-03-20. They will triage internal server errors above performance issues, as an educated guess.

[MetaMan2023]

We did see some random errors around the time the API "launched" (ie: the original deadline day) and have seen the API take a long time. We are doing very small shipments so I'm not sure why... Out of curiosity what formula are you using to wait for status -- for example if you make a call and then request status of the call.... you have to keep re-calling until it is done. We are waiting like 8 seconds after the call and then 4 seconds after that over and over... we had tried smaller amounts but it seemed no matter what we did, it would take over 8 seconds. Maybe it's faster now actually and I might have to test lower amounts.

…

On Thu, Jan 9, 2025 at 9:32 PM Jim Smith ***@***.***> wrote: FWIW, we have not seen those three operations take a full minute. So, I'm not sure why you'd be seeing that. I would say, maybe 15-20 seconds. You might be doing higher quantity than us, so maybe that's the difference? Maybe test it with low quantity. Or, maybe you are getting throttled? Maybe your IP is throttled? As for generate placement options and generate transport, unfortunately we're not there yet. I've had a ticket open with Amazon regarding an internal server error on the SetPackingInformation for almost 3 weeks now, with no resolution in sight. We have not been able to ship items for one of our clients. The UI is even broken. We cannot get shipping labels. I've heard/seen a few others with internal server errors. So my guess is that their engineering backlog is overwhelmed with bugs/issues related to FBA Inbound API v2024-03-20. They will triage internal server errors above performance issues, as an educated guess. — Reply to this email directly, view it on GitHub <#4396 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBYBSIVJULXBK63FYAHM2PT2J4WNLAVCNFSM6AAAAABTGQMFYWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNZZGMYTOMI> . You are receiving this because you authored the thread.Message ID: <amzn/selling-partner-api-models/repo-discussions/4396/comments/11793171@ github.com>

[MetaMan2023]

Actually correction -- so just the "createInboundPlan" for a single SKU: * I make the call and wait 4 seconds, check status * Status incomplete, i wait 2 seconds * Status incomplete, i wait 4 seconds * Status complete It's 10 seconds +/- just for the createInboundPlan call I did go back and change my timing requests for generatePackingOptions and I was able to get the status to clear on that in 1 second -- so I just saved like 8 seconds off my time... so that's helpful. I have re-run tests though over and over -- the times seem to vary wildly depending on when I call even with one SKU. So frustrating.

…

On Thu, Jan 9, 2025 at 9:59 PM John Babina III ***@***.***> wrote: We did see some random errors around the time the API "launched" (ie: the original deadline day) and have seen the API take a long time. We are doing very small shipments so I'm not sure why... Out of curiosity what formula are you using to wait for status -- for example if you make a call and then request status of the call.... you have to keep re-calling until it is done. We are waiting like 8 seconds after the call and then 4 seconds after that over and over... we had tried smaller amounts but it seemed no matter what we did, it would take over 8 seconds. Maybe it's faster now actually and I might have to test lower amounts. On Thu, Jan 9, 2025 at 9:32 PM Jim Smith ***@***.***> wrote: > FWIW, we have not seen those three operations take a full minute. So, I'm > not sure why you'd be seeing that. I would say, maybe 15-20 seconds. You > might be doing higher quantity than us, so maybe that's the difference? > Maybe test it with low quantity. Or, maybe you are getting throttled? Maybe > your IP is throttled? > > As for generate placement options and generate transport, unfortunately > we're not there yet. > > I've had a ticket open with Amazon regarding an internal server error on > the SetPackingInformation for almost 3 weeks now, with no resolution in > sight. We have not been able to ship items for one of our clients. The UI > is even broken. We cannot get shipping labels. I've heard/seen a few others > with internal server errors. So my guess is that their engineering backlog > is overwhelmed with bugs/issues related to FBA Inbound API v2024-03-20. > They will triage internal server errors above performance issues, as an > educated guess. > > — > Reply to this email directly, view it on GitHub > <#4396 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BBYBSIVJULXBK63FYAHM2PT2J4WNLAVCNFSM6AAAAABTGQMFYWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNZZGMYTOMI> > . > You are receiving this because you authored the thread.Message ID: > <amzn/selling-partner-api-models/repo-discussions/4396/comments/11793171@ > github.com> >

[marvinpaul95]

I’d like to echo the concerns raised here regarding the increased runtimes. We’ve experienced a significant jump in response times - from around 20 seconds with V0 to over 2 minutes with V2024-03-20 (single SKU).

This dramatic slowdown has made real-time processing during the packing process virtually impossible. Given the volume of shipments we handle daily, this sixfold (or more) increase in runtime means we now face the need to hire an additional employee just to account for the added wait times.

I kindly ask if Amazon can provide an update or solution to address these performance issues, as they are having a substantial impact on our operations.

Thank you.

[MetaMan2023]

I’d like to echo the concerns raised here regarding the increased runtimes. We’ve experienced a significant jump in response times - from around 20 seconds with V0 to over 2 minutes with V2024-03-20 (single SKU).

This dramatic slowdown has made real-time processing during the packing process virtually impossible. Given the volume of shipments we handle daily, this sixfold (or more) increase in runtime means we now face the need to hire an additional employee just to account for the added wait times.

I kindly ask if Amazon can provide an update or solution to address these performance issues, as they are having a substantial impact on our operations.

Thank you.

Agreed -- this time issue is significant, especially given there are so many glitches with the new system and/or poor error handling.

Debugging in this new API is SO SLOW -- I feel as if the life is being drained from me.

As an example, there are multiple existing APC LTL issues -- one acknowledged by Amazon (in the "Issues" section of GitHub).

Trying to test and trouble shoot takes forever... I make one minor change to test if that solves the problem and I have to wait like 5 minutes to generate this over and over again.

Other odd design choices -- Amazon generates a list of like 100+ transportation options for shipments but the maximum size you can request at once is only 20 (and it defaults to 10) -- so to get 100 transportation options takes at least 5 calls to "listTransportationOptions". Then similar for delivery windows -- now do this for like 5 shipments.

5 shipments x 5 calls to list transportation option = 25 calls
5 shipments x 3 calls to list delivery options = 15 calls

That's FORTY CALLS to Amazon just to get a full list of transportation & delivery windows for a shipment plan. Why is the request page size only 20? There is no filter, so you can't limit the results -- so we need to get 100% of the options. We should be able to make one or two calls at most per shipment (one to listTransportationOptions and one to listDeliveryOptions -- or preferably one call to get both at once in a combined result).

When you add in the generate and status checks -- your looking at like 60 calls to Amazon API just for transportation... and then those are throttled so you have to delay.