v9
latestOpenAPI 3.1.02026-08-08435208464.3 KBList Pending Thread Permission Requests Route
The approval still waiting in THIS thread, if any.
The card is pushed once over SSE and never repeated. A client whose stream died before it arrived (backgrounded app, slept tab, closed chat sheet) has no other way to learn an approval is outstanding, so the window burns down against a user who was shown nothing. Clients call this on thread mount, on return-to-foreground, and after a stream reconnect.
Authorization mirrors POST /permission-response's chat branch: fetch_authorized_thread proves the caller may see this thread, and the org + thread it authorized are then applied as FILTERS on the read. Proving thread access without binding the query to that thread is exactly the hole that let one caller answer another org's request (see tests/unit/test_permission_response_thread_request_binding.py) -- so the proof and the filter must not drift apart here either. On a shared/ org-visible thread (plans/2026-08-05-slack-shared-channel-threads.md amendment 3), thread access alone no longer implies "this pending approval is mine" -- requesting_user_id additionally excludes another member's stamped request; NULL-stamped (legacy) rows are unaffected.
Path parameters
Query parameters
Response
Successful Response