List access requests (admin queue, or your own)
/access-request
Two audiences on one route. **Without `mine`** this is the org-wide admin queue and requires `member:manage` — the closest existing permission to "may decide who gets more access": acting on a request always ends in a role change, a restriction edit, or an invite, so no new permission was added for this resource. A caller without it gets `403`, never an empty page — "nothing here" is a claim about the organization that a bystander has not earned. Rows are the admin view (`requester`, `resolved_by`, `can_resolve`). **With `mine=true`** it answers only the CALLER’S OWN requests and needs no permission at all — the same nothing that filing one needed, for the same deadlock reason, and the only way the person who filed a request can find it again. The scope comes from the session, so no id on the wire can name somebody else. Rows are the narrower **self view** (`can_withdraw`, and a bare `resolved_by_user_id` rather than a resolved name) for every caller, admins included: resolving an id into a name and email is a member-directory lookup this project does not hang off a route a plain member can reach. `limit`, `cursor`, `q` and `status` apply identically to both. `q` matches the requested **tool** name or the requester’s **note**, not the requester themselves — search members by name with a member lookup and cross-reference `requester_user_id` instead. It does not match `tool_label`: a connector’s label is resolved outside the store and lands in no column the query can read.
Query Parameters
Case-insensitive substring match on the requested tool name or the requester’s note. LIKE wildcards are matched literally. Max 200 characters.
Filter by status. Defaults to pending. Any other value is a 400.
pendingapproveddeniedwithdrawnall
Set true to list only the requests you filed (no permission required, self-view rows). Omitted or false means the org-wide admin queue, which requires member:manage. Any other value is a 400, so a typo cannot silently fall through to the queue.
truefalse10
Response Body
object · 21 properties
True while status is still pending and the row is not the caller’s own — the two preconditions resolve itself enforces (409 and 403 respectively).
True when the caller is the requester and status is still pending. Present on this shape as well as on the self view: an admin’s own request sits in their own queue, and withdrawing it is the one verb on that row that is theirs.
Display name of connector_slug on a tool request that names one (falls back to the slug).
On the same rows, for a TOOL request only: true when approving lifts nothing because the requester’s WHOLE connector is restricted — one tool cannot be carved out of a connector restricted whole, and an approval never opens the whole connector for a one-tool ask. Their connector access is what an admin would have to grant instead.
On a "tool" request, the connector the tool lives on when the request named one — what makes approving it able to lift the restriction on that tool. Always null on a "connector" request.
Access request id (areq_…).
Optional free text from the requester, ≤ 2000 characters.
Present only when reason is "permission" — never populated for a "restriction"-reason request, on either write or read. That is the disclosure rule: a restriction refusal never names the rule that blocked the caller, so this field must not become a second channel for the same fact.
What kind of refusal this request is asking to be reconsidered.
permissionrestriction
Resolved member profile. Falls back to { id } alone when the profile row no longer resolves.
3 properties
User id (usr_…).
User id (usr_…) of whoever filed the request.
Resolved member profile. Falls back to { id } alone when the profile row no longer resolves.
3 properties
User id (usr_…).
User id (usr_…) of the admin who resolved it.
toolconnector
pendingapproveddeniedwithdrawn
What was asked for: a tool name, or a connector slug when resource_type is "connector".
On a pending restriction-reason request approving could act on (a connector request, or a tool request naming its connector_slug): whether approving it would actually lift anything. Absent on every other row.
object · 15 properties
True when the caller is the requester and status is still pending.
On a "tool" request, the connector the tool lives on when the request named one — what makes approving it able to lift the restriction on that tool. Always null on a "connector" request.
Access request id (areq_…).
Optional free text from the requester, ≤ 2000 characters.
Present only when reason is "permission" — never populated for a "restriction"-reason request, on either write or read. That is the disclosure rule: a restriction refusal never names the rule that blocked the caller, so this field must not become a second channel for the same fact.
What kind of refusal this request is asking to be reconsidered.
permissionrestriction
User id (usr_…) of whoever filed the request.
User id (usr_…) of the admin who resolved it.
toolconnector
pendingapproveddeniedwithdrawn
What was asked for: a tool name, or a connector slug when resource_type is "connector".
curl -X GET 'https://api.elaichi.ai/access-request' \
-H 'Authorization: Bearer $ELAICHI_API_TOKEN' \
-H 'Content-Type: application/json'const response = await fetch('https://api.elaichi.ai/access-request', {
method: 'GET',
headers: {
'Authorization': 'Bearer ' + process.env.ELAICHI_API_TOKEN,
'Content-Type': 'application/json',
},
});
const data = await response.json();
console.log(data);import os
import requests
url = "https://api.elaichi.ai/access-request"
headers = {
"Authorization": f"Bearer {os.environ['ELAICHI_API_TOKEN']}",
"Content-Type": "application/json",
}
response = requests.get(url, headers=headers)
print(response.json())