not_found. The id doesn’t exist — or it exists but belongs to a
different account. The two cases are deliberately indistinguishable: a 404 never
confirms that someone else’s session id is real.
The shape
How to fix
- Check the id’s prefix against the resource:
sess_for sessions,ext_for extractions,mon_for monitors,whep_for webhook endpoints. Asess_id on/v1/webhooks/{id}is a 404, not a type error. (The extractions and monitors surfaces answer501on every id, right prefix or wrong — they aren’t served yet.) - Confirm you’re calling with a key from the same account that created the
resource — keys on other accounts see nothing, by design.
fn_test_andfn_live_keys share the account, so that split is not the cause. - List what the account can actually see:
GET /v1/sessions(covers extractions and monitor runs viatype). - Redaction is planned, not served —
DELETE /v1/sessions/{id}answers501today, so nothing you can call yet produces a redacted run. When it ships, a redacted run will keep its ledger skeleton while its data reads 404; if you rely on long-lived reads, note runs are retained at least 90 days.
Reproduce it
Works on anfn_test_ key, $0: