I know that through the REST API you can mark a contact as opt-in by setting ‘opt_in_reason’ then calling the PUT for /contacts. When I do however, I cannot ‘remove’ the opt-in afterward (nor can I receive the existing opt_in_reason after it has been set by calling GET contacts, as it’s never filled in). This is a problem as my users on my website can check/uncheck the option to subscribe to updates, but the unchecking doesn’t work since the REST API doesn’t remove (or even pass out) the opt_in_reason.
On top of that, I’m seeing two properties in JSON that are not documented in REST (GET: /contacts):
“email_status”:“SingleOptIn”
“email_opted_in”:true
Neither of these fields accept data being sent beyond the values they have applied to them. Being undocumented I’m not sure if these are just leaking out or the documentation is just out of date.
tldr; I need to be able to both optin and optout for customers via the REST API and it appears to not be functioning as intended atm.
Hi @paul_mcdowell, there currently isn’t a way to opt-out email addresses via REST. However, there is APIEmailService.optOut which exists in the XML-RPC API and should give you what you’re looking for.
Thanks for pointing out those fields that are missing from the documentation. They are supported read-only fields that are intentionally being included in the responses. I will look into why they aren’t appearing in our documentation.
Thank you @Nicholas_Trecina , I appreciate the heads up about the XML-RPC endpoint. I’m concerned about directing resources to the RPC endpoints however as I’m under the impression that those are going to be phased out. Being a small team and a startup the additional time to add XML-RPC support is non-trivial, especially when that work may quickly become deprecated.
It would be very useful if we could simply pass email_opted_in: false as part of the call to support that. I’d like to nominate that as the functional support for REST if possible, as it was the one idea everyone on my team felt was intuitive.
If you use OAuth then you can use the same credentials for the RPC as you do for REST. What will be sunsetted is the api key method. The API will still be available.