When creating a new carrier_service, if you set active:false, you get a 201 Created response along with a carrier_service body. If you take that carrier_service id and attempt a GET, it results in a 404.
Similarly, if you create an active carrier_service, then update to active:false using a PUT request, you get a 200 response with the active:false clearly indicated, but if you try a subsequent GET, you'll get a 404.
From the Merchant perspective, under shipping & delivery >> manage rates, you'll see that for the deactivation calls, a "Carrier and rate app" remains in place, thereby replicating rows with what appears to be a max of 6 instances. If we explicitly DELETE the service instead of updating to active:false, we can see the row being removed as expected.
Why can't we see the carrier_services with active:false? We want to be able to set a given instance to be inactive, and then reactivate it at a later time without the Merchant having to either clean up orphaned rate entries or, more importantly, re-configure any custom rate adjustments that had applied to the initial app rate entry. Is this expected behavior?
Thanks for bringing this to our attention, this is not expected behaviour and I have created an issue with the appropriate team. I don't have a timeline for a fix but will follow-up when I know more.
Connect your PayPal account to allow your customers to checkout using the PayPal gateway a...By Ollie Jul 28, 2022