[CIPP] Add a custom domain to a tenant via POST /api/AddDomain. CIPP body keys per spec: 'domain' (camelCase, the new domain to add) and 'tenantFilter' (camelCase, required). The domain will need DNS verification after adding. Pass keys verbatim — caller is responsible for exact spec casing.

[CIPP] Add CIPP service principal permissions to partner tenant. Required for CIPP API access.

[CIPP] Multi-action tenant endpoint at POST /api/AddTenant. 'Action' is read as `$Request.Body.Action ?? $Request.Query.Action` and switches over EXACTLY FOUR values: 'ValidateDomain', 'GetOrganizationProfile', 'AddTenant', 'ValidateAddress'; anything else falls to the default arm and returns state='Error' (capital E — the success arms use lowercase 'success', and JSON string comparison is case-sensitive) with 'Invalid action specified: <value>'. WARNING — Action='AddTenant' DOES NOT CREATE A TENANT: the Partner Center customer-creation call is commented out upstream ('# not doing this yet') and the handler returns a HARDCODED sample response (userName 'test', password 'this_is_not_a_real_password') wrapped as state='success' with 'Tenant created successfully'. An agent that dispatched it would report a fabricated tenant and fake credentials to a human, so THIS TOOL REFUSES Action='AddTenant' before dispatch; the other three actions dispatch normally and this tool is the way to reach them. The refusal inspects the request BODY, which is total as wired because StackJack's client posts this endpoint with no query string — if a query-capable overload is ever added, the refusal must be extended to the query lane or the fabricated-success path reopens. Body keys (PascalCase): 'Action', 'TenantName', 'CompanyName', 'AddressLine1', 'AddressLine2', 'City', 'State', 'PostalCode', 'Country', 'FirstName', 'LastName', 'Email', 'PhoneNumber'. NOT scoped via tenantFilter. Pass keys verbatim.

[CIPP] Force CIPP to bypass its tenant cache on the next enumeration, via POST /api/ListTenants carrying the body key 'ClearCache' as a real JSON boolean true. THIS TOOL WRITES to the CIPP instance: upstream tests `if ($Request.Body.ClearCache -eq $true)` and, when it matches, calls Remove-CIPPCache to discard the cached tenant list before rebuilding it from the partner relationships. Nothing is removed from any M365 tenant and no configuration changes — the cache is rebuilt by the refresh this call queues, so the call is safely repeatable. The response is NOT a tenant list: the cache-clear branch returns EARLY with a fixed acknowledgement, {"Results":[{"Results":"Cache has been cleared and a tenant refresh is queued."}],"Metadata":{"Details":[...Remove-CIPPCache progress strings such as 'Removed N tenants' / 'Cache cleanup complete'...]}}. No tenant appears in the payload. The rebuild runs asynchronously as the 'UpdateTenants' orchestration, so call cipp_list_tenants AFTERWARDS to read the freshly enumerated tenants. Use cipp_list_tenants for ordinary discovery: it is the read-only tool and it never touches the cache.

[CIPP] Run a domain action against a tenant via DELETE /api/ExecDomainAction. This is a THREE-WAY switch, NOT a delete-only endpoint — the destructive arm is one of three: 'verify' issues a Graph POST to /beta/domains//verify (submits the domain for verification); 'delete' issues a Graph DELETE on /beta/domains/ — DESTRUCTIVE and irreversible, the domain is removed from the tenant; 'setDefault' issues a Graph PATCH on /beta/domains/ with isDefault=true. Every arm runs -AsApp against the tenant named by 'tenantFilter'. Body keys read: 'tenantFilter', 'domain', 'Action'; upstream throws 'Action is required' on a blank Action and 'Invalid action: <x>' for anything outside the three. This tool takes the action and domain as typed parameters and refuses an unrecognized, ambiguous or overridden verb BEFORE dispatch — an 'Action' supplied through fieldsJson may not change the operation this call was reviewed and authorized as — so neither a mistyped nor a smuggled action can fall through to the delete arm.

[CIPP] Edit CIPP tenant configuration via POST /api/EditTenant. Invoke-EditTenant reads EXACTLY THREE body keys — 'customerId' (camelCase, the M365 customer/tenant GUID that identifies which tenant to edit), 'tenantAlias' (camelCase, the display alias) and 'tenantGroups' (camelCase). There is NO 'GroupId' body key: an earlier version of this description listed one and upstream never reads it. 'tenantGroups' is an ARRAY OF OBJECTS — the handler iterates it and reads '.groupId' off each element (plus '.groupName' for its log line) — and it is a REPLACE SET, not an addition: upstream adds the tenant to every listed static group AND removes it from every static group it currently belongs to that is not in the list, so always send the tenant's COMPLETE intended static-group list. WARNING — DATA LOSS: a comma-separated string, or an array of bare strings, has no '.groupId' on any element, so the add loop skips everything and the remove loop then matches EVERY current membership — the tenant is stripped from ALL of its static groups while the call still returns 200 with 'Tenant details updated successfully'. Send objects. WARNING — 'tenantAlias' is not optional in effect either: omitting it (or sending an empty string) DELETES the tenant's stored alias (the row keyed on the customerId you send), so re-send the current alias whenever you are only changing 'tenantGroups'. This endpoint does NOT take 'tenantFilter'. Pass keys verbatim — caller is responsible for exact spec casing.

[CIPP] Edit the default user-offboarding settings for a tenant via POST /api/EditTenantOffboardingDefaults. Invoke-EditTenantOffboardingDefaults reads EXACTLY THREE body keys — 'customerId' (camelCase), 'defaultDomainName' (camelCase) and 'offboardingDefaults' (camelCase). There is NO 'Alias' key and NO 'Groups' key: both appeared in an earlier version of this description and are silently discarded upstream. 'offboardingDefaults' must be a JSON OBJECT, never a pre-serialized string — the handler serializes it ITSELF with `$jsonValue = [string]($offboardingDefaults | ConvertTo-Json -Compress)`. WARNING: passing an already-serialized JSON string double-encodes it — CIPP wraps it again, so the string "" is STORED as a quoted "" instead of clearing the defaults. That is recoverable, not permanent: the clear-defaults branch (`$jsonValue -and $jsonValue -ne '' -and $jsonValue -ne 'null' -and $jsonValue -ne ''`) is evaluated on THIS request's serialized value and never on the stored row, so sending a real empty object on a later call still deletes it. Send to CLEAR the stored defaults. WARNING — omitting 'offboardingDefaults' is NOT a partial update: a missing value serializes to 'null' and takes that same CLEAR branch, wiping the tenant's stored defaults. These defaults are applied by user-offboarding flows; this is NOT the tenant-offboard endpoint. This endpoint does NOT take 'tenantFilter'. Pass keys verbatim — caller is responsible for exact spec casing.

[CIPP] Change CIPP's excluded-licences setting (a CIPP instance setting affecting licence reporting for EVERY tenant), via POST /api/ExecExcludeLicenses. Actions: 'AddExclusion' (exclude a SKU everywhere; needs guid + skuName), 'AlertOnly' (exclude from alerts only; needs guid + skuName), 'SetShowInDropdown' (toggle a SKU's licence-dropdown visibility; needs guid + showInDropdown; 500s when the GUID is not already excluded), 'RemoveExclusion' (needs guid; a GUID that is not excluded also 500s), 'RestoreDefaults' (re-seed CIPP's 26 defaults — ADDITIVE by default; with fullReset=true it FIRST DELETES EVERY ROW, including every exclusion an operator added by hand, then re-seeds: do not send fullReset=true unless the operator explicitly wants their custom exclusions destroyed). OVERWRITE TRAP: AddExclusion and AlertOnly rebuild the row from scratch, silently dropping a previously set ShowInLicenseDropdown flag — re-apply it with SetShowInDropdown afterwards. skuName is stored as the display name (the response's Product_Display_Name). ACCESS NOTE: admin/superadmin CIPP API clients only.

[CIPP] List the SKUs CIPP excludes from its licence reporting, via GET /api/ListExcludedLicenses (no parameters — this is a CIPP instance setting, not per-tenant). Returns rows with GUID, Product_Display_Name, ExcludedEverywhere, ShowInLicenseDropdown, and a derived ExclusionType ('Excluded Everywhere' or 'Excluded from Alerts Only'). CIPP auto-seeds its 26-entry default list (mostly free/trial SKUs) when the table is empty. ACCESS NOTE: CIPP's role model grants CIPP.AppSettings.* only to admin and superadmin API clients — a readonly- or editor-role CIPP credential gets Access denied on this endpoint even though it is a read.

[CIPP] Look up external tenant information by domain or tenant ID. Returns organization name, tenant ID, and federation status.

[CIPP] CIPP's licence report for a tenant: SKU name, total units, consumed units, and available units. NOT necessarily every licence in the tenant — the report reflects CIPP's excluded-licences setting (CIPP ships a 26-SKU default exclusion list, typically free/trial SKUs). Use cipp_list_excluded_licenses to see exactly which SKUs are excluded. includeExcluded is a TWO-CONDITION gate on CIPP's side: an excluded SKU appears only when includeExcluded is true AND that SKU is marked ShowInLicenseDropdown in CIPP's exclusion settings (no default exclusion row is) — mark specific SKUs with cipp_exec_exclude_licenses action SetShowInDropdown first, or the flag changes nothing.

[CIPP] List the OAuth application grants in a tenant. Each row carries Name, ApplicationID, ObjectID, Scope (the delegated permissions, comma-joined) and StartTime. Two optional filters narrow the response: 'nameFilter' is a case-insensitive SUBSTRING match on Name, and 'appId' is a case-insensitive EXACT match on either ApplicationID or ObjectID. BOTH are applied by StackJack to the response and are NOT sent to CIPP, which takes tenantFilter and nothing else on this endpoint. When both are given, a row must satisfy both. With neither set the response is byte-for-byte what CIPP sent. No match returns an empty array [], which means nothing matched your filter, NOT that the tenant has no OAuth grants.

[CIPP] List current M365 service health status for a tenant. Returns service name, status, and any active incidents or advisories.

[CIPP] List tenant alignment status — how each tenant's configuration compares to the standards templates applied to it — via GET /api/ListTenantAlignment. This report is ESTATE-WIDE by design: CIPP's entrypoint never reads a tenant (its own alignment page renders with no tenant selected), so the result is one row per tenant per standard for every tenant CIPP manages. The tenantFilter argument is accepted and forwarded but CIPP does not apply it; filter the rows on your side. Returns raw CIPP JSON.

[CIPP] List tenant onboarding status and progress via GET /api/ListTenantOnboarding. Spec marks the body required even on this GET endpoint — the request must carry a JSON object. Spec body keys (mixed casing): 'gdapRoles' (camelCase array), 'id' (lowercase, the onboarding job id), 'ignoreMissingRoles' (camelCase boolean), 'remapRoles' (camelCase boolean), 'standardsExcludeAllTenants' (camelCase boolean). Returns onboarding steps, completion state, and any pending actions.

[CIPP] List all M365 tenants managed by this CIPP instance via POST /api/ListTenants. Invoke-ListTenants reads EXACTLY TWO body keys — 'ClearCache' and 'TenantsOnly' — and this tool sends NEITHER, because clearing CIPP's cache is a write and this is the read-only discovery tool; use cipp_clear_tenant_cache when you need a fresh enumeration. Every real filter/refresh knob is read off the QUERY string instead (AllTenantSelector, IncludeOffboardingDefaults, TriggerRefresh, TenantFilter/tenantFilter, Mode), and StackJack's client sends NO query string on this endpoint, so none of them can be supplied through this tool — the CIPP call is always a full enumeration. NARROWING IS THEREFORE CLIENT-SIDE, and this tool now does it for you: 'domainFilter' drops non-matching tenants and 'slim' reduces each remaining tenant to displayName + defaultDomainName + customerId. Both run in StackJack AFTER the full response arrives — they change what you receive, never what CIPP computes or bills, and they cannot reach a tenant the connected CIPP API client is not already allowed to see. USE THEM: a large CIPP instance answers with hundreds of tenants and tens of thousands of characters, which can exceed an MCP result budget for what is usually a single-tenant lookup. The shape is unchanged either way — still the raw JSON array CIPP returned, just with fewer elements and/or fewer keys per element. With neither argument set the response is byte-for-byte what CIPP sent. WARNING: 'integrationCompany' is different from both — it IS sent to CIPP and is NOT read anywhere in the endpoint, so it filters nothing and still returns every tenant. Returns tenant display name, default domain, and customer ID (plus the rest of CIPP's tenant record unless 'slim' is set). Use this first to discover available tenants and their domain filters.

[CIPP] Onboard a tenant to CIPP via POST /api/ExecOnboardTenant. Invoke-ExecOnboardTenant reads EXACTLY these body keys: 'id', 'Cancel', 'Retry', 'gdapRoles', 'addMissingGroups', 'ignoreMissingRoles', 'autoMapRoles', 'standardsExcludeAllTenants'. WARNING: 'remapRoles' is NOT read anywhere in the endpoint — an earlier version of this description listed it, but it is accepted and discarded. 'id' is a SCALAR STRING, not a {label,value} object: it goes through `ConvertTo-CIPPODataFilterValue -Type String` and becomes the table RowKey, so an object stringifies to something that matches no row and you get 'Onboarding job not found' or an unrelated new record — use the typed 'id' parameter below. 'gdapRoles' is likewise consumed as-is (assigned straight onto the orchestrator item), never unwrapped from a {label,value} envelope. WARNING: 'Retry' is evaluated as `[bool]$Request.Body.Retry`, and in PowerShell `[bool]'false'` is TRUE — sending the STRING "false" FORCES a retry of the onboarding; use the typed 'retry' parameter, which sends a real JSON boolean. 'Cancel' is compared with `-eq $true`, which behaves correctly for a real boolean and for the strings 'true'/'false' alike. NOT scoped via tenantFilter — onboarding identifies the relationship via 'id'. Pass keys verbatim — caller is responsible for exact spec casing.

[CIPP] Clear CIPP's cached tenant-capabilities data for ONE tenant via GET /api/RemoveTenantCapabilitiesCache, forcing CIPP to re-evaluate that tenant's features and permissions on the next request. The tenant is named by its DEFAULT DOMAIN NAME (e.g. contoso.onmicrosoft.com), not a customer id, and it rides the query string as 'defaultDomainName' — upstream reads the query only, never the body, and 400s with 'Missing required parameter: defaultDomainName' without it. A second upstream gate refuses with 403 when the calling CIPP client is not entitled to that tenant. Clearing the cache removes no configuration; the next request repopulates it.

[CIPP] Create an M365 organizational message in a tenant, TARGETED AT ONE ENTRA SECURITY GROUP, via GET /api/ExecSendOrgMessage. Every input rides the query string with these exact casings: TenantFilter, ID, type, URL, freq — the endpoint never reads the body. It is NOT organization-wide: 'id' is the Entra group whose members receive the message (upstream puts it in targeting.includeIds under targetingType 'aadGroup'), so a value that is not an Entra group id targets nobody. messageType is refused here before dispatch unless it is one of 'taskbar', 'notification' or 'getStarted', because upstream's switch has NO default arm and an unrecognised value sends an EMPTY message rather than failing. WARNING: 'getStarted' is an unfinished stub upstream — its two cards carry hardcoded placeholder text ('My Message Value' / 'This message' / 'PlzClick') and clickUrl 'https://example.com/clickUrl/', and it sets no guidedContentId, so sending it publishes placeholder content into the customer tenant; only 'taskbar' and 'notification' produce a real message. Upstream performs no input validation, and its catch block maps EVERY failure to HTTP 403 — a genuine Graph permission error, a group id that does not exist, and an unaddressed call are indistinguishable by status. Read the normalized Graph error in the response body to tell them apart.

[CIPP] Configure authentication method policies for a tenant via POST /api/SetAuthMethod. CIPP body keys are mixed: 'GroupIds' (PascalCase, string), 'Id' (PascalCase, the auth method policy ID, string), 'state' (lowercase, the enabled/disabled state, string), 'tenantFilter' (camelCase, required). Controls which Azure AD auth methods are available (FIDO2, Authenticator, SMS, etc.). Pass keys verbatim — caller is responsible for exact spec casing.

[CIPP] Start OR poll a Business Email Compromise (BEC) background check for a specific user. THIS TOOL WRITES — it is not a read: the start leg adds a 'Waiting' row to CIPP's BEC cache table and starts a BEC run orchestrator, and overwrite=true forces that queue-and-run branch even when a completed result is already cached. TWO-STEP: call it once WITHOUT guid to enqueue the job — that answers the acknowledgement envelope {"GUID":"<userId>"} — then call it again passing that same GUID value as guid to read the result. While the job is still running the poll answers {"Waiting":true}; once it completes the poll returns the findings. The job examines sign-in locations, inbox rules and rule changes, trusted/blocked sender and safelist changes, OneDrive/SharePoint sharing links, added applications, MFA methods, Intune devices, sent mail and tenant-wide password changes. It does NOT check mailbox-level forwarding (ForwardingSMTPAddress / ForwardingAddress) — check that separately; forwarding set via an inbox RULE does appear under the inbox-rule evidence. A completed check is served from CIPP's cache and is NOT re-run unless you pass overwrite=true. The full assessment is also readable in the CIPP UI.

[CIPP] Evaluate which conditional access policies would apply to a specific user, via GET /api/ListUserConditionalAccessPolicies. CIPP answers by POSTing Microsoft Graph's BETA Conditional Access What-If evaluation (identity/conditionalAccess/evaluate) app-only, and hands back whatever that returns. READ THE THREE EMPTY ANSWERS CAREFULLY, they mean different things: [] is a clean result meaning no policy applies to this user, while [] — an array holding one empty object — is CIPP reporting that its own Graph call FAILED. Upstream wraps that call in a catch which discards the error and substitutes an empty object, so the failure arrives as an HTTP 200 and nothing is written to CIPP's log; there is no record of the underlying error on either side. A third shape, [null], means the Graph call succeeded but returned no `value` member — upstream dereferences `.value` unconditionally and wraps the null. Only [] means 'no policy applies'; never read [] or [null] that way. The upstream body is passed through unchanged.

[CIPP] Get the profile photo for a specific user. Photos are binary, so this returns a JSON envelope carrying a short-lived read-only SAS URL to the image in blob storage — sasUrl, contentType, suggestedFileName, sizeBytes and expiresAt — not the image itself. The URL stops working at expiresAt. A user who has no photo produces an upstream error rather than an empty result.

[CIPP] List users who have basic authentication (legacy auth) enabled. These accounts are security risks and should be migrated to modern auth.

[CIPP] List soft-deleted users in the tenant recycle bin. These users can be restored within 30 days using cipp_restore_deleted_user.

[CIPP] List user accounts that have not signed in recently. Returns last sign-in date and account details for identifying stale accounts.

[CIPP] List all users with their MFA registration status and methods. Useful for identifying users without MFA configured.

[CIPP] List all users in a tenant including display name, UPN, license status, and account enabled state. Use this to discover user IDs for other user tools.

[CIPP] Invite an external guest user to the tenant via POST /api/AddGuest. The guest's email is sent as the spec key `mail` (NOT `email`); `displayName`, `redirectUri` and `message` are read as-is, and an omitted redirectUri defaults server-side to https://myapps.microsoft.com. WARNING about the invite email: CIPP computes it as `[System.Convert]::ToBoolean($Request.Body.sendInvite) ?? $true`, and `??` only replaces null — never false. An ABSENT sendInvite therefore converts to false and the `?? $true` cannot rescue it, so CIPP creates the guest object, sends NO invitation email, and still returns HTTP 200. That silent no-invite is the opposite of what an operator inviting a guest expects, so this tool ALWAYS sends `sendInvite` as a real JSON boolean (defaulting to true) rather than letting it be omitted. CIPP forwards the value to Graph as `sendInvitationMessage`.

[CIPP] Save a new Just-In-Time (JIT) admin template via POST /api/AddJITAdminTemplate. JIT templates pre-populate the cipp_jit_admin form (default user, roles, duration, expire action, etc.) so operators can elevate access with a single click. Body keys per spec: 'tenantFilter' (required), 'templateName' (string), 'defaultUserAction' (string enum: 'create' | 'select'), 'defaultFirstName' / 'defaultLastName' / 'defaultUserName' (strings), 'defaultDomain' / 'defaultDuration' / 'defaultExistingUser' / 'defaultExpireAction' / 'defaultRoles' (LabelValue {label,value} objects), 'defaultForTenant' (boolean), 'defaultNotificationActions' (string array, e.g., ['webhook','email','psa']), 'generateTAPByDefault' (boolean), 'reasonTemplate' (string). Use additionalFieldsJson to populate the LabelValue and array fields verbatim.

[CIPP] Create a new user in the tenant via POST /api/AddUser. CIPP composes the UPN from `username` + `PrimDomain.value` (LabelValue object). The displayName parameter maps to the spec key `DisplayName` (PascalCase). When userPrincipalName is provided as a full address (e.g., john.smith@contoso.com), the tool splits on '@' to populate `username` and `PrimDomain` automatically. Use additionalFieldsJson for license assignment, copyFrom (LabelValue), userTemplate (LabelValue), Scheduled, jobTitle, department, etc.

[CIPP] Create multiple users in a tenant in bulk via POST /api/AddUserBulk. Body keys: 'tenantFilter' (required), 'BulkUser' (PascalCase), 'licenses', 'usageLocation'. WARNING — `BulkUser` IS AN ARRAY OF JSON OBJECTS, NOT AN ARRAY OF STRINGS OR CSV ROWS. CIPP does `foreach ($User in $BulkUsers)` and reads typed properties off each element: `mailNickName` (required), `domain` (required), and at least one of `displayName` / `givenName` / `surname`; it also reads `password` and `businessPhones`. String elements expose none of those properties, so every element fails the missing-required-fields check and NO user is created — the call still returns HTTP 200 with per-user "Required fields missing for..." text in Results, so always read Results. Read it DEFENSIVELY: Results is an ARRAY of per-user entries only when BulkUser is non-empty. Omit BulkUser (or send an empty array) and CIPP answers 200 with Results as a single bare OBJECT {resultText:'No users specified to import', state:'error'}; a batch where every element fails validation yields a lone {resultText:'No users to import'} entry. Both 'licenses' and 'usageLocation' are dereferenced as `.value ?? <the value itself>`, so each accepts either a LabelValue {label,value} object or a bare value.

[CIPP] Save a new-user-creation defaults template for a tenant via POST /api/AddUserDefaults. Templates pre-populate licenses, groups, and profile settings for new users created through CIPP. Body keys per spec mix camelCase, PascalCase, and LabelValue objects: 'tenantFilter' (required), 'templateName' (camelCase), 'GUID' (PascalCase, optional template ID for updates), 'usernameFormat' (camelCase string template like '.'), 'defaultForTenant' (string), 'MustChangePass' (PascalCase boolean), 'removeLicenses' (camelCase boolean), 'licenses' (array of SKU IDs), 'displayName', 'givenName', 'surname', 'jobTitle', 'department', 'companyName', 'streetAddress', 'city', 'state', 'postalCode', 'country', 'mobilePhone', 'password', 'addedAliases', 'otherMails' (array). LabelValue objects: 'primDomain' {label,value}, 'usageLocation' {label,value}, 'copyFrom' {label,value}, 'setManager' {label,value}, 'setSponsor' {label,value}.

[CIPP] Execute Business Email Compromise remediation actions on a user via POST /api/ExecBECRemediate. The user's object ID maps to the spec key `userid` (lowercase) and the optional UPN maps to `username` (lowercase). Run cipp_bec_check first to assess the situation. Note: the spec body contains only userid/username/tenantFilter; specific remediation actions (reset password, revoke sessions, etc.) are configured via separate CIPP endpoints.

[CIPP] Change license assignments for several users in one call via POST /api/ExecBulkLicense. The body is a JSON ARRAY — one entry per user — forwarded verbatim; entries carry their OWN tenantFilter, so one call can span tenants. Per entry: tenantFilter (tenant domain or GUID — required; 'AllTenants' is documented in CIPP's spec but NOT implemented by the backend and is refused here), userIds (array — required; CIPP acts on only the FIRST entry, the rest are ignored), LicenseOperation ('Add' | 'Remove' | 'Replace' — required and validated here, because an unrecognized value makes the CIPP backend silently reuse the PREVIOUS entry's computed licenses against this user), RemoveAllLicenses / ReplaceAllLicenses (booleans — each is honored ONLY with its matching operation: RemoveAllLicenses with LicenseOperation 'Remove', ReplaceAllLicenses with 'Replace'; on any other operation CIPP silently ignores the flag, so this tool refuses the mismatch), and the license buckets Licenses (the add-set for both Add and Replace), LicensesToRemove, LicensesToReplace — each an array of {label, value} OBJECTS where value is the SKU id: CIPP reads .value, so bare SKU strings do not apply as licenses. Per-entry failures come back as HTTP 200 with text in Results — always read Results. Discover SKU ids with cipp_list_licenses.

[CIPP] Clear the on-premises immutable ID (sourceAnchor) for a user via POST /api/ExecClrImmId. Required when migrating from AD sync to cloud-only or when fixing sync conflicts. Body keys per spec: 'tenantFilter' (required) and 'ID' (UPPERCASE per spec, the user's object ID). The same 'ID' and 'tenantFilter' values also appear as query arguments per the spec.

[CIPP] Create a Temporary Access Pass (TAP) for a user via POST /api/ExecCreateTAP. TAPs allow passwordless onboarding or MFA recovery with a time-limited code. The user's object ID maps to the spec key `ID` (uppercase) and the validity duration maps to `lifetimeInMinutes` (NOT `lifetimeMinutes`). All values are string-typed per spec.

[CIPP] Change or delete a device registration in Azure AD / Entra ID via POST /api/ExecDeviceDelete. CIPP reads three body keys: `ID` (UPPERCASE — `$Request.Body.ID ?? $Request.Query.ID`), `action`, and `tenantFilter`. There is NO `deviceId` key, so a body naming the device as deviceId is silently dropped. `action` is NOT optional: Set-CIPPDeviceState declares it `[Parameter(Mandatory = $true)][ValidateSet('Enable','Disable','Delete')]`, so a call without it fails on parameter binding — this tool therefore always sends one, defaulting to 'Delete' to match this tool's name. 'Delete' issues a Graph DELETE on the device; 'Disable' and 'Enable' PATCH accountEnabled false/true instead, which is the reversible alternative to deletion. The ID must be a valid GUID — Set-CIPPDeviceState validates it and throws 'DeviceID must be a valid GUID.' otherwise.

[CIPP] Enable or disable a user account via POST /api/ExecDisableUser. The spec uses `Enable` (PascalCase, string-typed) to indicate the desired state — true enables, false disables. The user's object ID maps to the spec key `ID` (uppercase). Disabled users cannot sign in but their data is preserved.

[CIPP] Dismiss a user's risk state in Azure AD Identity Protection via POST /api/ExecDismissRiskyUser. Use after investigating and confirming the user is not compromised. Body keys per spec: 'tenantFilter' (required), 'userId' (camelCase), 'userDisplayName' (camelCase, optional, used for audit/notification).

[CIPP] Update an existing Just-In-Time (JIT) admin template via POST /api/EditJITAdminTemplate. Body keys per spec are identical to AddJITAdminTemplate plus 'GUID' (PascalCase, the template ID — required to identify which template to update). Use cipp_list_jit_admin_templates to find the GUID. Body keys: 'tenantFilter' (required), 'GUID' (PascalCase, required for edit), 'templateName' (string), 'defaultUserAction' (string enum: 'create' | 'select'), 'defaultFirstName' / 'defaultLastName' / 'defaultUserName' (strings), 'defaultDomain' / 'defaultDuration' / 'defaultExistingUser' / 'defaultExpireAction' / 'defaultRoles' (LabelValue {label,value} objects), 'defaultForTenant' (boolean), 'defaultNotificationActions' (string array), 'generateTAPByDefault' (boolean), 'reasonTemplate' (string). Use additionalFieldsJson to populate the LabelValue and array fields verbatim.

[CIPP] Edit properties of an existing user via PATCH /api/EditUser. READ THIS BEFORE INTERPRETING THE RESPONSE. Set-CIPPUser runs NINE independent halves — profile, password, licenses, aliases, CopyFrom group copy, group add, group remove, set manager, set sponsor — and none of them aborts the others. Most append their own outcome line to Results; the CopyFrom copy, set manager and set sponsor have no local catch and report through the helper they call instead. Results is therefore a MIXED report, not a verdict: never read the word 'Failed' appearing anywhere in it as 'my edit did not happen'. Branch on the line for the half you actually asked for — a successful licence change always begins 'Successfully set licenses for '. STATUS CODES: the call answers HTTP 200 carrying every half's outcome as text in Results, with exactly two exceptions — a blank or missing 'id' is refused up front with HTTP 400 {"Results":["Failed to edit user. No user ID provided"]} before anything runs, and HTTP 500 is returned when the scheduling branch's Add-CIPPScheduledTask throws or when Set-CIPPUser throws out of one of the three halves that have no local catch. SCHEDULED EDITS TAKE A DIFFERENT PATH ENTIRELY: send Scheduled.Enabled truthy and CIPP queues a task and answers 'Successfully created scheduled task to edit user <name>' — Set-CIPPUser does not run now, so none of the behaviour below applies until that task fires. KNOWN UPSTREAM DEFECT — A SPURIOUS PROFILE FAILURE ON EVERY EDIT THAT DOES NOT CHANGE THE PROFILE (CIPP-API @df3738d, Set-CIPPUser.ps1): CIPP composes the UPN UNCONDITIONALLY as username@(Domain, falling back to primDomain.value), with no guard on whether you sent those keys, and its non-empty-property filter drops only null/blank values — so with none of them supplied the literal string '@' survives into the Graph profile PATCH. Graph rejects that, and Results gains 'Failed to edit user. The domain portion of the userPrincipalName property is invalid...'. StackJack sends NO username, Domain, primDomain or userPrincipalName key unless YOU supply one, so that line is upstream noise rather than a sign your call was malformed. WHICH HALVES THAT EMPTY UPN ACTUALLY REACHES — this is what decides whether you may ignore it. (1) SAFE, ignore the line: group add and group remove key on the user's object id, not the UPN, so they are unaffected; licences also apply correctly and only the message is disfigured, reading 'Successfully set licenses for @.'. (2) NOT SAFE, PARTIAL APPLICATION: an alias edit adds each alias and THEN issues one final PATCH restoring the primary address to that same empty '@'. The restore fails, so Results shows 'Failed to add aliases to user <name>' and NO 'Success. Added aliases to user.' line — even though the aliases themselves are already on the account. Do not retry blindly; re-adding the aliases is not what is missing. (3) NOT SAFE: CopyFrom (group copy), setManager and setSponsor are each keyed on the empty UPN and cannot identify the user at all. DO NOT 'FIX' ANY OF THIS BY ADDING username + Domain TO A NON-PROFILE EDIT: that makes the UPN valid, which makes the profile PATCH SUCCEED, and it then writes userPrincipalName AND mailNickname (upstream sets mailNickname from username whenever you supply a non-empty one) on a call you meant as licences-only. mailNickname legitimately differs from the UPN local part after any rename, so that 'workaround' can silently change a sign-in address or alias. WHEN YOU ARE GENUINELY EDITING THE PROFILE (displayName, jobTitle, department, mobilePhone, address, company, otherMails, business phones, or a deliberate rename) you MUST include `username` (the user's CURRENT sign-in local part, before the @) and `Domain` (the sign-in domain), or that same composition sends a malformed UPN and Graph discards the ENTIRE profile half while the other halves run on independently. Pass the CURRENT local part unless you intend to rename the sign-in address, and do NOT pass a userPrincipalName field — it is not part of this endpoint's contract; the UPN comes from username@Domain. The user's object ID maps to the spec key `id` (lowercase) — pass the GUID/objectId or UPN. Spec key casing is mixed and intentional: top-level booleans like `Autopassword`, `MustChangePass`, `removeLicenses`, `sherweb` use varied casing per CIPP's contract. The `Scheduled` block carries {enabled, date}. Use fieldsJson for fields like DisplayName, jobTitle, department, mobilePhone, licenses (an array of {label,value} OBJECTS — CIPP reads .value, so bare SKU strings do not apply), AddToGroups (array), RemoveFromGroups (array), primDomain (LabelValue), usageLocation (LabelValue), setManager (LabelValue), setSponsor (LabelValue).

[CIPP] Add or remove email aliases (proxy addresses) for a user account via POST /api/EditUserAliases. Body keys: 'tenantFilter' (read from the BODY only — `$UserObj.tenantFilter`, with no query fallback), 'id' (lowercase, the user's object ID or UPN — CIPP rejects a blank/absent id), 'AddedAliases' and 'RemovedAliases' (PascalCase strings), 'MakePrimary' (PascalCase, alias address to promote to primary SMTP). WARNING — MULTIPLE ALIASES ARE COMMA-SEPARATED, NOT NEWLINE-SEPARATED. CIPP splits both lists with `($UserObj.AddedAliases -split ',')` and trims each part; it never splits on a newline. A newline-delimited string such as "a@contoso.com\nb@contoso.com" therefore survives as ONE element containing an embedded newline, so CIPP attempts a single malformed alias instead of the two you intended — and the failure lands as text inside the HTTP 200 Results envelope rather than as an error. Use "a@contoso.com,b@contoso.com" and read Results.

[CIPP] Enable or configure Just-In-Time (JIT) admin access for a user via POST /api/ExecJITAdmin. Grants temporary elevated privileges that expire after a set duration. The body uses 'tenantFilter' (required) plus a mix of PascalCase and camelCase keys; 'userAction' is an enum: 'create' | 'select'. Use fieldsJson to populate the body.

[CIPP] Look up Microsoft license SKU details by SKU IDs via POST /api/ExecLicenseSearch. Returns SKU display names, included service plans, and pricing metadata for each SKU ID supplied. NOTE: this endpoint is NOT tenant-scoped — it queries the global Microsoft license catalog, so no tenantFilter is sent. Body keys per spec: 'skuIds' (string — typically a comma-separated list of SKU GUIDs).

[CIPP] List currently active Just-In-Time admin sessions via GET /api/ListJITAdmin. Returns user, role, expiration, and status. Query: 'tenantFilter' (camelCase, REQUIRED). A single tenant is answered inline. Pass 'AllTenants' for the estate-wide view — at CIPP-API master @df3738d that value queues a DURABLE FAN-OUT across every managed tenant and answers ASYNCHRONOUSLY: unless CIPP already holds rows newer than 60 minutes, the first call (and every call while the job runs) returns an EMPTY 'Results' array plus a QueueId in 'Metadata'. On that path an empty Results means 'still loading', not 'no JIT admins'; poll cipp_get_queue_status with the QueueId and call again once it completes.

[CIPP] List available Just-In-Time admin templates. Returns template names, roles, and default durations.

[CIPP] List saved new user creation default templates. Returns template names, assigned licenses, groups, and profile settings.

[CIPP] List the trusted and blocked senders configured for ONE user via GET /api/ListUserTrustedBlockedSenders. Returns sender addresses and list type (trusted or blocked) from that mailbox's junk-email configuration. Query: 'tenantFilter' (camelCase) and 'UserID' (upstream's casing) — BOTH REQUIRED. Verified against CIPP-API master @df3738d, which anchors the Exchange lookup on the UserID; the tool sent neither value before 2026-09-03 and could not succeed under any input.

[CIPP] Run a multi-step user offboarding workflow against POST /api/ExecOffboardUser. Each action (license removal, mailbox conversion, access delegation, forwarding, session revocation, deletion, etc.) is a separate flag — set only the actions you want performed. This tool is destructive: it can permanently strip licenses, disable sign-in, convert the mailbox to shared, and delete the user. Confirm the UPN with cipp_list_users and inspect the user with cipp_get_user_mailbox before running. PRE-FLIGHT REFUSAL: CIPP validates the body before creating anything and answers HTTP 400 {"Results":[<errors>]} if tenantFilter is blank, if `user` resolves to no userPrincipalName, if Scheduled.enabled is true with an unparseable date, or if NO action flag was set — set at least one action or the call is refused outright. `user` accepts either bare UPN strings or {label,value} objects (upstream reads `$.value ?? $`); this tool sends the object form. WARNING — the response NEVER contains per-action outcomes, in EITHER mode. CIPP always routes this endpoint through Add-CIPPScheduledTask; scheduling only changes whether a ScheduledTime is attached (scheduled) or RunNow is requested (immediate). Both modes answer a task-CREATION acknowledgement, never license/mailbox/deletion results — but the two strings differ. An IMMEDIATE offboard (no scheduledRunAt) sets RunNow, so Add-CIPPScheduledTask creates the task AND queues Start-UserTasksOrchestrator for it straight away, answering "Task Offboarding: <upn> scheduled to run now". A SCHEDULED offboard answers "Successfully added task: <name>. It will run in <relative time>." Neither carries per-action outcomes: poll cipp_offboarding_job_status and re-check the user with cipp_list_users / cipp_get_user_mailbox. Use additionalFieldsJson only for forward-compatibility with new CIPP fields not yet exposed as typed parameters.

[CIPP] Get the status of queued CIPP offboarding jobs via GET /api/CIPPOffboardingJob. When cipp_offboard_user is called with a scheduledRunAt, the response is only a queue acknowledgement; use this tool to check the actual per-action results once the job runs. UPSTREAM-BROKEN: at CIPP-API master @df3738d there is no HTTP entrypoint by this name — the only CIPP function so named is an internal worker whose parameters cannot accept what CIPP's HTTP dispatcher passes it — so this tool is expected to FAIL until CIPP ships a route for it, and no parameter added on the StackJack side would change that.

[CIPP] Provision a OneDrive for Business site for a user via POST /api/ExecOnedriveProvision. Required before the user can access OneDrive. CIPP reads exactly two keys: `UserPrincipalName` (PASCALCASE — `$Request.Body.UserPrincipalName ?? $Request.Query.UserPrincipalName`) and `tenantFilter` (camelCase). There is NO `userId` key — a body identifying the user as userId is silently dropped and the provision runs with no target user, so this tool seeds the PascalCase key from its typed parameter.

[CIPP] Create a OneDrive shortcut for a user to a SharePoint site via POST /api/ExecOneDriveShortCut. CIPP reads exactly four body keys — `tenantFilter`, `username`, `userid` (ALL LOWERCASE — a camelCase `userId` is never read) and `siteUrl` — and forwards them unvalidated to New-CIPPOneDriveShortCut. TWO TRAPS. (1) `username` is THE identifier: the helper builds its Graph call as POST /beta/users//drive/root/children, so the UPN in `username` is what the shortcut is created for. `userid` is logged in the helper's opening message and NEVER referenced again — it cannot target the user on its own, which is why this tool requires username and treats userid as optional context. (2) `siteUrl` must be an OBJECT — it is dereferenced as `$Request.Body.siteUrl.value`, so a plain STRING resolves to $null; CIPP then matches no SharePoint site and fails loudly with HTTP 500 'Could not add OneDrive shortcut to <user> : Could not find a SharePoint site matching URL:'. Nothing is created. This tool always wraps the typed siteUrl into {label,value} for you. There is NO `libraryName` key — CIPP never reads one, so a library cannot be selected by name; pass the full site/library URL in siteUrl instead.

[CIPP] Set or unset the password-never-expires flag for a user account via POST /api/ExecPasswordNeverExpires. Body keys per spec (all camelCase): 'tenantFilter' (required), 'userId', 'userPrincipalName', 'PasswordPolicy' (PascalCase, controls the policy applied — typically 'DisablePasswordExpiration' or empty/null to re-enable expiration). Use fieldsJson to populate the body.

[CIPP] Apply partial updates to a user record via PATCH /api/PatchUser. The body schema is NOT open: CIPP normalizes the body to a list of user entries and hard-validates every one of them with `[string]::IsNullOrWhiteSpace(\(_.id) -or [string]::IsNullOrWhiteSpace(\)_.tenantFilter)`, answering HTTP 400 'Failed to patch user(s). Some users are missing id or tenantFilter' if either is blank or absent. Both are therefore REQUIRED, and this tool seeds them from typed parameters. `userPrincipalName` is NOT an accepted identifier — only `id` is. Everything else you pass is forwarded to Microsoft Graph as a user PATCH, EXCEPT four keys stripped by `Select-Object -ExcludeProperty id, tenantFilter, manager, sponsor`: id and tenantFilter are routing-only and never reach Graph, while `manager` and `sponsor` are pulled out and applied separately through CIPP's Set-CIPPManager / Set-CIPPSponsor helpers rather than being passed through as Graph properties. This tool sends ONE user object per call. NO-OP WARNING: after the strip, an entry with no remaining properties is SKIPPED and CIPP still answers HTTP 200. Since this tool always seeds exactly id + tenantFilter and both are stripped, an empty fieldsJson issues NO Graph PATCH at all and answers 'Successfully patched 0 users across 1 tenant' — note the singular 'tenant', CIPP pluralizes both nouns off their own counts. A body carrying only manager/sponsor likewise issues no Graph PATCH, but takes a different branch and answers the 'Successfully updated N manager assignment(s) across 1 tenant' variant instead. Read the count in Results, not just the 200.

[CIPP] Enable, disable, or enforce per-user (legacy) MFA for a specific user via POST /api/ExecPerUserMFA. Note: Conditional Access policies are the preferred MFA approach in modern tenants. IDENTIFIER CONTRACT — `userPrincipalName` is THE identifier, not a nicety: CIPP resolves the target as `$Request.Body.userPrincipalName -match '#EXT#' ? $Request.Body.userId : $Request.Body.userPrincipalName`, so `userId` is consulted ONLY for guest accounts whose UPN contains '#EXT#'. A body carrying only userId hands the downstream helper a null user for every non-guest, which is why this tool requires userPrincipalName and treats userId as the guest-only fallback. STATE — read as `$Request.Body.State.value ? $Request.Body.State.value : $Request.Body.State`, so a plain string works (this tool sends one). Set-CIPPPerUserMFA validates it against exactly 'enabled' | 'disabled' | 'enforced' and forwards it to Graph as `perUserMFAstate`. The helper's own `$State = 'enabled'` default is UNREACHABLE from this endpoint — the entrypoint always splats a State key, and an explicitly-passed null never falls back to a parameter default — so an omitted state is a hard failure (parameter-binding error surfaced as HTTP 500), not a silent enable. This tool requires an explicit state and refuses anything outside the three literals.

[CIPP] Permanently remove a soft-deleted object from the tenant recycle bin via POST /api/RemoveDeletedObject. WARNING: this permanently purges the object; it cannot be recovered afterwards. CIPP reads `ID` (UPPERCASE — `$Request.Query.ID ?? $Request.Body.ID`) as the identifier, plus `tenantFilter`, `userPrincipalName` and `displayName`. There is NO `objectId` key and NO `objectType` key — objectType is never read anywhere in the endpoint, so the object type cannot be selected through this call, and a body naming the target as objectId is silently dropped. Use cipp_list_deleted_users to find the ID.

[CIPP] Delete a Just-In-Time (JIT) admin template via POST /api/RemoveJITAdminTemplate. Body keys per spec: 'ID' (PascalCase, the template ID — required). NOTE: this endpoint does NOT take a tenantFilter (templates are partner-scope, not tenant-scope). Use cipp_list_jit_admin_templates to find the template ID before removing.

[CIPP] Remove an entry from a user's trusted or blocked senders list via POST /api/RemoveTrustedBlockedSender. CIPP reads exactly four body keys: `tenantFilter`, `userPrincipalName` (the mailbox to edit), `value` (the sender address or domain to remove), and `typeProperty` (which Set-MailboxJunkEmailConfiguration parameter to remove it from). NONE of 'userId', 'sender' or 'listType' is read by CIPP — a body using those names leaves all three parameters null and the call does nothing useful, which is why this tool seeds the real keys from typed parameters. Use cipp_list_user_trusted_blocked_senders to see the current entries before removing one.

[CIPP] Delete a user from the tenant via POST /api/RemoveUser. The user is soft-deleted and recoverable for 30 days through cipp_restore_deleted_user. WARNING: this permanently deletes the user account. Use cipp_disable_user for temporary suspension instead. Body keys per spec: 'tenantFilter' (required), 'ID' (UPPERCASE, the user's object ID), 'userPrincipalName' (camelCase, optional UPN used for audit/notification). The same 'ID', 'tenantFilter', and 'userPrincipalName' values can also appear as query arguments per the spec.

[CIPP] Remove a saved new-user defaults template via POST /api/RemoveUserDefaultTemplate. CIPP reads exactly ONE key — `ID` (UPPERCASE), as `$Request.Query.ID ?? $Request.Body.ID`. There is NO `templateId` key: a body naming the template as templateId leaves ID unset, and CIPP then fails the GUID sanitizer with HTTP 500 'Invalid GUID format for OData filter' rather than acting on anything. ID must be a hyphenated 8-4-4-4-12 GUID, in either case — the sanitizer matches with `-notmatch`, not `-cnotmatch`, so an uppercase GUID passes; what it rejects is a blank, brace-wrapped, or otherwise non-GUID value. A well-formed ID matching no template answers HTTP 404. `tenantFilter` is not referenced anywhere in this endpoint — templates are partner-scope, so no tenant is sent. Use cipp_list_new_user_defaults to find the template ID.

[CIPP] Reprocess license assignments for a user to fix license provisioning errors or stale service plan states, via POST /api/ExecReprocessUserLicenses. CIPP reads `ID` (UPPERCASE — `$Request.Query.ID ?? $Request.Body.ID`), `tenantFilter`, and `userPrincipalName`. Only ID reaches Graph (it builds /beta/users//reprocessLicenseAssignment); `userPrincipalName` is interpolated into the result text for logging ONLY and never identifies the user. There is NO `userId` key — a body identifying the user as userId is silently dropped and the call runs with an empty user segment, so this tool seeds the uppercase key from its typed parameter.

[CIPP] Reset MFA registration for a user via POST /api/ExecResetMFA, requiring them to re-register their authentication methods on next sign-in. The user's object ID maps to the spec key `ID` (uppercase).

[CIPP] Reset a user's password via POST /api/ExecResetPass. CIPP generates a new random password server-side; the spec does not accept a caller-supplied password. The user's object ID maps to the spec key `ID` (uppercase). The mustChange flag (sent as `MustChange` PascalCase, string-typed per spec) controls whether the user must change the password on next sign-in.

[CIPP] Restore a soft-deleted user from the tenant recycle bin via POST /api/ExecRestoreDeleted. Users can be restored within 30 days of deletion. The user's object ID maps to the spec key `ID` (uppercase). Use cipp_list_deleted_users to find restorable users.

[CIPP] Revoke all active sessions and refresh tokens for a user via POST /api/ExecRevokeSessions, forcing re-authentication on all devices. The spec uses `id` (lowercase) for the user object ID and `Username` (PascalCase) for the optional UPN. Pass userId for the GUID and optionally username for the UPN.

[CIPP] Send a test push notification to a user's registered Microsoft Authenticator MFA device via POST /api/ExecSendPush. Body keys per spec (PascalCase): 'TenantFilter' (required, PascalCase!) and 'UserEmail' (PascalCase, the UPN of the target user). NOTE: this endpoint's body uses PascalCase 'TenantFilter' while the query argument added by the client is camelCase 'tenantFilter' — the tool merges fieldsJson so the caller can override with the correct key.

[CIPP] Set a directory object's on-premises sync behaviour via POST /api/ExecSetCloudManaged — CIPP PATCHes /beta/{users|groups|contacts}//onPremisesSyncBehavior with {"isCloudManaged": <bool>}. Besides `tenantFilter`, CIPP reads four body keys: `ID` (UPPERCASE), `type`, `isCloudManaged`, `displayName` — there is NO `userId` key, so a body naming the target as userId is silently dropped. TWO DANGEROUS DEFAULTS this tool now closes. (1) DIRECTION: CIPP computes `[System.Convert]::ToBoolean($Request.Body.isCloudManaged)`, and Convert.ToBoolean(null) is FALSE — so an ABSENT isCloudManaged means 'on-premises managed', the exact OPPOSITE of converting an object to cloud-managed. This tool always sends a real JSON boolean, defaulting to true. (2) TARGET: Set-CIPPCloudManaged declares `[ValidateSet('User','Group','Contact')][string]$Type` and picks its Graph URI from a switch over those three with no default arm. An absent or unrecognized type is rejected at parameter binding before the switch runs, so the call fails with HTTP 500 rather than acting — this tool defaults type to 'User', normalizes the casing, and refuses anything outside that set. That matters because fieldsJson merges LAST and can override `type`. Despite the upstream variable being named $GroupID, the endpoint serves users, groups and contacts alike — the type key is what selects which.

[CIPP] Set or remove the profile photo for a user via POST /api/ExecSetUserPhoto. Body keys (all camelCase, each also accepted as a query argument except photoData): 'tenantFilter', 'userId' (the user's object ID or UPN), 'action', 'photoData' (base64-encoded image bytes, read from the BODY only and required when action='set'). ACTION VALUES — CIPP branches on exactly `if ($action -eq 'remove')` / `elseif ($action -eq 'set')` and otherwise hits `throw "Invalid action. Must be 'set' or 'remove'"`. The only two accepted values are therefore 'set' and 'remove'; 'upload' and 'delete' are NOT accepted and every such call throws. This tool maps the legacy 'upload'/'delete' spellings onto 'set'/'remove' and refuses anything else before dispatch.

[CIPP] Create a new group in the tenant via POST /api/AddGroup. Upstream normalizes 'groupType' with a case-insensitive wildcard switch into exactly seven kinds, and the kind decides which API creates the group. Graph POST /groups: 'generic' (plain Entra security group — securityEnabled, NOT mail-enabled), 'azurerole' (role-assignable), 'dynamic' (membershipRule), 'm365' (Unified). Exchange Online: 'distribution' (New-DistributionGroup), 'dynamicdistribution' (New-DynamicDistributionGroup), and 'security'. TRAP: 'security' does NOT create a plain security group — it goes through New-DistributionGroup -Type Security, i.e. a MAIL-ENABLED security group; the plain Entra security group is 'generic'. Kinds needing an address ('m365', 'distribution', 'dynamicdistribution', 'security') build it as username@primDomain.value, or take 'primaryEmailAddress' verbatim. Optional body keys upstream actually reads: allowExternal, aliases, description, disableNesting, hideFromGAL, licenses, members, membershipRules, owners, primaryEmailAddress, primDomain, subscribeMembers, username. CIPP caches creations for 10 minutes per tenant+displayName (cache RowKey = '<tenant>_<displayName with every character other than a letter, digit or hyphen replaced by _>') and SKIPS a repeat instead of creating a second group — but the response does NOT say so: the endpoint answers 'Successfully created group <displayName> for <tenant>' either way, so a de-duplicated call is indistinguishable on the wire from a real creation. Confirm with cipp_list_groups if the distinction matters.

[CIPP] Save a group template for reuse via POST /api/AddGroupTemplate. The body has NO 'tenantFilter' — templates are tenant-agnostic. 'displayName' and 'groupType' are BOTH required: displayName is validated explicitly (upstream throws 'You must enter a displayname'), and groupType is required implicitly because upstream calls .ToLower() on it unguarded — omit it and the call answers HTTP 200 with Results = 'Group Template Creation failed: You cannot call a method on a null-valued expression.'. CIPP reads the body case-insensitively, so displayName / displayname / Displayname are the SAME key and none of them is case-critical. The stored template keeps exactly: displayName, description, groupType, membershipRules, allowExternal, username, licenses, aliases, hideFromGAL and GUID — anything else you send (notably 'subscribeMembers', 'members', 'owners', 'primDomain') is silently DROPPED, so a template can never carry it. groupType is normalized upstream to one of 'generic' | 'security' | 'azureRole' | 'dynamic' | 'dynamicDistribution' | 'm365' | 'distribution'; a value matching none of the wildcard arms is stored VERBATIM rather than normalized, and New-CIPPGroup's own default arm would later send that stored value down the Exchange distribution path. Note that supplying a non-empty membershipRules FORCES groupType to 'dynamic' unless it resolved to 'dynamicDistribution'. 'GUID' is optional and defaults to a fresh one — passing an EXISTING template's GUID overwrites that template in place rather than adding one. Failures are returned at HTTP 200 as a 'Group Template Creation failed: ...' Results string, so read Results rather than the status code.

[CIPP] Convert an existing M365 group into a Microsoft Teams team via POST /api/AddGroupTeam. The group must be an M365 (Unified) group. CIPP PUTs the TeamSettings value straight to https://graph.microsoft.com/beta/groups/{GroupId}/team as the request body, so TeamSettings must be a JSON OBJECT — omit it and CIPP supplies its own default object (memberSettings.allowCreatePrivateChannels/allowCreateUpdateChannels, messagingSettings.allowUserEditMessages/allowUserDeleteMessages, funSettings.allowGiphy/giphyContentRating='strict'). Body keys read: TenantFilter, GroupId, TeamSettings (CIPP reads the body case-insensitively). A group created less than ~15 minutes ago commonly fails with a replication-delay 404 that CIPP reports as 'The group may have been created too recently' — retry later rather than recreating the group. This endpoint ALWAYS answers HTTP 200: every failure, the replication 404 included, arrives only as a text line inside Results, so read Results rather than the status code.

[CIPP] Delete a group from a tenant via POST /api/ExecGroupsDelete. WARNING: this permanently deletes the group; for M365 groups Microsoft also removes the associated SharePoint site, Teams team and mailbox. groupType is a CLOSED vocabulary — 'Distribution List' and 'Mail-Enabled Security' are removed with Remove-DistributionGroup (BypassSecurityGroupManagerCheck), 'Microsoft 365' and 'Security' with a Graph DELETE (a 'Security' group has its assigned licenses stripped first). WARNING: upstream matches that vocabulary with a plain if/elseif and has NO else — any other value deletes NOTHING, raises no error and still answers HTTP 200 with a null result, which is indistinguishable from a real deletion. That is why an unrecognized groupType is refused here before dispatch. Body keys: tenantFilter, GroupType, id, displayName (CIPP reads the body case-insensitively; only tenantFilter is also on the query string).

[CIPP] Edit properties of an existing group via PATCH /api/EditGroup. Required body key: 'tenantFilter'. Key casing is NOT load-bearing — CIPP re-serializes the request so every body lookup is case-insensitive — but the spellings below are CIPP's own. Membership change keys — 'AddContact', 'AddMember', 'AddOwner', 'RemoveContact', 'RemoveMember', 'RemoveOwner', and 'AddDevice' — are arrays of OBJECTS carrying {"value":"<directory object id>"}, NOT arrays of UPN strings; ONLY 'AddMember' also accepts a bare UPN string, which CIPP resolves to an object id with a Graph lookup. 'AddLicenses' / 'RemoveLicenses' (arrays of {"value":"<skuId>"} objects or bare sku-id strings) are processed ONLY when the group resolves to 'Security'. Other body keys: 'allowExternal' (boolean — REQUIRES 'mail' in the same body), 'description' (string), 'displayName' (string), 'groupId' (object, the target group identifier), 'groupName' (string), 'groupType' (string — advisory: CIPP re-derives the kind from a live Graph lookup of the group), 'hideFromOutlookClients' (boolean), 'mail' (string), 'mailNickname' (string), 'membershipRules' (string), 'securityEnabled' (boolean — written only alongside displayName / description / mailNickname / membershipRules), 'sendCopies' (boolean), 'visibility' (string). Read Results, not the status code — and read each line's TEXT, never its prefix: every per-operation failure rides inside HTTP 200, most as an 'Error - ...' line, but the allowExternal, visibility, sendCopies and hideFromOutlookClients stages and the RemoveContact refusal report a bare 'Failed to ...' / 'You cannot ...' line with no prefix, and several successes carry no 'Success - ' prefix either, so never gate on the prefix. A body that matches no block writes nothing and still answers 200 with an empty Results array. 'tenantId' (string) is ALSO a body key but it is NOT a group property: it is a tenant-routing selector — upstream reads `tenantId ?? tenantFilter` for the member/device/owner/contact work, the licence assignment, allowExternal, visibility, sendCopies and hideFromOutlookClients, and for BOTH bulk executions themselves, while only the initial group lookup and the Graph property PATCH read tenantFilter. Leave it unset; the tool seeds tenantFilter so both reads agree.

[CIPP] Set whether a distribution or Microsoft 365 group accepts mail only from internal senders via POST /api/ExecGroupsDeliveryManagement (it writes RequireSenderAuthenticationEnabled). groupType is a CLOSED vocabulary: 'Distribution List' and 'Mail-Enabled Security' go through Set-DistributionGroup, 'Microsoft 365' through Set-UnifiedGroup, and 'Security' is REFUSED upstream with a loud error (the setting does not exist on a security group). WARNING: any value outside that vocabulary matches no branch upstream, runs no cmdlet, and still returns 'Successfully set ... group ...' at HTTP 200 — a silent no-op that reads as success; such values are therefore refused here before dispatch. onlyAllowInternal is sent as a REAL JSON boolean: upstream binds it to a [bool] parameter, and PowerShell casts ANY non-empty string to true, so the string "false" would enable sender authentication — the exact opposite of what it says. Body keys: tenantFilter, GroupType, ID, OnlyAllowInternal (CIPP reads the body case-insensitively; only tenantFilter is also on the query string).

[CIPP] Show or hide a group in the Global Address List via POST /api/ExecGroupsHideFromGAL (it writes HiddenFromAddressListsEnabled). groupType is a CLOSED vocabulary: 'Distribution List' and 'Mail-Enabled Security' go through Set-DistributionGroup, 'Microsoft 365' through Set-UnifiedGroup, and 'Security' returns a refusal string at HTTP 200 ('cannot have this setting changed'). WARNING: any value outside that vocabulary matches no branch upstream, runs no cmdlet, and still returns 'Successfully hidden/unhidden ... from GAL' at HTTP 200 — a silent no-op that reads as success; such values are therefore refused here before dispatch. hideFromGal is sent as the string literal 'true' or 'false'. Upstream binds the value to a [string] parameter and tests `-eq 'true'` case-insensitively, so the string 'true' AND a real JSON boolean true (which binds as 'True') both HIDE, while everything else — 'yes', '1', an empty value, a JSON boolean false — SHOWS. Body keys: tenantFilter, GroupType, ID, HideFromGAL (CIPP reads the body case-insensitively; only tenantFilter is also on the query string).

[CIPP] Report whether external senders may email ONE group, via GET /api/ListGroupSenderAuthentication. This answers for a single named group, not a list: all three inputs are required and ride the query string — tenantFilter (query key 'TenantFilter'), groupId (query key 'groupid') and groupType (query key 'Type'). Verified against CIPP-API master @df3738d: upstream acts only on groupType 'Distribution List' (Exchange, Get-DistributionGroup) and 'Microsoft 365' (Exchange too, Get-UnifiedGroup) — both read the SAME RequireSenderAuthenticationEnabled property, which the endpoint flips into `allowedToReceiveExternal`. Every other value falls to a default arm that answers the CONSTANT {"allowedToReceiveExternal": false} without looking at the group at all, and so does the catch, so a value outside those two — or an Exchange failure — produces a fabricated answer rather than an error. Use cipp_list_groups to obtain a group id and its calculatedGroupType.

[CIPP] List saved group templates. Returns template names, group types, and configured settings.

[CIPP] List all groups in a tenant including security groups, distribution lists, M365 groups, and mail-enabled security groups. Returns group name, type, email, and member count.

[CIPP] List all directory roles in a tenant including role name, description, and assigned members. Useful for auditing admin access.

[CIPP] Remove a saved group template via POST /api/RemoveGroupTemplate. Templates are tenant-agnostic, so there is no tenantFilter. The only key read is 'ID' — the template's GUID (upstream sanitizes it as a Guid before building the table filter), which is the template row's RowKey as returned by cipp_list_group_templates. This client sends NO query string at all, so the value travels in the body only; CIPP reads the body case-insensitively, so 'ID' and 'id' are the same key.

[CIPP] Run an Exchange Online mail-flow / connectivity diagnostic via GET /api/ExecMailTest. Per spec the endpoint accepts a single query parameter 'Action' selecting which test to run, but the current CIPP client method is parameterless — this tool calls the endpoint without arguments and CIPP runs its default test. Read-only diagnostic; no mailbox state is changed.

[CIPP] Get mobile devices connected to a specific mailbox via ActiveSync or Outlook Mobile. Returns device name, OS, last sync time, and access state.

[CIPP] Inbox rules for EVERY mailbox in a tenant, via GET /api/ListMailboxRules. This is a TENANT-WIDE cached report, not a per-mailbox lookup — for one mailbox use cipp_list_user_mailbox_rules instead. ASYNCHRONOUS by default: when CIPP holds no cached rows less than an hour old it starts a background job that walks every mailbox in the tenant and answers immediately with {"Metadata":{"QueueMessage":"...","QueueId":"..."},"Results":[]}. Poll by REPEATING THIS EXACT CALL until Results is populated; the cache then serves for an hour. Getting the SAME QueueId back on a repeat means CIPP's job is STILL RUNNING — a newly started job would carry a new id — and a tenant-wide enumeration routinely takes minutes; pass that id to cipp_get_queue_status for its task counts and status. Set useReportDB=true to read CIPP's reporting database synchronously instead, which skips the queue entirely — but note that the RESPONSE SHAPE CHANGES on that branch: it returns a BARE JSON ARRAY of rows with no 'Results' key and no 'Metadata' at all, so the polling rule above does not apply to it, and a failure there comes back as HTTP 500 rather than the 403 the cached/queued path answers with. Verified against CIPP-API master @df3738d.

[CIPP] Run a read-only Exchange Online PowerShell cmdlet via POST /api/ListExoRequest and return its raw output. Lets callers query EXO data not exposed by a dedicated CIPP endpoint. THE TENANT IS BODY-ONLY: CIPP reads it from the 'TenantFilter' body key and never reads any query argument, so the tenant cannot be supplied out-of-band. Body keys (mixed casing, verified against upstream): 'TenantFilter' (PascalCase, required — the only tenant source), 'Cmdlet' (PascalCase, the EXO cmdlet name, e.g., 'Get-Mailbox', 'Get-CASMailbox'), 'cmdParams' (camelCase, a JSON OBJECT of cmdlet parameter name/value pairs that CIPP splats onto the cmdlet), 'Select' (PascalCase, comma-separated property selector), 'AsApp' (PascalCase, real JSON boolean — runs as the app identity), 'Compliance' (PascalCase, real JSON boolean — routes via the Security/Compliance endpoint instead of EXO), 'Anchor' (PascalCase, anchor mailbox identifier for cmdlet routing), 'AvailableCmdlets' (PascalCase, real JSON boolean — see the WARNING below), 'UseSystemMailbox' (PascalCase — accepted but effectively INERT upstream; forwarded only when true, with no observable effect on the cmdlet that runs). The casing split between Cmdlet (Pascal) and cmdParams (camel) is upstream's, not a typo. VERB REALITY — CIPP accepts ONLY two verbs, Get-* and Search-, and answers anything else with HTTP 400 'Invalid cmdlet: <name>'. StackJack narrows that further: only canonical Get-<Noun> is usable. Search- is refused locally on purpose (Search-Mailbox -DeleteContent purges mail). WARNING: Find-<Noun> still passes StackJack's local gate for historical reasons but NO Find-* cmdlet can ever succeed — CIPP rejects every one with HTTP 400. Do not use Find-; use Get-. Aliases, module qualifiers and shell metacharacters are refused before the request is sent. Mutating cmdlets (Set-/Remove-/Add-/New-/Disable-/Enable-) require a dedicated tool. WARNING — 'AvailableCmdlets' is a MODE SWITCH, not a hint: when true, CIPP ignores Cmdlet, cmdParams, Select, Anchor and UseSystemMailbox entirely, never runs the requested cmdlet, and returns HTTP 200 carrying a list of cmdlet NAMES. That success-shaped response is indistinguishable from a real result to a caller who did not expect it, so leave availableCmdlets unset unless you specifically want to enumerate cmdlet names.

[CIPP] List entries in ONE tenant's Global Address List (GAL) via GET /api/ListGlobalAddressList. Returns all mail-enabled recipients visible in that organization's address book. Query: 'tenantFilter' (camelCase, REQUIRED). Verified against CIPP-API master @df3738d: with no tenant CIPP's Exchange helper substitutes the CIPP installation's own partner tenant, so a call without one returns partner data or nothing at all — never the tenant that was meant.

[CIPP] List mailbox forwarding configuration across the tenant via GET /api/ListMailboxForwarding. Reports each mailbox's ForwardingAddress / ForwardingSmtpAddress and whether DeliverToMailboxAndForward is set, plus inbox-rule-driven forwarding. Critical for BEC investigation. Spec query: 'tenantFilter' (required), 'UseReportDB' (string 'true'/'false' — when 'true', CIPP serves the cached/aggregated report DB instead of querying live; default lives behavior).

[CIPP] List ONE tenant's pending and completed mailbox restore requests via GET /api/ListMailboxRestores. Returns restore status, source, target, and completion percentage. Query: 'tenantFilter' (camelCase, REQUIRED). Verified against CIPP-API master @df3738d: the tenant is passed straight to Exchange Online, and without one CIPP substitutes its own partner tenant, so the intended tenant is never queried.

[CIPP] List all mailboxes in a tenant including user, shared, and resource mailboxes. Returns display name, primary SMTP address, mailbox type, and size.

[CIPP] Retrieve ONE quarantined message via GET /api/ListMailQuarantineMessage. Returns the raw message content for the quarantined item named by identity. Query: 'tenantFilter' (camelCase) and 'Identity' (PascalCase upstream) — BOTH REQUIRED. Verified against CIPP-API master @df3738d, which runs Export-QuarantineMessage anchored on that identity; the tool sent neither value before 2026-09-03 and could not succeed under any input. Use cipp_list_quarantine to list a tenant's quarantined messages and read the identity of the one you want.

[CIPP] List users who have been restricted from sending email due to suspected spam or compromise. Use cipp_remove_restricted_user to unblock.

[CIPP] List the shared mailboxes in one tenant that still have sign-in enabled. A shared mailbox with an enabled account is a security risk because it can be used for a direct login. The tenant is required: CIPP builds its Exchange and Graph reads from it and fails with a 500 when it is missing.

[CIPP] Inbox rules for ONE mailbox, via GET /api/ListUserMailboxRules. This is THE per-mailbox inbox-rule route and it answers SYNCHRONOUSLY — no queue and no cache: CIPP runs Get-InboxRule -IncludeHidden against the mailbox named by userId and returns its rules, hidden ones included. It then drops two built-ins from the answer, the 'Junk E-Mail Rule' and the out-of-office rules, so a count one or two short of the Exchange admin console is expected rather than a gap. Both tenantFilter and userId are REQUIRED: with no user CIPP anchors on an empty mailbox, Exchange Online answers 404 and the call comes back as HTTP 500. For the tenant-wide cached report across every mailbox, use cipp_get_mailbox_rules.

[CIPP] Create a new shared mailbox via POST /api/AddSharedMailbox. Shared mailboxes do not require a license and can be accessed by multiple users. The primary SMTP address is constructed by CIPP as username@domain. The tenant is carried by body key 'tenantID' — the ONLY tenant input this CIPP endpoint reads; the tool sends it automatically (from tenantID, or tenantFilter when tenantID is omitted). WARNING: with an unresolvable tenant value, CIPP creates NOTHING and still answers HTTP 200 with 'Successfully created shared mailbox' (upstream defect, reported) — so prefer the tenant GUID and confirm with cipp_list_mailboxes when in doubt.

[CIPP] Convert a mailbox between types via POST /api/ExecConvertMailbox. Shared mailboxes under 50GB do not require a license. Valid MailboxType values: 'UserMailbox', 'SharedMailbox', 'RoomMailbox', 'EquipmentMailbox'.

[CIPP] Configure whether items sent on behalf of a mailbox by a delegate are also copied to the mailbox owner's Sent Items folder via POST /api/ExecCopyForSent. It is a single on/off switch — the one value sets both MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled. Body keys: 'tenantFilter' (required), 'ID' (UPPERCASE, the mailbox owner's user object ID or UPN), 'messageCopyState' (REQUIRED). WARNING — messageCopyState is NOT an 'Enabled'/'Disabled' enum: upstream runs it through [System.Convert]::ToBoolean, which accepts only a real JSON boolean or the strings 'True'/'False' (case-insensitive) and throws a FormatException on any other non-empty string. That conversion sits OUTSIDE the endpoint's try block, so 'Enabled' or 'Disabled' produces an unhandled Azure Function error, not the {"Results":...} envelope this tool otherwise returns. WARNING — OMITTING messageCopyState is not a no-op and not an error, it is an unrequested WRITE: [System.Convert]::ToBoolean(null) returns false WITHOUT throwing, so a body of {"ID":"user@contoso.com"} reaches Set-CIPPMessageCopy with MessageCopyForSentAsEnabled=false AND MessageCopyForSendOnBehalfEnabled=false — it silently turns delegate sent-item copies OFF and answers HTTP 200. Always send an explicit true/false. Verified against CIPP-API master @df3738d.

[CIPP] Grant, change, or revoke a delegate's access to a mailbox's calendar folder via POST /api/ExecEditCalendarPermissions. RUNTIME CONTRACT: CIPP's live backend consumes the exact autocomplete objects its own React UI emits — it unwraps `$Request.Body.Permissions.value`, `$Request.Body.UserToGetPermissions.value`, and `$Request.Body.RemoveAccess.value`. Sending those fields as BARE STRINGS makes the backend read $null and fail with `Cannot convert value "System.String[]" to type MailboxFolderAccessRight[]`. This tool builds the backend-compatible {value,label} object shape (and a real JSON boolean for CanViewPrivateItems) from the typed parameters below, so callers pass plain strings/booleans. To GRANT or CHANGE access leave removeAccess=false and supply permissionLevel; to REVOKE access set removeAccess=true (permissionLevel/canViewPrivateItems are then ignored). Response is CIPP's raw {"Results":[...]} envelope (HTTP 200 even on per-operation failure). Use additionalFieldsJson only for forward-compatibility with new CIPP fields.

[CIPP] Add or remove mailbox permissions (Full Access, Send As, Send on Behalf) on a mailbox via POST /api/ExecEditMailboxPermissions. NOTE: the body uses lowercase 'tenantfilter' and uppercase 'userID' — these casings are intentional and must not be normalized.

[CIPP] Enable the online archive mailbox for a user via POST /api/ExecEnableArchive. Archive mailboxes provide additional storage and auto-expanding archive capabilities. Provide either 'username' (UPN) OR 'id' (object ID) — supplying both is allowed but redundant.

[CIPP] Enable auto-expanding archive for a mailbox via POST /api/ExecEnableAutoExpandingArchive. Allows the archive mailbox to grow beyond the initial 100 GB limit by adding additional auxiliary archive mailboxes as needed. Body keys per spec: 'tenantFilter' (required), 'ID' (UPPERCASE, the user's object ID), 'username' (lowercase, the user's UPN). Provide either ID or username (or both).

[CIPP] Perform an admin action on a mailbox-attached mobile device via GET /api/ExecMailboxMobileDevices. Exactly one action per call, chosen with the 'action' parameter: 'Quarantine' (alias 'Block') adds the device to the mailbox's ActiveSync BLOCKED list so it stops syncing mail; 'Allow' adds it to the ActiveSync ALLOWED list; 'Delete' removes the device's ActiveSync partnership from Exchange entirely. The identifiers are NOT interchangeable — Quarantine/Allow act on 'userId' + 'deviceId' (the ActiveSync DeviceID), while Delete acts on 'guid' (the Exchange mobile-device Identity/GUID). Passing the wrong identifier silently writes a bogus entry and still reports success, so discover both values with cipp_get_mailbox_mobile_devices first. DESTRUCTIVE: 'Delete' calls Exchange Remove-MobileDevice, which removes the device's ActiveSync partnership — the device stops syncing immediately and CIPP offers no undo; the partnership has to be re-established from the device, and will typically re-create itself on the device's next connection unless that device is also blocked. This is partnership removal, NOT Exchange's Clear-MobileDevice remote-wipe cmdlet, though some device or MDM policies do drop locally cached mail when a partnership is removed. Note CIPP answers HTTP 200 even on failure, returning a 'Results' string beginning with 'Failed' — read the response body, not just the status.

[CIPP] Show or hide a mailbox from the Global Address List (GAL) via POST /api/ExecHideFromGAL. Hidden mailboxes are not visible in the address book but can still receive email.

[CIPP] Manage a High Volume Email (HVE) user account via POST /api/ExecHVEUser. HVE accounts let line-of-business applications (CRM, ticketing, automation) send large volumes of internal email without a full Exchange mailbox licence. The endpoint is a switch on body key 'Action', DEFAULTING TO 'Create' when the key is absent, with FIVE behaviours — Create, Edit, AssignBillingPolicy, RemoveBillingPolicy and Remove (Remove deletes the mail user via Remove-MailUser -Confirm:$false). Each non-Create action requires 'Identity'. Casing differs BETWEEN actions and is not normalized: Create reads camelCase 'displayName' / 'primarySMTPAddress' / 'password', while Edit reads PascalCase 'DisplayName' / 'PrimarySmtpAddress' (or 'username' + 'domain') / 'ReplyTo'. Create also warns when Security Defaults are on and tries to exclude the new account from basic-auth-blocking Conditional Access policies. NOTE: a failed call returns HTTP 403 (not 500) with the message in Results. Verified against CIPP-API master @df3738d.

[CIPP] Manage mailbox restore requests via POST /api/ExecMailboxRestore. DESTRUCTIVE on one arm: 'Remove' runs Remove-MailboxRestoreRequest and deletes the restore request. The endpoint is a switch on body key 'Action' with TWO DIFFERENT PARAMETER SETS, and the identity parameter belongs to only one of them. 'Remove' / 'Resume' / 'Suspend' act on an EXISTING restore request and use 'Identity' as its identifier. Every other Action value — including 'New' and an omitted Action — falls to the default arm, which CREATES a restore request from body keys 'RequestName' (the request's Name), 'SourceMailbox' and 'TargetMailbox' — always with AllowLegacyDNMismatch hardcoded to true by upstream, which is NOT a body key: sending AllowLegacyDNMismatch:false is silently ignored and the restore still runs with the mismatch allowed — and IGNORES 'Identity' completely. So to create a restore you must supply RequestName and SourceMailbox through additionalFieldsJson; the required identity parameter is inert on that path and exists for the three request-lifecycle actions. WARNING: this endpoint answers HTTP 200 even on failure — its catch block returns 200 with the error text in Results and colour='danger' — so always read the body. Verified against CIPP-API master @df3738d.

[CIPP] Trace email messages via POST /api/ListMessageTrace by sender, recipient, and date range. Returns delivery status, timestamps, and routing details. Useful for troubleshooting email delivery issues. dateFilter='relative' (uses 'days') OR 'startEnd' (uses 'startDate'/'endDate').

[CIPP] Modify calendar folder permissions via POST /api/ExecModifyCalPerms — the cmdlet-style batch alternative to cipp_edit_calendar_permissions. The backend expects body key 'permissions' to be a JSON ARRAY of permission-entry objects (NOT a JSON-encoded string). Each entry's PermissionLevel/UserID are unwrapped via `.value ?? <scalar>`, so this tool sends {value,label} objects. It builds a single-entry array from the typed parameters below; supply permissionsJson to send a full multi-entry array instead. Response is CIPP's raw {"Results":[...]} envelope (HTTP 500 if any entry errored).

[CIPP] Modify a mailbox owner's Contacts-folder permissions via POST /api/ExecModifyContactPerms (cmdlet-style batch). Controls who can view or edit a user's personal Contacts folder. The backend expects body key 'permissions' to be a JSON ARRAY of permission-entry objects (NOT a JSON-encoded string). Each entry's PermissionLevel/UserID are unwrapped via `.value ?? <scalar>`, so this tool sends {value,label} objects. It builds a single-entry array from the typed parameters below; supply permissionsJson for a full multi-entry array. NOTE (differs from calendar perms): the Contacts helper has NO CanViewPrivateItems/delegate flag, and FolderName defaults to 'Contact'. Response is CIPP's raw {"Results":[...]} envelope (HTTP 500 if any entry errored).

[CIPP] Modify mailbox-level permissions via POST /api/ExecModifyMBPerms — the cmdlet-style batch alternative to cipp_edit_mailbox_permissions. TWO PAYLOAD SHAPES ARE REACHABLE HERE: a BATCH, body key 'mailboxRequests' = array of {"userID":..., "permissions":[...]}; or a SINGLE mailbox, top-level 'userID' AND 'permissions' both present (both are required for that shape to match). CIPP also accepts a bare top-level JSON array, but this tool cannot send one — fieldsJson is deserialized as a JSON object. If no shape matches, CIPP answers HTTP 400 'No mailbox requests provided'. Each permissions entry carries: 'PermissionLevel' (REQUIRED) — one of FullAccess, SendAs, SendOnBehalf, ReadPermission, ExternalAccount, DeleteItem, ChangePermission, ChangeOwner (an UNRECOGNISED value is SILENTLY SKIPPED; a comma-separated string is split into several levels); 'Modification' — 'Remove' revokes, ANY other value (including 'Add') grants; 'UserID' (REQUIRED) — the delegate, as a bare UPN string, an array of them, or {"value":...} objects; and optional 'AutoMap' (defaults true). WARNING: an unrecognised PermissionLevel is forgiving, a MISSING one is not. Upstream dereferences both required fields by METHOD CALL — $PermissionLevels.Trim() and $Permission.UserID.ToString() — inside a loop that sits OUTSIDE any try block, so omitting either raises 'You cannot call a method on a null-valued expression' as an unhandled function error: HTTP 500 with no {"Results":...} envelope at all. The Add*/Remove* bucket keys (AddFullAccess, RemoveSendAs, ...) belong to cipp_edit_mailbox_permissions — this endpoint never reads them. The mailbox identifier key is 'userID'; 'userPrincipalName' is not read. Verified against CIPP-API master @df3738d.

[CIPP] Remove a specific inbox rule from a mailbox via POST /api/ExecRemoveMailboxRule. Use cipp_get_mailbox_rules first to find rule IDs. Commonly used to remove suspicious forwarding rules during incident response. ruleId is MANDATORY — it is not an alternative to ruleName: upstream calls $RuleId.Split('')[0] to derive the mailbox object id BEFORE its try block opens, so a ruleName-only call dies on a method-invocation-on-null and returns an unhandled Azure Function error instead of the documented {"Results":...} envelope. This tool refuses that call locally. ruleName is passed through as an additional selector alongside ruleId. NOTE: the body uses uppercase 'TenantFilter' (intentional). Verified against CIPP-API master @df3738d.

[CIPP] Unblock a user who has been restricted from sending email via POST /api/ExecRemoveRestrictedUser. Use cipp_list_restricted_users first to see blocked sender addresses.

[CIPP] Schedule a mailbox-vacation workflow against POST /api/ExecScheduleMailboxVacation. It queues TWO scheduled tasks — an 'Add' at startDate granting each delegate the named permission(s) on each vacationing owner's mailbox (plus calendar folder permissions when includeCalendar is set), and a 'Remove' at endDate that revokes them. The grant is the CARTESIAN PRODUCT of mailboxOwners x delegates x permissionTypes. WIRE SHAPES ARE LOAD-BEARING and this tool builds them for you from the plain parameters below: startDate/endDate go out as UNIX EPOCH SECONDS (real JSON numbers — CIPP casts them with [int64] and schedules the task at that second, so an ISO string fails the whole request); mailboxOwners/delegates go out as ARRAYS of {value,label} objects, because CIPP reads each element's '.addedFields.userPrincipalName ?? .value' and a JSON-encoded string or a bare UPN array resolves to null PER ELEMENT — and since @($null) has Count 1, CIPP's own 'owners, delegates and permission types are required' guard does NOT fire, so the vacation is scheduled against a null user at HTTP 200; permissionTypes goes out as an ARRAY (CIPP never splits a comma-separated string, it would use 'FullAccess,SendAs' as one bogus level); and autoMap/includeCalendar/canViewPrivateItems go out as REAL JSON BOOLEANS, because CIPP casts them with [bool] and in PowerShell the STRING 'false' is true. Note autoMap defaults to TRUE upstream when the key is absent. Body keys (camelCase): 'tenantFilter' (required, BODY ONLY — the query argument is not read), 'startDate', 'endDate', 'mailboxOwners', 'delegates', 'permissionTypes', 'autoMap', 'includeCalendar', 'calendarPermission', 'canViewPrivateItems', 'postExecution', 'reference'. Destructive note: this grants long-lived FullAccess; confirm the Remove task exists before relying on auto-revert. Verified against CIPP-API master @df3738d.

[CIPP] Schedule a future out-of-office (auto-reply) window for one or more users via POST /api/ExecScheduleOOOVacation. CIPP queues TWO tasks — an 'Add' at startDate that turns auto-replies on with the supplied messages, and a 'Remove' at endDate that turns them off without re-sending messages (so the user's own later edits survive). WIRE SHAPES ARE LOAD-BEARING and this tool builds them for you: startDate/endDate go out as UNIX EPOCH SECONDS (real JSON numbers — CIPP does [DateTimeOffset]::FromUnixTimeSeconds([int64]$StartDate) and schedules at that second, so an ISO string fails the request), and 'Users' goes out as an ARRAY of {value,label} objects, because CIPP reads each element's '.addedFields.userPrincipalName ?? .value'. A JSON-encoded string — the shape this tool used to send — resolves to null PER ELEMENT, and because an array holding one null still has Count 1, CIPP's 'At least one user is required' guard does NOT fire: the OOO is scheduled against a null user and the API answers HTTP 200 'Successfully scheduled'. Body keys: 'tenantFilter' (camelCase, required, BODY ONLY — the query argument is not read), 'Users' (PascalCase, intentional — do not normalize), 'startDate', 'endDate', 'externalMessage', 'internalMessage', 'postExecution', 'reference'. Verified against CIPP-API master @df3738d.

[CIPP] Configure calendar processing settings for a resource mailbox (room or equipment) via POST /api/ExecSetCalendarProcessing — auto-accept, booking window, conflict resolution, processing of external meeting messages, and so on. TWO WARNINGS, both silent at HTTP 200. (1) BOOLEANS MUST BE REAL JSON BOOLEANS: upstream coerces every flag with `-as [bool]`, and in PowerShell EVERY non-empty string is $true — so the string 'false' TURNS THE SETTING ON. Send true/false, or omit the key. (2) THIS IS A FULL OVERWRITE, NOT A PATCH: all ten boolean flags are placed in Set-CalendarProcessing's cmdParams on every call, so any flag you omit is written as $false, and omitting BOTH automaticallyAccept and automaticallyProcess writes AutomateProcessing='None'. Always send the mailbox's complete desired boolean state, not just the one field you want to change. Numeric keys are the exception — they are applied only when truthy. Body keys: 'tenantFilter' (required), 'UPN' (PascalCase, the resource mailbox UPN = Set-CalendarProcessing -Identity), booleans 'automaticallyAccept', 'automaticallyProcess', 'allowConflicts', 'allowRecurringMeetings', 'scheduleOnlyDuringWorkHours', 'addOrganizerToSubject', 'deleteComments', 'deleteSubject', 'removePrivateProperty', 'removeCanceledMeetings', 'removeOldMeetingMessages', 'processExternalMeetingMessages'; numerics 'maxConflicts', 'maximumDurationInMinutes', 'minimumDurationInMinutes', 'bookingWindowInDays'; string 'additionalResponse'. Verified against CIPP-API master @df3738d.

[CIPP] Configure email forwarding for a mailbox via POST /api/ExecEmailForward. forwardOption SELECTS THE OPERATION and is REQUIRED — it is not a hint: 'internalAddress' forwards to the ForwardInternal recipient, 'ExternalAddress' forwards to the ForwardExternal SMTP address, 'disabled' turns forwarding off. Supplying ForwardInternal or ForwardExternal does NOT choose the branch. WARNING (why this tool refuses bad values locally): upstream is a PowerShell switch over exactly those three literals with NO default arm, so an absent or unrecognised forwardOption runs no branch at all — neither the result nor the HTTP status is ever assigned and nothing changes. Body keys: 'tenantFilter' (body is what upstream reads), 'userID' (uppercase ID), 'ForwardInternal', 'ForwardExternal', 'KeepCopy' (real JSON boolean), 'forwardOption'. Verified against CIPP-API master @df3738d.

[CIPP] Enable or disable litigation hold on a mailbox via POST /api/ExecSetLitigationHold. Litigation hold preserves all mailbox content including deleted items for legal discovery. Upstream computes the hold state as `-not $Request.Body.disable`, a TRUTHINESS test, not a boolean parse — so what decides the outcome is whether the value is FALSY, not whether the key is present: a boolean true or any NON-EMPTY string (the literal "false" and the string "0" included) DISABLES the hold, while a boolean false, a numeric 0 or an empty string are falsy and ENABLE it exactly like omitting the key — and CIPP answers HTTP 200 either way. That is why this tool OMITS 'disable' entirely for disable=false rather than sending a value; do not 'fix' that back to emitting "false". The same rule governs the escape hatch below, where it reads backwards: a 'disable': false placed there is merged LAST over a typed disable=true and silently RE-ENABLES the hold instead of releasing it. 'Identity' is the ONLY mailbox identifier that reaches Set-Mailbox — 'UPN' appears solely in the response and log text — so this tool defaults Identity from the upn parameter when identity is omitted. Body keys: 'tenantFilter', 'UPN', 'Identity', 'disable', 'days'. Verified against CIPP-API master @df3738d.

[CIPP] Set the maximum send/receive message size for a mailbox via POST /api/ExecSetMailboxEmailSize. Controls the largest single message (including attachments) that can be sent from or received by the mailbox. Body keys per spec: 'tenantFilter' (required), 'UPN' (PascalCase, the mailbox UPN), 'id' (lowercase, the mailbox object ID), 'maxSendSize' (camelCase string with units, e.g., '35MB'), 'maxReceiveSize' (camelCase string with units, e.g., '35MB').

[CIPP] Set ONE storage quota threshold for a mailbox via POST /api/ExecSetMailboxQuota. THE THRESHOLD KEYS ARE PRESENCE FLAGS, NOT VALUES: upstream reads the size to write from body key 'quota' alone and uses 'IssueWarningQuota' / 'ProhibitSendQuota' / 'ProhibitSendReceiveQuota' only to decide WHICH Exchange property that one value lands on. Naming a threshold with no 'quota' therefore writes null. Worse, upstream reassigns its $quota variable to each Set-Mailbox call's return value, so a second or third threshold in the same request receives that response object instead of a size string. This tool therefore accepts exactly ONE threshold per call and seeds 'quota' from it when quota is omitted; a second threshold is refused before dispatch. Call the tool once per threshold, warning-first then prohibit-send then prohibit-send-receive. WARNING: naming NO threshold at all is a silent no-op — none of upstream's three presence checks fires, nothing is written, and it still answers HTTP 200 with an empty Results array. NOTE: the body key is lowercase 'tenantfilter' here (intentional, do not normalize) and the endpoint hardcodes HTTP 200 — read the Results array, never the status. Verified against CIPP-API master @df3738d.

[CIPP] Enable or disable an existing server-side inbox rule on a mailbox via POST /api/ExecSetMailboxRule. This endpoint does not create a rule — it flips an existing one identified by ruleId or ruleName. STATE IS EXPRESSED BY PRESENCE, NOT BY VALUE: upstream reads both flags with `-as [bool]`, under which every non-empty string is $true, so the string 'false' means TRUE. Send exactly one of 'Enable' / 'Disable' as a real JSON boolean true and OMIT the other — sending Enable:true together with Disable:'false' sets both, and Enable is tested first, so the rule is enabled. With neither flag truthy upstream `throw`s outside any try block ('No state provided for mailbox rule'), which surfaces as an unhandled function error rather than a result envelope. Body keys: 'TenantFilter' (PascalCase — this tool seeds it for you), 'userPrincipalName' (camelCase), 'ruleId' / 'ruleName', 'Enable' / 'Disable' (PascalCase). Verified against CIPP-API master @df3738d.

[CIPP] Configure out-of-office (automatic reply) settings for a mailbox via POST /api/ExecSetOoO with separate internal and external messages. AutoReplyState valid values: 'Enabled', 'Disabled', 'Scheduled'. When 'Scheduled', set StartTime and EndTime as ISO-8601 timestamps.

[CIPP] Set the maximum number of recipients per outbound email message for a mailbox via POST /api/ExecSetRecipientLimits. Helps contain mass-mailing damage from compromised accounts. 'Identity' IS THE ONLY MAILBOX IDENTIFIER — it is the sole value passed to Set-Mailbox; body key 'userid' is used purely to compose the success/error text, so a call that supplies userid without Identity targets a null mailbox while the message still names the user. Body keys: 'tenantFilter' (required, camelCase, body only), 'Identity' (PascalCase — UPN, alias, DN or GUID), 'recipientLimit' (camelCase, passed straight through to Set-Mailbox -RecipientLimits), 'userid' (lowercase, display only). Verified against CIPP-API master @df3738d.

[CIPP] Enable or disable retention hold on a mailbox via POST /api/ExecSetRetentionHold. When enabled, retention policies temporarily stop deleting/moving items so a user (e.g., on leave) does not lose mail to retention while away. TWO CONTRACTS THAT BITE. (1) The hold state is computed as `-not $Request.Body.disable` — a TRUTHINESS test, not a boolean parse — so what matters is whether the value is FALSY, not whether the key is present. Only a boolean true or a NON-EMPTY string DISABLES the hold, and note that the non-empty string 'false' is one of them. A JSON boolean false, a numeric 0 and an empty string are all falsy, so they ENABLE the hold exactly like omitting the key: there is no way to release a hold by sending 'disable':false. To enable, OMIT the key; to disable, send boolean true. (2) 'Identity' IS THE ONLY MAILBOX IDENTIFIER — it is the sole value passed to Set-Mailbox; 'UPN' only decorates the returned message, so a UPN-only call targets a null mailbox while the message still names the user. Body keys: 'tenantFilter' (required, camelCase, body only), 'Identity' (PascalCase, required in practice), 'UPN' (PascalCase, display only), 'disable' (lowercase). Verified against CIPP-API master @df3738d.

[CIPP] Start the Managed Folder Assistant for a mailbox via POST /api/ExecStartManagedFolderAssistant to immediately process retention policies and tags instead of waiting for the next automatic cycle. Body keys per spec: 'tenantFilter' (required), 'Id' (mixed-case 'Id' — capital I lowercase d, the mailbox object ID), 'UserPrincipalName' (PascalCase, the mailbox UPN). The same 'Id' and 'tenantFilter' values can also appear as query arguments per the spec.

[CIPP] Delete retention policies for a tenant via DELETE /api/ExecManageRetentionPolicies. Spec marks the body required with required camelCase 'tenantFilter'. Optional body keys: 'CreatePolicies' (PascalCase array), 'ModifyPolicies' (PascalCase array), 'DeletePolicies' (PascalCase array). WARNING: Deleting retention policies may affect legal hold compliance.

[CIPP] Delete retention tags for a tenant via DELETE /api/ExecManageRetentionTags. Upstream reads EXACTLY four top-level body keys and nothing else: 'tenantFilter' (camelCase, required; also accepted as a query argument), 'DeleteTags' (PascalCase array of plain tag identity STRINGS), 'CreateTags' (PascalCase array of tag OBJECTS), 'ModifyTags' (PascalCase array of tag OBJECTS). WARNING: there is no top-level 'Comment' key. 'Comment' is a property of each individual tag object inside CreateTags/ModifyTags; a Comment placed at the root of the body is read by nothing and silently dropped — no error, no 400, and the response gives no sign the input was ignored. WARNING: at least one of DeleteTags / CreateTags / ModifyTags is REQUIRED. A body carrying only tenantFilter is not a minimal delete: it takes an undocumented default LIST branch that runs Get-RetentionPolicyTag and returns EVERY retention tag in the tenant at HTTP 200 having deleted nothing, so despite this tool's name and its Destructive flag that list is the tenant's tags, NOT the tags that were removed. WARNING: Removing retention tags affects how mailbox items are managed and may impact compliance.

[CIPP] Assign an Exchange Online retention policy to one or more mailboxes via POST /api/ExecSetMailboxRetentionPolicies. Body keys: 'Mailboxes' (PascalCase, a JSON ARRAY of mailbox identity strings — upstream iterates the array and passes each element straight to Set-Mailbox -Identity), 'PolicyName' (PascalCase string — the retention policy display name), 'tenantFilter' (camelCase; also accepted as a query argument). All three are required: upstream answers 400 'Mailboxes array is required' when Mailboxes is missing or empty, and 400 'PolicyName is required' when PolicyName is empty. WARNING: do NOT pass Mailboxes as a comma-separated string. Upstream never splits it, and a non-empty scalar string satisfies the array guard, so the entire string is attempted as ONE invalid mailbox identity — every mailbox you intended is left unchanged and the only symptom is a single failure entry. Returns {"Results":[...]} with one success or failure string per mailbox; read every entry, because a per-mailbox failure is reported inside Results rather than as an error status.

[CIPP] Create a new mail contact in a tenant directory via POST /api/AddContact. Mail contacts are external people that appear in the GAL but cannot sign in. Verified against CIPP-API master @df3738d: CIPP reads the destination tenant from the BODY key 'tenantid' only — the query string is never consulted for this endpoint — and this tool seeds it from tenantFilter. The body keys CIPP actually reads are 'displayName' (becomes both DisplayName and Name), 'email' (becomes ExternalEmailAddress), 'firstName', 'lastName', 'Title', 'Company', 'StreetAddress', 'City', 'State' (becomes StateOrProvince), 'PostalCode', 'CountryOrRegion', 'phone', 'mobilePhone', 'website' (becomes WebPage), 'mailTip' and 'hidefromGAL'; anything else is ignored. Empty/whitespace values are SKIPPED only for the second-pass Set-Contact fields ('Title', 'Company', 'StreetAddress', 'City', 'State', 'PostalCode', 'CountryOrRegion', 'phone', 'mobilePhone', 'website') and 'mailTip'; 'displayName', 'email', 'firstName' and 'lastName' are handed to New-MailContact UNCONDITIONALLY, so a blank one is sent as-is. WARNING — hidefromGAL is a TRUTHINESS test upstream ([bool]$value), so ANY non-empty string, INCLUDING the string "false", evaluates true and HIDES the contact from the Global Address List. Use the typed hideFromGal parameter, which sends a real JSON boolean.

[CIPP] Create a new CIPP contact template via POST /api/AddContactTemplates. Stores the contact attributes for later bulk deployment (via cipp_deploy_contact_templates) across tenants. Not tenant-scoped — this is the CIPP-internal template store. CIPP body keys are MOSTLY camelCase per spec: businessPhone, city, companyName, country, displayName, email, firstName, hidefromGAL (boolean — note specific casing 'hidefromGAL'), jobTitle, lastName, mailTip, mobilePhone, postalCode, state, streetAddress, website. Display name and email are typically required for the underlying contact.

[CIPP] Create a new equipment mailbox for a bookable resource (projector, vehicle, conference phone, etc.) via POST /api/AddEquipmentMailbox. Equipment mailboxes are bookable through Outlook calendaring. Verified against CIPP-API master @df3738d: CIPP reads the destination tenant from the BODY only — spelled 'tenantID' in the upstream source, but the casing is NOT load-bearing (CIPP re-serializes the request so every body lookup is case-insensitive; AddRoomMailbox spells the same key 'tenantid' and either spelling works on either endpoint) — and reads exactly THREE mailbox properties — 'username' (becomes New-Mailbox Name), 'displayName' and 'userPrincipalName' (becomes PrimarySmtpAddress, which is what determines the mailbox address). A 'domain' key is NEVER READ by this endpoint. After creation CIPP blocks sign-in for the new mailbox; a failure there is reported inside Results but still returns HTTP 200. A create failure returns HTTP 403, not 500.

[CIPP] Create a new room list (group of rooms by building/floor/location) via POST /api/AddRoomList. Room lists group rooms so users can browse them by category in Outlook's room finder. CIPP body uses camelCase + a LabelValue 'primDomain' object. tenantFilter is sent on BOTH the query string AND the body.

[CIPP] Create a new room mailbox via POST /api/AddRoomMailbox. Room mailboxes are bookable through Outlook calendaring. Verified against CIPP-API master @df3738d. TENANT: CIPP reads the destination tenant from the BODY key 'tenantid' (all-lowercase) ONLY (`$Tenant = $Request.Body.tenantid`); there is no query-string read in the file, so the TenantFilter query argument is inert. This tool therefore seeds 'tenantid' from tenantFilter, and the optional tenantId parameter overrides it. CIPP reads exactly FOUR mailbox properties: 'username' (becomes New-Mailbox Name), 'displayName', 'userPrincipalName' (becomes PrimarySMTPAddress — this, NOT any domain field, determines the mailbox address) and 'ResourceCapacity'. A 'domain' key is accepted by the schema but NEVER READ by this endpoint. After creation CIPP blocks sign-in for the new mailbox; a failure there is reported inside Results but still returns HTTP 200.

[CIPP] Bulk-deploy CIPP contact templates to create mail contacts across one or more tenants via POST /api/DeployContactTemplates. CROSS-TENANT: the targets come from the body key 'selectedTenants', never from tenantFilter. Verified against CIPP-API master @df3738d — BOTH body keys are ARRAYS OF OBJECTS, and CIPP reads only the '.value' of each element. 'selectedTenants': [{"value":"contoso.onmicrosoft.com"}, ...], where the literal value 'AllTenants' expands to EVERY tenant CIPP knows. 'TemplateList': [{"value":<the full contact-template object>}, ...] — the element's value is the whole template (its email/displayName/firstName/lastName/jobTitle/companyName/streetAddress/city/state/postalCode/country/businessPhone/mobilePhone/website/hidefromGAL/mailTip fields are read individually), NOT a template id, and '.Count' in the upstream guard is PowerShell's array length, not a field you supply. WARNING — a selectedTenants list that yields no '.value' is NOT an error: CIPP skips the deploy loop entirely and returns HTTP 200 with empty Results, so a silent zero-tenant deploy looks like success. The typed selectedTenants parameter exists to make that unreachable. Per-tenant behaviour: an existing contact with the same email is SKIPPED (reported, not overwritten), and per-tenant failures come back as text lines inside Results under HTTP 200.

[CIPP] Edit an existing mail contact via POST /api/EditContact. Verified against CIPP-API master @df3738d. TENANT: CIPP reads the destination tenant from the BODY key 'tenantID' ONLY (`$TenantID = $Request.Body.tenantID`); the file contains no query-string read, so the TenantFilter query argument is inert. This tool therefore seeds 'tenantID' from tenantFilter, and the optional tenantId parameter overrides it. Body keys CIPP reads: 'ContactID' (REQUIRED — the Set-Contact / Set-MailContact Identity), 'displayName', 'email' (written to BOTH WindowsEmailAddress, the address the contacts list displays, AND ExternalEmailAddress, the actual mail-routing target), 'firstName', 'LastName', 'Title', 'StreetAddress', 'PostalCode', 'City', 'State' (becomes StateOrProvince), 'CountryOrRegion', 'Company', 'website' (becomes WebPage), 'mobilePhone', 'phone', 'hidefromGAL' (real JSON boolean, null-checked upstream — false genuinely UN-hides), 'mailTip'. Empty/whitespace values are SKIPPED for every field EXCEPT 'mobilePhone' and 'phone', which are presence-tracked: passing an empty string for those two CLEARS the value. WARNING — an edit carrying only ContactID writes NOTHING and still returns HTTP 200 'Successfully edited contact'; this tool refuses such a call up front rather than reporting that false success.

[CIPP] Modify an existing CIPP contact template via POST /api/EditContactTemplates. The template is identified by 'ContactTemplateID' in the body (not the same key as live contact's 'ContactID'). Not tenant-scoped — this edits the CIPP-internal template store. CIPP body keys are MOSTLY camelCase per spec; preserve casing exactly. Use cipp_list_contact_templates to find the ContactTemplateID.