Inquiry: Workflow Impact Due to Deprecation of Existing APIs with the Introduction of Fulfillment Inbound API v2024-03-20

[umutyusuf]

Our workflow is significantly impacted by the updates to the Fulfillment Inbound API, specifically the deprecation of existing APIs. Currently, we provide a solution to sellers that enables them to scan each item, print a label, and immediately apply it before moving on to the next item. This process is facilitated by the createInboundShipmentPlan operation from Fulfillment Inbound API v0. By supplying a single SKU to this API, we receive the fnsku, allowing the seller to instantly print and apply the label to the scanned item. This scan-and-label workflow is crucial for many sellers we support. After all items are labeled, the seller proceeds with boxing and shipping the items to Amazon fulfillment centers, following the previous Seller Central workflow.

However, with the introduction of the new Fulfillment Inbound API v2024-03-20 and the deprecation of the createInboundShipmentPlan operation, we can no longer offer the same experience. Specifically, we are unable to obtain the fnsku necessary for sellers to print labels for scanned items in real-time. To address this, we have explored the following approaches, but none have met our requirements:

We attempted to use the putListingsItem operation from the Listings Items API v2021-08-01 and then call getListingsItem to retrieve the fnsku. However, this process takes at least an hour for the fnsku to be ready for a single item, which is not practical for our workflow.

We also tried sending feeds, such as POST_FLAT_FILE_INVLOADER_DATA (which is deprecated and will soon be removed) or the JSON_LISTINGS_FEED. Once processed, we checked for the fnsku. Unfortunately, since this approach is asynchronous and has stricter rate limitations, it is not feasible for sellers who need to scan 200 items within an hour.

Despite thoroughly reviewing the documentation, we have not found any operations that provide the fnsku before creating the listing. Are we overlooking something, or does the new API structure make it impossible to support this workflow going forward?

We would greatly appreciate your guidance in resolving this issue.

[mafge]

Hi @umutyusuf, thanks for reaching out! After calling createInboundPlan you can use listInboundPlanItems. The response should contain the fnsku for each item. Hope that helps! Best, Marc Selling Partner Developer Services

[umutyusuf]

Hi @umutyusuf, thanks for reaching out! After calling createInboundPlan you can use listInboundPlanItems. The response should contain the fnsku for each item. Hope that helps! Best, Marc Selling Partner Developer Services

@mafge Thanks for immediate response, but I think you missed the main concern I laid out in the issue. The issue is not failing to obtain fnsku eventually. I'm trying to investigate if it's possible to obtain it as the listing process goes. createInboundPlan is the final stage of the listing in our phisical workflow in terms of arranging all the items and finalizing the labeling.

[mafge]

@umutyusuf So just to clarify, you want to get the fnsku while the listing not even has been created/listing creation is ongoing?

[umutyusuf]

@umutyusuf So just to clarify, you want to get the fnsku while the listing not even has been created/listing creation is ongoing?

@mafge exactly. current workflow allows this via createInboundShipmentPlan method being invoked with a single item.

[gitsaved]

We are facing the same issue as many third-party listing services that offer "label as you list" as part of the workflow. This feature is critical for us because it ensures that the client doesn't have to handle items multiple times. Since they have the product in hand to scan the barcode while listing a new product, the ability to label it at that moment is highly desirable. Many third-party listing services have included this functionality as a core workflow enhancement for over 10 years.

With the new workflow, we can only offer label printing during the box contents phase, but there’s a complication. When we list a new SKU using the Listings API (for a product that already exists in the catalog but is new to the seller), it takes 45+ minutes for the price field to update. Until the price updates, we cannot request a shipment for that SKU or obtain the FNSKU. Although the listing becomes "discoverable" within minutes, it initially shows a price of "0.00". Despite sending the price with the initial JSON request, it typically takes around 45 minutes for the price to populate, delaying our ability to create a shipment or retrieve the FNSKU value. We've even tried sending a PATCH request to update the price after the listing becomes discoverable, but this hasn't helped.

Currently, users must scan items to create listings and then wait about an hour before proceeding to the next steps. Once we can create the shipment and obtain the FNSKU, customers have to match the labels with the products they scanned an hour earlier, which is much more difficult compared to the previous workflow.

I would appreciate any insights on how we can get the price to update faster on a new SKU so that the offer isn’t stuck in an incomplete state for so long.

[mafge]

@puppsupr Any ideas for this use case?