All very valid points you raise here!
Also curious how others are handling this and Braze's perspective here. Nirnay, have you tried submitting a support ticket with this information?
Also curious what your goal is here. Are you trying to maintain a separate list or a separate database that has accurate spam status information for all users?
Hey AllanHeoFNM , thanks for engaging on this!
To answer your question on the goal: the driver is a practical support workflow. When a user stops receiving emails and contacts our customer support team, the agent needs to quickly determine whether that user is spam-blocked or hard bounced, and resolve it without pulling in a developer.
Hard bounces are actually straightforward. Braze provides an API for that, so querying and removing users from the bounce list is simple enough. The real pain point is spam status, which is what prompted me to post here. There's no equivalent current-state API, which forces us down the Currents path with all the complexity I outlined above.
I did raise a support ticket with Braze, but the response was essentially that there's no better native solution beyond what we're already working with i.e., raw event streams via Currents.
I posted here specifically hoping someone in the community has found a cleaner approach to this, whether that's a pattern we haven't considered, a workaround. Would love to hear how others are tackling it.
What you can do is create a segment of users who have marked you as spam and use the segment API to pull that list, then you and query to see if they user is marked as spam (at least up to the point you last pulled the list).
Not perfect, but it should server your purpose.
Hi TedScott. Thanks for responding.
I ended up doing something similar over the last couple of days, integrated GCS with a new export bucket, automated a daily job to call /users/export/segment, and set up a Cloud Run Function to allow our external APIs to read directly from BigQuery.
Braze could have made this a lot simpler with a straightforward pull API. Not entirely sure what the constraints are on their end, but the current setup feels like more overhead than it should be.
