Update WalkMe Access Settings

Update WalkMe Support access settings for your account.

POST
https://api.walkme.com/public/v1/walkmeAccess

cURL Example

curl -L -X POST 'https://api.walkme.com/public/v1/walkmeAccess' \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{
    "restrictAccess": true,
    "restrictionDelayDays": 1,
    "allowedUserEmails": ["[email protected]"]

  }'

Response Example -JSON

{
  "accessRestricted": false,
  "restrictionStartsAt": "2026-06-23T09:44:54.734Z",
  "allowedUserEmails": ["[email protected]"]
}

BODY PARAMS

FieldTypeRequiredDescription
restrictAccessbooleanYesWhether to restrict WalkMe Support access to your account
restrictionDelayDaysnumberNoMinutes until the restriction starts. Allowed values: 0,1,3,7,30,60
AllowedUserEmailsstring[]NoFull replacement list of emails WalkMe Support may impersonate.
Omitting the field leaves the existing list unchanged.
An empty array clears the list (all users allowed). Maximum 50 values.

restrictionDelayDays values:

ValueDelay
0Immediately (same as omitting the field when restricting)
11 day
33 days
77 days
30~1 month
60~2 months

Examples

Block access immediately

Set restrictAccess to true and omit restrictionDelayMinutes (or set it to 0). The restriction takes effect right away.

 curl -L -X POST "https://api.walkme.com/public/v1/walkmeAccess" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "restrictAccess": true
  }'

Response

{
  "accessRestricted": true
 }

Schedule a restriction

Block access starting in 1 day:

{
  "restrictAccess": true,
  "restrictionDelayDays": 1
}

Response

{
  "accessRestricted": false,
  "restrictionStartsAt": "2026-06-23T09:44:54.734Z"
 }

Until restrictionStartsAt passes, impersonation is still allowed. After that time, a GET will return access Restricted: true without restrictionStartsAt.

Remove restriction

Allow WalkMe Support access again:

{
  "restrictAccess": false
}

Response

{
  "accessRestricted": false,
 }

Omitting allowedUserEmails leaves the allow-list unchanged.

Allow specific users only

Set the allow-list to exactly these emails (replaces any existing list; emails must exist on your account):

{
  "restrictAccess": false,
  "addAllowedUserEmails": ["[email protected]"],
  }

Allow all users again

Send an empty allowedUserEmails array to clear the allow-list.
Posting restrictAccess: false alone does not clear the list.

{
  "restrictAccess": false,
  "addAllowedUserEmails": [],
 }

Response when all users are allowed again (allowedUserEmails is omitted from the response):

{
  "accessRestricted": false
  
 }

Combined update

{
  "restrictAccess": false,
  "restrictionDelayDays": 1,
  "addAllowedUserEmails": ["[email protected]"]
  }

Response

{
"accessRestricted": false,
"restrictionStartsAt":"2026-06-23T09:44:54.734Z",
  "addAllowedUserEmails": ["[email protected]"]
 }

Access is not restricted yet because of the delay.
Until restrictionStartsAt, WalkMe Support may impersonate only [email protected].

Response

200 OK

The POST request returns the updated settings in the same format as the GET request:

{
"accessRestricted": false,
"restrictionStartsAt":"2026-06-23T09:44:54.734Z",
  "addAllowedUserEmails": ["[email protected]"]
 }
FieldTypeDescription
accessRestrictedbooleanWhether WalkMe Support access is currently restricted
restrictionStartsAtstringOptional. ISO 8601 UTC timestamp when a scheduled restriction will take effect
allowedUserEmailsstring[]Current list of allowed user emails. Omitted when accessRestricted is 'true'or when all users are allowed.

You do not need to call GET after a successful POST — the response already reflects the new state.

Request vs response field names

POST uses restrictAccess (your intent to change settings). The response uses accessRestricted (whether access is restricted right now), and optionally restrictionStartsAt when a restriction is scheduled.

POSTResponse
restrictAccess: true without delayaccessRestricted: true (no restrictionStartsAt )
restrictAccess: true with delayaccessRestricted: false, restrictionStartsAt: <future time>
restrictAccess: falseaccessRestricted: false (no restrictionStartsAt`)

Allowed users list behavior

  • allowedUserEmails in the request replaces the full allow-list. It is not incremental add/remove

  • Omit allowedUserEmails to leave the existing list unchanged (for example when only updating restrictAccess or restrictionDelayDays)

  • Send allowedUserEmails: [] to clear the list so all users on the account may be impersonated

  • When allowedUserEmails is omitted in the response and accessRestricted is false, all users on the account may be impersonated

  • When allowedUserEmails is present in the response, impersonation is limited to those emails only.

Validation errors

Missing or invalid restrictAccess

{
  "status": 400,
  "detail": "restrictAccess is required and must be a boolean"
}

Invalid delay value

{
  "status": 400,
  "detail": "restrictionDelayDays must be one of: 0, 1,3,7,30,60"
}

Too many emails in a list

{
  "status": 400,
  "detail": "addAllowedUserEmails must not contain more than 50 email addresses"
}

allowedUserEmails is limited to 50 entries per request.

Email not found on account

{
  "status": 400,
  "detail": "User(s) not found on this account: [email protected]"
}

This applies to any email in allowedUserEmails that does not belong to a user on your account.

Other error responses

StatusCause
401Invalid or missing Bearer token
403Token missing a write scope
500Internal server error