Every message in the workspace, newest first, across every one of its addresses.
More
WHAT THIS IS FOR. Until now the only way to see what had arrived ANYWHERE was to walk the
addresses one at a time — the console showed one inbox and you switched between them. Asking
the question by fanning out over the per-inbox route is not an option and never was: at Pro's
25 addresses on the console's 3s poll it is 500 requests a minute from a single tab, the same
arithmetic that already forced arrival counts to be aggregated server-side for the addresses
list rather than derived per row.
NOT A REPLACEMENT FOR THE PER-INBOX ROUTE. That one stays the way to read ONE address, and it
is what a CI poller should use — narrower, cheaper, and it 404s when its address is gone, which
is the signal a script wants. This is the human question ("what has arrived") rather than the
machine one ("did the mail I am waiting for land yet").
THE GATE IS THE CREDENTIAL, NOT THE ROUTE — require_read_api, exactly as its sibling does it.
A browser session reads on every plan including free; only a minted API key is charged for
programmatic access. Gating the route instead is how the read API shipped the first time, and
it made free unusable in a way no test caught: the dashboard necessarily calls the same
endpoint a script does, so mail arrived, parsed, stored, and could be looked at by nobody.
Each row carries its own inbox_id already, so nothing new goes on the wire — a client joins
the address string from the inbox list it has loaded anyway rather than having it denormalised
onto every message, which would be a second copy of a value that can be renamed.