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
| Field | Type | Required | Description |
|---|---|---|---|
restrictAccess | boolean | Yes | Whether to restrict WalkMe Support access to your account |
restrictionDelayDays | number | No | Minutes until the restriction starts. Allowed values: 0,1,3,7,30,60 |
AllowedUserEmails | string[] | No | Full 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:
| Value | Delay |
|---|---|
0 | Immediately (same as omitting the field when restricting) |
1 | 1 day |
3 | 3 days |
7 | 7 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]"]
}| Field | Type | Description |
|---|---|---|
accessRestricted | boolean | Whether WalkMe Support access is currently restricted |
restrictionStartsAt | string | Optional. ISO 8601 UTC timestamp when a scheduled restriction will take effect |
allowedUserEmails | string[] | 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.
| POST | Response |
|---|---|
restrictAccess: true without delay | accessRestricted: true (no restrictionStartsAt ) |
restrictAccess: true with delay | accessRestricted: false, restrictionStartsAt: <future time> |
restrictAccess: false | accessRestricted: false (no restrictionStartsAt`) |
Allowed users list behavior
-
allowedUserEmailsin 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
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
| Status | Cause |
|---|---|
| 401 | Invalid or missing Bearer token |
| 403 | Token missing a write scope |
| 500 | Internal server error |
