The 3 ungranted roles are ungranted on purpose. Requesting a PII scope (Buyer Communication, Direct-to-Consumer Shipping, Tax Invoicing) puts the application into Amazon's Data Protection Policy audit track: annual security questionnaire, encryption and retention attestations, and penetration-test evidence. No screen in this console needs a buyer name, address or email, so the application stays outside that scope and every response it handles is aggregate or ASIN-level.

Three properties of this pipeline are worth naming, because they are the difference between a script and something that can be left running. Restated windows are rewritten, not upserted: Amazon moves sales figures for up to 72 hours and can reopen a settlement, so the 9 feeds marked above delete their window before writing it, which is the only way a total keeps matching Amazon's own console. Auth failures are separated from throttling: a 403 from a lapsed role grant and a 429 from rate limiting look alike in a log and need opposite responses, so the client classifies them and a feed waiting on a human is held back rather than retried every fifteen minutes all weekend. Nothing here writes to Amazon. There is no code path in the ingestion layer that POSTs to a selling partner resource. Acknowledging a PO and filing a claim are separate operations, each behind an explicit human approval.

Why two latencies exist in this app. Notifications land on an EventBridge bus or an SQS queue, a small consumer normalises the payload and writes it to Supabase, and the alert rules evaluate on write rather than on a poll. That is why buy-box loss and suppression alerts appear within minutes of the event, while anything sourced from a report (fees, settlement, aged inventory, vendor traffic) can only move on the report cadence shown above. When a number on another page looks behind, the row that explains it is in one of these two tables.