We have found a bug in the Checkout/Order API relating to setting the `buyer_accepts_marketing` field when using the REST Admin API.
It seems that if you have placed an order using the Checkout API, and then update the `buyer_accepts_marketing` field on the Order object, that this will not update the status of the `Customer.accepts_marketing` field as expected.
If you set the `buyer_accepts_marketing` field while the Checkout is active and the order has not yet been placed, this will correctly update the `Customer.accepts_marketing` field.
It seems misleading and pointless to be allowed to update the `buyer_accepts_marketing` field in the Order API, if it doesn't actually influence the related customer field.
We notice that once the checkout has been converted into an order, the `buyer_accepts_marketing` field is now not visible on the checkout object when you do a get, and is not living on the order object.
You cannot update the field on the checkout object after the order has been placed.
This is clearly a bug, or an unintended feature of the Checkout/Order API, which is not documented anywhere in the REST Admin API.
Please can this be looked into and resolved, as ideally, you should be able to state whether the user has accepted marketing emails after the fact.
In our use case, we want to ensure the order has been placed successfully before setting this field, as it would be irritating to spam users if they weren't actually able to buy anything from a checkout, because it failed.
Hey @JamesGilmore - thanks for getting in touch, I really appreciate the concise and thoughtful breakdown for the `buyer_accepts_marketing` field issue you shared here. We've been in touch with a few other developers who have mentioned that they are encountering similar issues with checkout-related marketing consent.
I can share that our developers have pushed a fix for this that will allow this field to be updated correctly through the order endpoint in REST. You're totally correct that there appeared to be a disconnect between the `customer.accepts_marketing` and 'buyer_accepts_marketing' fields that should now be resolved. Can you let us know if you're still seeing the issue, and if so, share an X-Request-ID with us so we can look into this further? I can get in touch with my colleagues and dig deeper into this if need be.
Thanks again for getting in touch - happy to help further if you need us.
Hey @Alan, thanks very much for the quick response to this, we really appreciate that and how quickly you managed to issue a fix as well.
Sadly though, after thorough testing, it doesn't appear the fix has resolved the issue.
For our latest run - with the X-Request-ID for the PUT call to update the `buyer_accepts_marketing` field on the Order object.
Just for a bit of sanity checking really, on a separate test, I've also set the `buyer_accepts_marketing` flag to True on the Checkout object right before paying for the order, which does successfully set the Customer.accepts_marketing to True. But still doesn't work if we do this on the Order object.
Please let me know if you need any more information to help resolve this.
Hey James - thanks for getting back in touch. That does seem odd that the issue is still persisting. We rotate monitoring of our community forums, so I'm not always available to reach back out. I wanted to check in to see if you're still experiencing the issue? If so, could you reach out through our Report an Issue form when logged into your partner account?
If you could include an X-Request-ID from within the last 10-14 days in that form, that would be great and we'd be able to continue a conversation over email. This may make us able to keep in touch more consistently.
Hope to hear from you soon - we'll help get this looked into/fixed.
Hey Alan, thanks for getting back to me. That's good to know about the rotating monitoring going on, just for ease of mind.
I've re-ran my tests now, and can confirm this is still an issue. I've used the Report an Issue form now and have included the X-Request-ID from all my test runs from today (Ticket #31803401).
Look forward to hearing from you over email soon. Thanks again.