ChiliPiper MCP

Deletes the column definition for an assignment table at the specified revision ONLY. Uses optimistic concurrency: pass the current revision (re-fetch via assignment-table-definition-get right before calling). Any rules that reference this table will no longer resolve an assignment. - workspaceId (req): the workspace that owns the table. - assignmentTableId (req): the table's id. - revision (req): the definition's current revision. → empty (204) on success ⚠ irreversible via API; a stale revision causes a conflict: re-fetch and retry see: assignment-table-definition-get (get a fresh revision immediately before calling)

Fetches one assignment-table definition (column schema) by its assignmentTableId. Use this to read the current column layout and a fresh revision before replacing the definition or patching a column. Use assignment-table-definition-list to browse. - workspaceId (req): the workspace that owns the table. - assignmentTableId (req): the table's id. → {id, name, inputs: [{key, name, required, typeHint?}], outputs: [{key, name, context, required}], allKeys, metadata: {revision, ...}} see: assignment-table-definition-list (browse), assignment-table-definition-replace (replace schema), assignment-table-get (read the rows)

Browses the assignment-table definitions (column schemas) in a workspace so you can discover assignmentTableIds, revisions, and column keys before reading/writing rows. An assignment-table definition describes the table's input columns (the variables a rule matches on) and output columns (each pinned to a Record/Meeting/Conversation context). Paging defaults to page 0 / pageSize 10; optionally filter by name. - workspaceId (req): the workspace whose definitions to list. - name (opt): case-sensitive filter on the definition name. → {results: [{id, name, inputs: [{key, name, required, typeHint?}], outputs: [{key, name, context, required}], allKeys, metadata: {revision, ...}}], total, page, pageSize} see: assignment-table-definition-get (fetch one), assignment-table-definition-create (add a definition)

Renames a single column in an assignment-table definition without replacing the whole schema. Uses optimistic concurrency: pass the current revision (re-fetch via assignment-table-definition-get right before calling). The column is addressed by its stable key, so renaming does not break existing rows. - workspaceId (req): the workspace that owns the table. - assignmentTableId (req): the table's id. - columnKey (req): the stable key of the column to rename (from the definition's allKeys / inputs / outputs). - revision (req): the definition's current revision. - newName (opt): the new column name; omit to leave the name unchanged. → {id, name, inputs, outputs, allKeys, metadata: {revision, ...}} ⚠ a stale revision causes a conflict: re-fetch and retry see: assignment-table-definition-replace (replace the whole schema)

Replaces the whole column definition for an assignment table. This is a full replace of name+inputs+outputs, not a merge; column ids (keys) are preserved by name so existing rows keep matching where names are unchanged. Uses optimistic concurrency: pass the current revision (re-fetch it via assignment-table-definition-get right before calling). Removing or renaming a column can invalidate existing rows. - workspaceId (req): the workspace that owns the table. - assignmentTableId (req): the table's id. - revision (req): the definition's current revision (from assignment-table-definition-get). - name / inputs / outputs (req): the new schema (same shape as create). → {id, name, inputs, outputs, allKeys, metadata: {revision, ...}} ⚠ full replace; a stale revision causes a conflict: re-fetch and retry see: assignment-table-definition-patch-column (rename a single column instead), assignment-table-definition-get

Creates or replaces ALL rows of an assignment table, validating them against the persisted definition. This is a full replace of the table's rows, not an append. The table's DEFINITION must already exist (assignment-table-definition-create): send definitionRevision equal to that definition's current revision so a write built against a stale schema is rejected. Optimistic concurrency on the table itself uses revision: omit it on the first upsert, otherwise pass the table's current revision. - workspaceId (req): the workspace that owns the table. - assignmentTableId (req): the table's id. - revision (opt): the table's current revision; omit on the first upsert. - table (req): {rows: [{inputs, outputs}]}: at least one row. inputs map input-column keys to JSON values; outputs map output-column keys to {tableOutType: "User"|"Distribution", value: {type: "UserAssignment", userId} | {type: "DistributionAssignment", distributionId}, humanReadableName?, context?}. - definitionRevision (req): revision of the definition the rows were authored against. → {id, rows, metadata: {revision, ...}} ⚠ full replace of rows; a stale table or definition revision causes a conflict: re-fetch and retry see: assignment-table-definition-get (get the definitionRevision), assignment-table-get (get the table revision)

Full-text search of Salesforce campaigns for the tenant's connected org so you can find the `campaignId` used by a router's "Add to Campaign" CRM action. Salesforce-only. Preferred over campaign-list for large orgs. - searchText (required): text to match against campaign names; must be at least 2 characters - isActive (opt): filter to active (true) or inactive (false) campaigns; omit for all - page (opt, default 0), pageSize (opt, default 10) → {results: [{id, name, status, startDate, endDate, active}], page, pageSize} Note: `id` is the Salesforce campaign id to drop into the Add-to-Campaign action's campaignId; search does not return a total ⚠ 4xx if searchText is shorter than 2 characters, or if Salesforce is not connected for the tenant see: campaign-list (browse all campaigns)

Edits a Concierge router and republishes it live. Only the fields you supply change; omitted fields (and config dimensions Edge doesn't model, e.g. router-link enrichment waterfalls and CRM-upsert settings) are preserved. Supplying name re-derives the URL slug. Each dimension you send is a full replace, except branding which merges per sub-field (see below). Triggers are a product of optional kinds: a webform (form OR thirdPartyForm: mutually exclusive), inAppButton, and routerLink each replace only their own kind: writing one never destroys the others. Call concierge-router-get first to inspect the current config. - routing (opt): when present, sets the routing matrix; when omitted, the current routing is kept. Each row's rule, when it matches, runs that row's `outcome`; the catch-all `outcome` runs when no row matches: {routes: [{ruleId, outcome}], catchAll?: outcome} outcome (one of): {type: "Schedule", assignment, meetingTypeId, timeout?, crmActions?} {type: "Redirect", url} Schedule assigns the lead and books a meeting type. assignment is {type: "Distribution", distributionId} or {type: "User", userId}. timeout (opt) {minutes, onTimeout} sets the no-show fallback; onTimeout is {type: "Landing"} or {type: "Url", url}; omit timeout for the default (10 min → Landing). crmActions (opt) is an ordered post-booking chain, each {type: "ConvertLead"}, {type: "Notify", slackChannel?} (omit slackChannel to notify the assigned host instead of a named channel), {type: "AddToCampaign", campaignId, memberStatus} (add the matched Salesforce lead/contact to a campaign with that member status; find campaignId with campaign-list / campaign-search), {type: "SalesforceUpdateFields", contact:[{object,field,value}], lead:[{field,value}]} (write field values onto the matched Salesforce contact/lead), {type: "HubspotUpdateFields", contact:[{object,field,value}]} (write property values onto the matched HubSpot record), {type: "SalesforceUpsertRecord", settings:{noMatch,whenMatch}} (create/update the matched Salesforce lead/contact), or {type: "HubspotUpsertRecord", settings:{noMatch,whenMatch}} (create/update the matched HubSpot contact), {type: "SalesforceUpdateOwnership", contact:[{object,field}], lead:[{field}]} (set the record owner to the booked host), or {type: "HubspotUpdateOwnership", contact:[{object,field}]} (set the record owner to the booked host). Redirect sends the lead to a URL instead of booking. ruleId is required on every row; an always-match route is the catchAll. routes may be empty (then only the catchAll applies). Note: catchAll is OPTIONAL on update: omit it to keep the router's current catch-all unchanged (a targeted edit of the rows only), including keeping a router that has no catch-all catch-all-less. Supply it to replace (or add) the catch-all outcome. - form (opt): when present, fully REPLACES the webform with a Chili form built from these fields (the in-app-button / router-link triggers, if any, are preserved); MUST include the email field (PersonEmail). If the router's current webform is a third-party form this CONVERTS it to a Chili form. Mutually exclusive with thirdPartyForm. Omit to keep the current webform: [{dataField, label, description?, required?, hidden?}] Note: dataField is a CRM data-field reference: a default field name (e.g. PersonEmail, PersonFirstName) or a custom-field UUID; a made-up name is rejected (400). label is the field's display name; required toggles whether the guest must fill it. hidden (opt) is a PREFILLED value (a string) stored on the field but NOT shown to the guest: it is a value, not a show/hide flag; omit it for a normal visible field. - thirdPartyForm (opt): when present, fully REPLACES the webform with a THIRD-PARTY (external) form: the mapping from each external form field name to a CP data field; MUST include the email field (PersonEmail). If the router's current webform is a Chili form this CONVERTS it to a third-party form. Mutually exclusive with form. Omit to keep the current webform: [{formFieldName, dataField, label?}] Note: formFieldName is the external form field's submitted name (e.g. "0-1/email"); dataField/label are as for form. An existing per-field enrichment waterfall is preserved (matched by formFieldName) across the replace, as is the automapped container URL; neither is settable via the API. - inAppButton (opt): when present, fully REPLACES the in-app-button trigger's fields (the form/router-link triggers, if any, are preserved); MUST include the email field (PersonEmail). Omit to keep the current button: [{dataField}] - routerLink (opt): when present, fully REPLACES the router-link trigger's fields (the form/in-app-button triggers, if any, are preserved); MUST include the email field (PersonEmail). Omit to keep the current link: [{dataField, label, required?, hidden?}] Note: a router-link field's enrichment waterfall is not settable via the API; an existing one is preserved (matched by dataField) across the replace. - branding (opt): the cover/heading/language. Merged PER SUB-FIELD: a sub-field you supply is replaced; one you omit is PRESERVED (so a partial {headingText} does not wipe coverImage/language). localizations are preserved. To clear a sub-field entirely, edit the router in the Concierge app.: {coverImage?, headingText?, language?} - localizations (opt): when present, fully REPLACES the per-language overrides (preserving branding): {"<lang-tag>": {"<key>": "<text>"}} → {id, workspaceId, name?, slug?, routing: {known, representable, rows: [{ruleId?, ruleType?, outcome}], catchAll?: {outcome}}, form?, thirdPartyForm?, inAppButton?, routerLink?, branding?, localizations?} Note: the returned routing is the lossy per-row summary (same shape as concierge-router-get), not the matrix you sent ⚠ full-replace + publishes live immediately: supplying routing/form/thirdPartyForm/inAppButton/routerLink/localizations replaces that ENTIRE dimension, not a partial merge (branding is the exception: it merges per sub-field, see above) ⚠ routing REJECTED (409) when the router's existing routing: its DRAFT tree or its PUBLISHED tree: isn't representable in this simplified model (advanced routing built in the Concierge app: owner-assign, contact-options / multiple-choice, call-rep, multiple assignees per row, CRM actions beyond convert-lead / Slack-notify, enrichment or spam-check steps, etc.): to avoid silently destroying it, edit those routers in the Concierge app instead. Check routing.representable via concierge-router-get first. ⚠ form and thirdPartyForm are mutually exclusive (a router has a single webform): supplying both is rejected (400). Supplying form on a third-party-webform router (or thirdPartyForm on a Chili-webform router) CONVERTS the webform to the supplied kind, replacing the previous mapping. branding/localizations are always accepted. A name-only update always succeeds. ⚠ every update publishes the router's current DRAFT: if the draft carries unpublished edits made in the Concierge app, those go live as a side effect, even on a name-only patch ⚠ if the final publish step fails, the changes are saved on an UNPUBLISHED draft and a typed 422 error is returned: fix or delete the draft in the Concierge app see: concierge-router-get (check routing.representable / form.representable before replacing), rule-list (find ruleIds), distribution-list (find distributionIds), user-find (find userIds), meeting-type-list (find meetingTypeIds)

Cancels the Chili Piper meeting linked to a CRM event (v2 POST variant): the CRM-keyed twin of meeting-cancel-post. Resolves the CRM id (15- or 18-char Salesforce EventId or equivalent) to its meeting, cancels it, and returns the updated meeting record. → {meetingId, meetingStatus: "CANCELLED", ...} ⚠ irreversible; may email attendees; 404 if the CRM id has no linked meeting see: crm-get (verify before/after), meeting-cancel-post (if CP meetingId already known), crm-cancel (v1 GET variant)

Resolves the ChiliPiper meeting linked to a CRM event ID and permanently cancels it. Irreversible: may email attendees. Accepts 15- or 18-character Salesforce IDs.

Fetches one data field by its reference (a custom field's UUID, or a default/internal field's stable name). → {reference, objectType, label, dataType, mappings: [...]} see: data-field-list (find references)

Browses every Distro router in the org to discover routerIds, activation status, and triggers. A Distro router routes CRM records (leads) to users via distributions, driven by a trigger. → {routers: [{id, name, status, trigger: {objectType, eventTypes: [{type, ...}], evaluation, delay}}]} Note: status is the router's activation state: one of {type:"Active"} | {type:"Inactive"} | {type:"Activating"} | {type:"Deactivating"} | {type:"Error", message}. A router created via the API is Inactive until distro-router-activate is called. Note: when an entry of trigger.eventTypes has type=Scheduled it carries schedulerId: that is the resourceSchedulerId expected by resource-scheduler-run. see: resource-scheduler-run (run a scheduled router on demand using schedulerId from a Scheduled trigger), distro-router-activate / distro-router-deactivate (toggle a router's status)

Audits a workspace's Distro router runs: a paginated, record-level trail of which records were routed, to whom, and how. Use distro-log-get afterwards to drill into why a single record routed the way it did. Paging defaults to page 0 / pageSize 10. - body (req; send `{}` for no filtering): filter with optional fields: - userIds (opt): filter by assignee user IDs - status (opt): flow lifecycle outcome; one of: "NotTriggered" | "NotMatchedEntryRule" | "DelayInProgress" | "WorkingHours" | "SlaInProgress" | "NotRouted" | "Finished" | "SlaFinished" | "Error" - distributionMethod (opt): how the user was picked (a distribution-level decision, not a distro-level state); one of: "FromOwnershipArs" | "RoundRobinEvaluationSuccess" | "EvaluatedFromRoundRobinArs" | "FallbackTeam" | "FallbackUser" | "DuplicateMatchOwner" | "AssignmentTable" | "NoDistribution" | "NoUserAvailable" | "ClientError" - search (opt): text search - from (opt): start time (ISO8601 with zone, e.g. "2024-01-01T00:00:00Z") - to (opt): end time (ISO8601 with zone) → {results: [{log: {id, workspaceId, routerId, status, assignments: [{userId, distributionId?, method}], trigger?: {entityId, entityType, eventType}, createdAt, updatedAt}, router: {id, name, workspaceId}}], total, page, pageSize} see: distro-list-routers (find routers), distro-router-get (find a router's workspaceId)

Permanently deletes a Distro router. The router must be INACTIVE first: deactivate it via distro-router-deactivate and wait until distro-router-get shows Inactive before deleting. ⚠ REJECTED (409) when the router is still active (or mid-transition): deactivate it first via distro-router-deactivate, then delete once distro-router-get shows status inactive ⚠ irreversible via API; any triggers or links pointing at this router stop working see: distro-router-deactivate (deactivate before deleting), distro-list-routers or distro-router-get (confirm the id and status before deleting)

Creates a Handoff router and publishes it live in one step: there is no unpublished-draft state via the API. workspaceId must be a team workspace of this tenant (400 otherwise). The routing matrix is a list of ordered rules evaluated top-down plus an optional catch-all fallback: - routing (req): ordered rules evaluated top-down, plus an optional catch-all fallback. Each row's rule, when it matches, runs that row's `outcome`; the catch-all `outcome` runs when no row matches: {routes: [{ruleId, outcome}], catchAll?: outcome} outcome: {type: "Schedule", assignment, meetingTypeId, crmActions?} Schedule assigns the lead and books a meeting type. assignment is {type: "Distribution", distributionId} (round-robin / ownership / whatever the distribution does) or {type: "User", userId} (a specific host). crmActions (opt) is an ordered post-booking chain, each {type: "ConvertLead"}, {type: "AddToCampaign", campaignId, memberStatus} (add the matched Salesforce lead/contact to a campaign with that member status; find campaignId with campaign-list / campaign-search), {type: "SalesforceUpdateFields", contact:[{object,field,value}], lead:[{field,value}]} (write field values onto the matched Salesforce contact/lead), {type: "HubspotUpdateFields", contact:[{object,field,value}]} (write property values onto the matched HubSpot record), {type: "SalesforceUpdateOwnership", contact:[{object,field}], lead:[{field}]} (set the record owner to the booked host), or {type: "HubspotUpdateOwnership", contact:[{object,field}]} (set the record owner to the booked host). ruleId is required on every row; an always-match route is the catchAll. catchAll is optional: a router with no catch-all simply has no fallback when no row matches. Provide at least one row or a catchAll (an empty matrix with neither is rejected). Note: handoff routers support only the Schedule outcome: Redirect outcomes, no-show timeouts, Notify (Slack), and the SalesforceUpsertRecord / HubspotUpsertRecord create-record CRM actions are concierge-only and are not part of the handoff schema (ConvertLead / AddToCampaign / SalesforceUpdateFields / HubspotUpdateFields / SalesforceUpdateOwnership / HubspotUpdateOwnership are the only CRM actions here). → {id, workspaceId, name?, routing: {known, representable, rows: [{ruleId?, ruleType?, outcome}], catchAll?: {outcome}}} Note: the returned routing is the lossy per-row summary (same shape as handoff-router-get), not the matrix you sent ⚠ if the final publish step fails the router is left behind as an UNPUBLISHED draft (typed 422); retrying the create mints ANOTHER draft: fix or delete the leftover in the Handoff app see: handoff-router-list (find a workspaceId), rule-list (find ruleIds), distribution-list (find distributionIds), user-find (find userIds), meeting-type-list (find meetingTypeIds), handoff-router-update (replace config afterwards)

Edits a Handoff router and republishes it live. Only the fields you supply change; omitted fields are preserved. Use handoff-router-get first to confirm the routing is representable before replacing it. - routing (opt): when present, sets the routing matrix; when omitted, the current routing is kept. Each row's rule, when it matches, runs that row's `outcome`; the catch-all `outcome` runs when no row matches: {routes: [{ruleId, outcome}], catchAll?: outcome} outcome: {type: "Schedule", assignment, meetingTypeId, crmActions?} Schedule assigns the lead and books a meeting type. assignment is {type: "Distribution", distributionId} or {type: "User", userId}. crmActions (opt) is an ordered post-booking chain, each {type: "ConvertLead"}, {type: "AddToCampaign", campaignId, memberStatus} (add the matched Salesforce lead/contact to a campaign with that member status; find campaignId with campaign-list / campaign-search), {type: "SalesforceUpdateFields", contact:[{object,field,value}], lead:[{field,value}]} (write field values onto the matched Salesforce contact/lead), {type: "HubspotUpdateFields", contact:[{object,field,value}]} (write property values onto the matched HubSpot record), {type: "SalesforceUpdateOwnership", contact:[{object,field}], lead:[{field}]} (set the record owner to the booked host), or {type: "HubspotUpdateOwnership", contact:[{object,field}]} (set the record owner to the booked host). ruleId is required on every row; an always-match route is the catchAll. routes may be empty (then only the catchAll applies). Note: catchAll is OPTIONAL on update: omit it to keep the router's current catch-all unchanged (a targeted edit of the rows only), including keeping a router that has no catch-all catch-all-less. Supply it to replace (or add) the catch-all outcome. Note: handoff routers support only the Schedule outcome: Redirect outcomes, no-show timeouts, Notify (Slack), and the SalesforceUpsertRecord / HubspotUpsertRecord create-record CRM actions are concierge-only and are not part of the handoff schema (ConvertLead / AddToCampaign / SalesforceUpdateFields / HubspotUpdateFields / SalesforceUpdateOwnership / HubspotUpdateOwnership are the only CRM actions here). → {id, workspaceId, name?, routing: {known, representable, rows: [{ruleId?, ruleType?, outcome}], catchAll?: {outcome}}} Note: the returned routing is the lossy per-row summary (same shape as handoff-router-get), not the matrix you sent ⚠ publishes live immediately. For a representable router, routing replaces the whole matrix; for an app-built (non-representable) router, your rows are OVERLAID onto the existing tree by ruleId: the modeled dimensions (assignment, meeting type, CRM chain, and catch-all when supplied) are replaced in place and every app-only feature is preserved. Check routing.representable via handoff-router-get first. ⚠ every update publishes the router's current DRAFT: if the draft carries unpublished edits made in the Handoff app, those go live as a side effect, even on a name-only patch ⚠ if the final publish step fails, the changes are saved on an UNPUBLISHED draft and a typed 422 error is returned: fix or delete the draft in the Handoff app see: handoff-router-get (check routing.representable before replacing), rule-list (find ruleIds), distribution-list (find distributionIds), user-find (find userIds), meeting-type-list (find meetingTypeIds)

Replaces the ENTIRE set of Chili Piper ↔ Gong user mappings for the tenant with the submitted map. This is a strict full-replace, not a merge: any CP user NOT present in the map is left unmapped, and an empty map clears ALL Gong mappings for the tenant. Gong-only; use integration-salesforce-set-mappings / integration-hubspot-set-mappings for the CRMs. - body: a JSON object keyed by Chili Piper user id, whose value is the Gong user's email to map that CP user to (e.g. `{"<cpUserId>": "rep@example.com"}`); send `{}` to clear all mappings Note: Gong identifies users by email: the value is the Gong user's email, not a numeric id ⚠ atomic: if ANY submitted email does not resolve to a real Gong user, the WHOLE request is rejected (422) and nothing is changed → {UserId: {email}} Note: response echoes the resulting full mapping set (the same shape as integration-gong-users), so the caller sees exactly what is now mapped see: integration-gong-users (read current mappings)

Resolves the given Chili Piper user ids to their mapped Slack users: the linked Slack user id plus best-effort email and display name. Slack-only; use integration-salesforce-users / integration-hubspot-users for the CRMs. - userIds: Chili Piper user ids to resolve → {UserId: {id, email, name}} Note: response is a JSON object keyed by Chili Piper user id; unmapped users are omitted see: integration-find-users (CRM-agnostic mapping status), integration-slack-set-mappings (replace mappings)

Fetches one team meeting type by id, including its attached reminders (unlike meeting-type-list, which leaves reminders null). Use it before editing to read current state, or once you already know the id instead of browsing the list. → {id, workspaceId, name, description?, inviteTitle, inviteDescription, status, isActive, duration, location: {default: {type, index, host?, value?}, others: [{type, index, host?, value?}]}, buffers: {before?, after?}, meetingLimit?: {limitBy: "Email"|"Domain", timeframe: "Hourly"|"Daily"|"Weekly"|"Monthly"|"Yearly", count}, sharedWith?: {type: "Workspace"}|{type: "Teams", teamIds}, reminders: [{id, workspaceId, channel, trigger: {kind, offset?}, name, title?, body}]} Note: meetingLimit.timeframe is approximate: the backend's reset schedule (e.g. every-2-weeks) is summarised to the nearest timeframe; finer reset details (every-N, anchor day) are not surfaced. Note: sharedWith (the sharing scope: whole workspace vs specific teams) is read from the meeting type's admin (one-on-one) scheduling link; it is null when no such link, or more than one, is found: null means "indeterminate", not "workspace". ⚠ personal meeting types are not manageable here and return an error see: meeting-type-list (browse to find an id), meeting-type-update (edit), meeting-type-delete (remove)

Runs a resource scheduler on demand: executes its configured query and dispatches matched records to the linked executing flow.

Returns a paginated list of routing rules with optional filters.

Creates a group scheduling link: a meeting with a fixed host plus additional members. Offered slots are the intersection of the host and required members' availability; optional members are invited but do not gate availability. - slug: URL slug (lowercase letters, digits, hyphens, underscores). - hostUserId: the host user; use user-find. - sharedWith (opt): sharing scope, {type: "Workspace"} (default) or {type: "Teams", teamIds}. → {workspaceId, linkId, name, slug, meetingTypeIds, bookingUrl} see: user-find (resolve user ids), scheduling-link-list-group (browse existing)

Deletes a group scheduling link by id. - linkId (req): the group link's id ⚠ irreversible via API; the booking URL stops working immediately see: scheduling-link-list-group (confirm the id before deleting)

Patches an ownership scheduling link. Send only the fields you want to change; omitted fields keep their current value. Passing ownership or distribution replaces that whole config block. As on create, distribution assignments are lean {distributionId, required}: no members field. → {workspaceId, linkId, name, slug, meetingTypeIds, ownership, distribution, pageConfig, sharedWith, bookingUrl} ⚠ takes effect immediately see: scheduling-link-list-ownership (find a linkId and inspect current config)

Returns all round-robin scheduling links.

Adds one or more users to a team.

Removes one or more users from a specific team.

Sends invitation emails to existing users who have not yet been invited, or whose last invite is past the re-invite cooldown. - userIds (opt): list of user IDs to notify; omit to send to all eligible users in the org → {} ⚠ non-idempotent: triggers emails; users within the cooldown window are silently skipped see: user-invite (create a new user account, optionally sending the invite in one step), user-find (look up user IDs)

Returns details of a user by their ID.