Challenges with Fetching Spam-Blocked Users from Braze

We've been working on identifying users who have marked our emails as spam, and it's proven to be significantly more complex than expected. Here's a breakdown of the key challenges we've run into:

1. No current-state API — only raw event streams Braze doesn't expose a current-state endpoint for spam status. The only available data is a stream of raw events, which means you have to rely on a data warehouse to ingest and process potentially millions of event logs just to reconstruct user state.
2. Spam status is reversible, requiring cross-referencing two large event tables Because a spam mark can be reversed, you can't simply collect spam events and call it done. Each spam event needs to be cross-referenced against send events to determine whether the spam status is still active — which means scanning two large tables on every run.
3. Events arrive independently with no guaranteed ordering The spam event and the corresponding send event don't arrive together or at consistent times. A user might generate a spam event today and a related send event days later, making real-time or near-real-time processing unreliable.
4. Certain Canvases allow sending to spam-blocked users, causing false positives Some Canvases are configured to bypass spam suppression and send to all users, including those who have marked messages as spam. This means a send event from such a Canvas can overwrite a user's spam status to false, producing false positives in any derived spam blocklist.
5. Heavy infrastructure overhead All of the above ultimately requires building and maintaining a scheduled backend job that runs daily, pulling and processing large volumes of data from the warehouse — adding meaningful operational and compute cost.

Has anyone else run into these issues? Would love to hear how others are approaching this, or whether there are better patterns we haven't considered.