System Blacklist/Whitelist

When a user should not get any communication anymore, not even transactional, its possible to blacklist someone. The system will enforce this status.

The blacklist status will only be held for users that exist in the database. If the user gets deleted, their blacklist-status will be gone as well. This is important, if at any later time the user gets added again, Crossengage has no record of the blacklisting anymore.

Blacklist status

Every user has an Blacklist-status, which per default is “false”. It is stored in a system user-trait that is not visible in the user profile. You could only assume that a blacklist is there, if there was a failed message, which will show up like this:

How to Blacklist

There are two ways to opt out a user:

• via API endpoint (see User Management API 1.0 under “Opt-out management” → “Blacklist Endpoint“) PUT https://api.crossengage.io/users/id/blacklist-status

  { "blacklisted": true }

• via sending the system event “Blacklisted” Event “Blacklisted” POST https://api.crossengage.io/events

  { "id": "USERID", "events": [ { "event": "Blacklisted" } ] }

Both ways will have the same technical result:

• the Blacklist status will be set to “true”

• the system triggers the “Blacklisted” event (which includes the timestamp when it happened)

How to Whitelist

To remove a blacklisting, you do the same steps as for blacklisting, just set the status to “false” or use the “Whitelist”-event instead:

• API endpoint PUT https://api.crossengage.io/users/id/blacklist-status

  { "blacklisted": false }

• Event “Whitelisted” POST https://api.crossengage.io/events

  { "id": "USERID", "events": [ { "event": "Whitelisted" } ] }

Which is better?

Both ways have pros and cons.

• API endpoint

  • For using the API endpoint, the user needs to be a “full” user, because the identifier is the external Id of the user. Therefore this can’t be used for so-called “Leads”, users that only have an email address, but no external Id (e.g. Newsletter subscriber, not full customer).

  • But it is possible to request the status of a user with it (just not for a lead).

• Sending the event instead has more pros than cons

  • the event can have more properties and its possible to add more information like that (works like any other event).

  • an external Id is not necessary, because an event can be send with an email address (plus business Unit if it exists) instead.

  • it can get technically get used in segmentation, just like any other event