Skip to main content
HTTP 404 · type 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

A planned route is a 501, not a 404. Everything marked x-fn-status: planned in the API reference (discover, extractions, monitors, refresh, redaction, GET /v1/receipts/{id}, webhook test/redeliver, /mcp) answers 501 not_implemented with a surface field naming what is missing — see not_implemented. Do not branch on 404 to detect an unshipped route; branch on 501.One other thing does still answer 404, honestly stated: a wrong HTTP method on a known path (a 405 is planned). If a route you’re sure exists 404s, check the verb before hunting for an ownership problem.

How to fix

  • Check the id’s prefix against the resource: sess_ for sessions, ext_ for extractions, mon_ for monitors, whep_ for webhook endpoints. A sess_ id on /v1/webhooks/{id} is a 404, not a type error. (The extractions and monitors surfaces answer 501 on 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_ and fn_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 via type).
  • Redaction is planned, not servedDELETE /v1/sessions/{id} answers 501 today, 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 an fn_test_ key, $0: