question

www_strumpfshop_de avatar image
0 Likes"
www_strumpfshop_de asked ·

[2 Bugs] The FulfillmentAPI occasionally does return inconsistent data (compared to the webfrontend)

In our case roughly 10 from 500 (2%) orders (from the last 90 days) are inconsistent between the data the api does provide and the data the webfrontend ( https://www.ebay.de/sh/ord) does show. **Bug1:** **What happens:** The webfrontend ( https://www.ebay.de/sh/ord/?filter=status:AWAITING_SHIPMENT) does not show any orders (at least not any that is older then a week). The fulfillmentAPI (getOrders from last 90 days) returns some orders, that are (for example) OLDER then a month and have following properties: a) orderPaymentStatus = PAID and b) orderFulfillmentStatus = NOT_STARTED and c) cancelStatus->cancelState = NONE_REQUESTED If you search for the specific orders in the webfrontend, they are listed as PAID+SHIPPED. And indeed, this specific orders were already shipped long time ago (immediatly after they were paid) and the feedbacks (seller + customer) for the finished orders were (partially) already created. **What should happen:** An already shipped order (according to the webfrontend) should not be returned with orderFulfillmentStatus = NOT_STARTED (via fulfillmentApi, getOrders). **Bug2:** **What happens:** If you try to createShippingFulfillment for the orders described above, you get a valid response (statuscode 201: created), but the orderFulfillmentStatus from this order remains the same: NOT_STARTED For some reason, the shippedDate does change(!!!) (even though the orderFulfillmentStatus remains NOT_STARTED). Also the response of this api call returns a location (in header) aca Web Service URI with the fulfillmentId 999. However, if you try to call the request (getShippingFulfillment), you receive: status 400: Bad Request { "errors": [ { "errorId": 32110, "domain": "API_FULFILLMENT", "category": "REQUEST", "message": "Invalid Shipping Fulfillment Id: '999'", "parameters": [ { "name": "shippingFulfillmentId", "value": "999" } ] } ] } **What should happen:** In the first place (as suggested above), the already shipped order (according to the webfrontend) should not be returned with orderFulfillmentStatus = NOT_STARTED (via fulfillmentApi, getOrders). If you succesfully create a shipppingFulfillment (createShippingFulfillment) for an order (with status 201: created), the orderFulfillmentStatus of the order should no longer be NOT_STARTED, but rather IN_PROGRESS. If the order was already shipped (according to te webfrontend), you should no longer be allowed to createShippingFulfillment for this order. Also the api-call (getShippingFulfillment) with the provided location from the previous request (createShippingFulfillment) should be valid. **Questions:** Are those bugs already known? Is there a way to identify an already shipped order (according to the webfrontend), that is wrongly returned with orderFulfillmentStatus=NOT_STARTED from the api? **Additional info:** Our production DevID: fe1b4fb1-558f-41f2-899b-50d790ae508b Examples for inconsistent orders: orderId: 142651513388-1496594402004!180000125165984 location: https://api.ebay.com/sell/fulfillment/v1/order/142651513388-1496594402004!180000125165984/shipping_fulfillment/999 RlogId: t6pithqauq%60%3F%3Ckuvukqjtcpse*2052241%29pqtfwpu%29osu%29fgg%7E-fij-1621eba0325-0x1e631 orderId: 142621758495-1483265445004!160000108729825 location: https://api.ebay.com/sell/fulfillment/v1/order/142621758495-1483265445004!160000108729825/shipping_fulfillment/999 RlogId: t6pithqauq%60%3F%3Ctofukqjtcpse*277572%3E%29pqtfwpu%29pie%29fgg%7E-fij-1621eb967e2-0xc0 King regards strumpfshop
fulfillment apibug reportinconsistent data
10 |600 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

0 Answers

· Write an Answer

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.