A valid request URL is required to generate request examples{
"preferences": [
{
"category": "<string>",
"label": "<string>",
"opted_out": true
}
]
}{
"error": {
"code": "forbidden",
"message": "your role does not allow this action"
}
}{
"error": {
"code": "forbidden",
"message": "your role does not allow this action"
}
}{
"error": {
"code": "forbidden",
"message": "your role does not allow this action"
}
}Change my notification preferences
Switches one or more categories off, or back on. Partial: a category left out of the body is left alone.
A category this API does not know is refused by name with 400 rather than ignored, transactional included — a consent decision dropped in silence is a screen that says “saved” over a preference that was never stored, and the person finds out from the next email.
An opt-out publishes contact.notification_opt_out on the internal bus. It is not delivered to your webhooks, and that is the one entry in the catalogue whose reason is about direction rather than permissions: what anybody would build on “this person unsubscribed” is a message from their own system, which is the one message the fact says must not be sent. The preference is on the contact’s record instead, where the audience that mails them reads it.
A valid request URL is required to generate request examples{
"preferences": [
{
"category": "<string>",
"label": "<string>",
"opted_out": true
}
]
}{
"error": {
"code": "forbidden",
"message": "your role does not allow this action"
}
}{
"error": {
"code": "forbidden",
"message": "your role does not allow this action"
}
}{
"error": {
"code": "forbidden",
"message": "your role does not allow this action"
}
}Authorizations
A contact session token, uk_ct_…. Belongs to one of the developer's own users, and reads only that user's data.
Body
1Show child attributes
Show child attributes
Response
The full catalogue again, as it now stands.
Show child attributes
Show child attributes