Missing Equivalents for TrackingId and TransportStatus in Fulfillment Inbound API v2024-03-20

[serjae]

Hi

We’re migrating our integrations to the Fulfillment Inbound API v2024-03-20 due to the deprecation of the getTransportDetails operation in version v0. However, we’ve encountered challenges replacing the TrackingId and TransportStatus fields, previously obtained via getTransportDetails.

• TrackingId:
  The documentation suggests this data is now available through the listTransportationOptions or listDeliveryWindowOptions operations. However, after testing and further investigation, we found that the field is only referenced in the getShipment operation under the optional trackingDetails section, which is always returned empty in our tests.

• TransportStatus:
  We haven’t found any equivalent field or data point in the new API to replace this functionality.

Have you found reliable replacements or workarounds for these fields in the new API?

Thanks in advance!

[puppsupr]

Hi,
As you mentioned, you need to call the getShipment. Are you checking this after confirm Transportation ?

[serjae]

Thank you for your response.

I will look into the confirmTransportation issue, but what stands out is that in API v0, the TrackingId was available in this same case, while in the new API v2024-03-20, the data is not included, even after calling getShipment.

Thanks again for any additional insights.

[puppsupr]

Hi @serjae,
The putTransportDetails is replaced with generateTransportationOptions,
generateDeliveryWindowOptions. You don't require a TrackindId in v2024. You can look into the tracking details and status using the getShipment.

Please look into the Postman collections to look at the required requests/responses and flows. Here is the full documentation for migration and sample tutorials.

Please review and let me know if you have further questions.

[serjae]

Hi,

Thank you for your response.

I have an application that generates reports, and one of the data points I need to obtain is the TrackingId, which I used to get through the getTransportDetails operation in API v0, which is soon to be deprecated.

In the new version v2024-03-20, as we discussed, we know that this data can sometimes be retrieved via the getShipment operation. However, in our tests, we don’t always get the TrackingId in the response. This inconsistent behavior is a problem for us, as we need this data for report generation and cannot use PUT or POST operations that perform modifications; we can only use GET operations.

Therefore, I would like to better understand the logic behind this behavior, why is the TrackingId sometimes available and sometimes not? In the old API v0, we always received it consistently, so we need to find a reliable way to obtain this data in the new version.

One assumption I have is that perhaps workflows initiated with the v0 API don’t provide this value, while those using the v2024-03-20 API do, but this is just a hypothesis.

I would appreciate any further guidance on how we can obtain this data consistently and reliably.

Thanks again for your help.

[puppsupr]

Hi,
You get the tracking ID associated with each box in a non-Amazon partnered Small Parcel Delivery (SPD).

In v0, putTransportDetails requires shipment tracking numbers using TrackingId (small parcel) and PRO number (LTL). In v2024-03-20, updateShipmentTrackingDetails requires shipment ID and tracking details for LTL or small parcel shipments.