Open zmzwenzelh opened 1 year ago
Thank you for bringing this concern to our attention. Our technical team is looking into it and will provide a more substantive response shortly.
This is confirmed as a production defect and will follow the process to address it. Thanks again for bring this to our attention.
I'd appreciate if you updated us here once issue is resolved. BTW, the same problem applies to other messages, e.g. 128400, but I assume you figured that out yourself.
cheers.
Definitely! And appreciate your patience.
Your process to address this confirmed production defect is a little bit stretching my patience. Is there any news about it?
Would also really love an update on this @chuntoulee
Hi, thank you for your comments. The Rate API has been updated to replace the variables.
unfortunately it still dos not work. just this moment had another such case
-- in the old SOAP API I might add --
since we moved to the REST API meanwhile I do unfortunately have to confirm and restate that the error still persists, even in the REST API. Please dear UPS devs, give it a chance and repair it, it might not be relevant in your main market US but it very much is in Europe.
Hi, thank you for your comment. Just to check, have you experienced this behavior recently while using the RESTful Rate API?
HI UPSRahul,
yes. Recently (sept 4) with the RESTful API
Request fragment(anonymized)
"ShipTo":{"Name":"XXXX","AttentionName":".","Phone":{"Number":"XXXX"},"Address":{"AddressLine":[". ","XXX"],"City":"ADEJE","PostalCode":"38670","CountryCode":"ES"}}
Response: {"response":{"errors":[{"code":"128400","message":"The destination postal code dest.postal is not a valid dest.country postal code. Verify your postal code or select dest.AdjCountry as your destination country or territory."}]}}
for clarification, the fragments above are from shipping API
Hi,
it seems to me that in rating API error message 118400 as well as in the same message in Shipping API 128400 there is a new bug inttroduced a few months ago. It kind of made it's way even to the documentation
The variables %xyz% are not replaced by meaningful information but appear explicit as such.
For us it would be important to restore the correct behaviour since, e.g., we use the information in %dest.AdjCountry% to correct an earlier request for a destination region we couldn't identify in the first place.
Thx for your suggestions.