Offboarding preflight for member removal
/member/{userId}/offboarding
What removing this member would break. Every connection they own (all are deleted on removal), each with `references` (exact counts of the toolboxes and other members' synthetic tools using it, plus at most five names) and up to ten `replacement_candidates` (same connector, active, not the leaver's, usable by you; owner named) beside an exact `replacement_candidate_count`. `credentials` counts the API tokens and AI client logins removal revokes. Separately, `delegated_entries` lists entries on OTHER members' toolboxes whose pin currently rides on THIS member's own `use` grant, not their ownership (docs/access-model.md §6) — non-blocking, member removal never refuses over it, but once the member is gone those entries go unmet until somebody with their own `use` on the connection re-pins them; there is no operation that does that automatically. Read-only — call it before `DELETE /member/{userId}` to collect the hand-over and replacement decisions that call takes. `connectors` lists every custom connector the member owns, each with a bounded `shared_with` rollup and a `connection_count` (never the grant or connection lists). Requires `member:manage`.
Path Parameters
User id (usr_…) of an org member.
Response Body
Every connection the member owns: connection, referenced_by, private, needs_resolution (informational), references, replacement_candidates, replacement_candidate_count.
Every custom connector the member owns: slug, name, logo, owner_user_id, private, the bounded shared_with rollup, connection_count, needs_resolution (always true: every connector needs a new owner) and timestamps. Resolved by connector_actions on DELETE /member/{userId}.
Non-blocking (§6): entries elsewhere in the org whose delegation chain depends on this member, independent of which connections they own.
True when the member owns connectors and nobody can receive them: no active member other than the leaver and the caller exists, and the caller lacks connector:manage so cannot take them either. DELETE /member/{userId} cannot succeed until another member is invited. Always false when connectors is empty. A bounded existence check, never a member count.
True when the member owns connectors, no active member other than the leaver and the caller exists, and the caller holds connector:manage: the caller may then name themselves as the connector recipient (audited as self_assigned_sole_successor). Connectors only. Mutually exclusive with no_eligible_successor; always false when connectors is empty.
curl -X GET 'https://api.elaichi.ai/member/<userId>/offboarding' \
-H 'Authorization: Bearer $ELAICHI_API_TOKEN' \
-H 'Content-Type: application/json'const response = await fetch('https://api.elaichi.ai/member/<userId>/offboarding', {
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/member/<userId>/offboarding"
headers = {
"Authorization": f"Bearer {os.environ['ELAICHI_API_TOKEN']}",
"Content-Type": "application/json",
}
response = requests.get(url, headers=headers)
print(response.json())