Get the current user and their organizations
/user/me
Returns the current user and their organizations. The result is the profile of whoever the credential belongs to, plus one entry per organization they are an active member of, each carrying that org's roles, teams and effective permissions. Call this first: it is how a client learns which organization ids it may put in `X-Organization-Id` and which actions to offer. With an org API token this still returns the token owner's memberships, so read `organizations` rather than assuming the token's org is the only one.
Response Body
false while an organization the user belongs to requires a second factor and they hold no passkey — turning the authenticator app off (DELETE /user/me/mfa/totp) is refused with 409 mfa_required_by_organization. The reason is in mfa_disable_blocked_reason.
User id (usr_…).
Login identities linked to this account.
e.g. google, email_code, invite, or an SSO connection.
Inactive accounts cannot authenticate at all.
True only for Elaichi support accounts. Always false for customer members.
True only for Elaichi support accounts. Always false for customer members; unrelated to organization roles.
A sentence saying why can_disable_mfa is false, or null.
True when TOTP is active on this account.
True when THIS session would be refused (403 mfa_setup_required) in at least one organization the user belongs to, because the organization requires a second factor and the session has not shown one. Always false for an API token. A client routes the person to second-factor setup on this rather than working out which organizations require one.
How many organizations refuse this session for lack of a second factor.
The organizations behind mfa_setup_required: a bounded page (at most 50), with the organization named by the current_org_id query parameter first when it is one of them. Not the whole set — mfa_setup_required_org_count is the true number; an organization not listed still refuses with 403 mfa_setup_required when entered.
One entry per active membership. Organizations where membership has lapsed are omitted.
Membership facts only — roles and teams are the sibling fields below, not nested here.
4 properties
User id (usr_…).
How they joined, e.g. invite or verified domain.
22 properties
Whether Elaichi support may sign in as this organization's members to help them. true by default. When false, every request made through such a support session against this organization is refused with 403 staff_impersonation_blocked, reads included, and the organization is left out of that session's GET /user/me and GET /organization. Changed with PATCH /organization/{id} (org:manage).
Why can_authorize_apps is false, in the gate's own order: blocked, then pending_deletion (even when the subscription is also gone, since a soft delete cancels it), then no_plan, then plan_single_user (Personal admits only the primary owner). null when connecting is open.
blockedpending_deletionno_planplan_single_usernull
Whether the CALLER may connect an app (MCP OAuth consent) to this organization right now: false while it is suspended, scheduled for deletion, has no active plan, or is on Personal and the caller is not its primary owner. Server-computed by the same gate POST /oauth/authorize-request/{id}/approve calls; present only on member-scoped responses. authorize_apps_blocked_reason says which.
Whether the caller may delete this organization: the org:delete permission, which only the Org Owner role holds. Server-computed, so branch on this rather than inspecting roles. Always false on rows that have no member context to compute it from, such as the organization list GET /organization. It never overstates: trust it when true, and read GET /user/me or GET /organization/{id} (both compute it) when you need it for a list row.
Whether the caller may change this organization's settings: the org:manage permission that PATCH /organization/{id} requires, and the organization is neither suspended nor in its deletion grace period. Server-computed, and false wherever can_delete is false for lack of a member context; it never overstates.
Whether the CALLER may turn mfa_required ON right now: can_manage, from an interactive session that would itself pass the check it is about to create. false — with the reason in can_require_mfa_reason — when switching it on would lock the caller out of this organization. The PATCH refuses that regardless with 409 mfa_setup_required. Turning it OFF is not governed by this field; it needs a step-up.
A sentence saying why can_require_mfa is false for a caller who can otherwise manage the organization. null otherwise.
Whether the caller may cancel a scheduled deletion: the org:manage permission, and only while purge_after is still ahead. Server-computed like can_delete, and false on rows with no member context. Read purge_after to tell "too late" from "not yours to undo".
Set when a deletion has been scheduled (DELETE /organization/{id}). The organization is read-only until purge_after. Null otherwise.
Organization id (org_…) — the value for X-Organization-Id.
Public URL of the logo image, or null.
Whether members must hold a second factor to act in this organization. false by default. When true, a signed-in session that has not shown a second factor (no TOTP challenge at login, no passkey sign-in, no factor enrolled since) is refused on every organization-scoped route, reads included, with 403 mfa_setup_required; error.details.has_second_factor says whether the person already has one and only needs to sign in with it. Exempt: org API tokens, Elaichi support sessions, and a session signed in through this organization's own SSO connection. MCP connections made before it was switched on, or from a session without a factor, are refused until the person connects again. Turning it off only lifts the organization requirement: a member who set up an authenticator app of their own is still challenged for it at every non-passkey sign-in. Changed with PATCH /organization/{id} (org:manage, interactive session only).
The stored plan: personal, gold, black, or none while on hold. This is not the same as the effective entitlement — read GET /organization/{id}/entitlements before gating a feature on it.
When a scheduled deletion becomes permanent — 30 days after deletion_scheduled_at. Null unless scheduled.
Data location fixed at creation: us/eu pin a hard jurisdiction, apac is a placement hint.
Free-form org settings. PATCH /organization/{id} REPLACES this object wholesale.
Immutable after creation.
Set when Elaichi granted this organization an indefinite trial, otherwise null. Unlocked with no end date: no countdown, no expiry email, billing still reachable.
Effective permission names, unioned across roles. This is the authoritative list for deciding what to show; the server re-checks it on every request.
Role summaries held in this organization.
4 properties
Role id (role_…).
billablefree_admin
2 properties
Team id (team_…).
The current organization only (current_org_id), and only when these permissions include billing:view (absent otherwise): null unless a seat-change invoice the card holder can act on is unpaid, including when the only unpaid ones are still with the bank. The newest such charge, as unpaid_seat_charges.newest on GET /organization/{id}/billing, plus count (every unpaid seat charge). The Elaichi app shows it as a bar on every page.
6 properties
Major units of currency.
Stripe's hosted invoice page; null for bank_approval.
failedneeds_approvalbank_approval
curl -X GET 'https://api.elaichi.ai/user/me' \
-H 'Authorization: Bearer $ELAICHI_API_TOKEN' \
-H 'Content-Type: application/json'const response = await fetch('https://api.elaichi.ai/user/me', {
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/user/me"
headers = {
"Authorization": f"Bearer {os.environ['ELAICHI_API_TOKEN']}",
"Content-Type": "application/json",
}
response = requests.get(url, headers=headers)
print(response.json())