Filter out Deprovisioned Users with a not equals fails 400 bad request

Questions
1

Hi,
I’ve a general question on the filtering of users.
I’ve an api call where I get all users in my Okta instance with (calling from postman):
https://xxxxxxxxxxx.okta.com/api/v1/users?filter=lastUpdated%20gt%20%222021-09-30T00:00:00.000Z%22 but I want to filter out Deprovisioned users and return all the rest so I tried:

https://xxxxxxxxxxx.okta.com/api/v1/users?filter=lastUpdated%20gt%20%222021-09-30T00:00:00.000Z%22%20and%20status%20ne%20%22DEPROVISIONED%22

Without the urlencoding:
https://xxxxxxxxxxx.okta.com/api/v1/users?filter=lastUpdated gt "2021-09-30T00:00:00.000Z" and status ne "DEPROVISIONED"
But this fails with a 400 bad request.

I know you can do a status eq "ACTIVE" or status eq "STAGED".

My question is why does ne (not equals) give a bad request but eq (equals) works?
Seems like I’ll need a string of status eq XXX or ... for all status except the one I want to filter out.
Is this correct?
This doesn’t seem very maintainable if there is a new status introduced, I’ll need to manually update my api calls that filter on status.

Filter status api doc section: Users | Okta Developer
Filter condition api doc section: Core Okta API | Okta Developer

2

Hmmm, unfortunately this does look to be the case. The note in the filter docs states:

Note: The ne (not equal) operator isn’t supported for some objects, but you can obtain the same result by using lt ... or ... gt . For example, to see all user agents except for “iOS”, use (client.userAgent.os lt "iOS" or client.userAgent.os gt "iOS") .

I tried filter=status lt "DEPROVISIONED" or status gt "DEPROVISIONED" and doesn’t look like it’s supported either.

3

Thanks for the reply Cale, would it be worth adding? At the moment I have added below as a work around but it’s messy and hard to read (this is post urlencoded).

lastUpdated%20gt%20%222021-09-30T00:00:00.000Z%22%20and%20%28status%20eq%20%22ACTIVE%22%20or%20status%20eq%20%22STAGED%22%20or%20status%20eq%20%22PROVISIONED%22%20or%20status%20eq%20%22RECOVERY%22%20or%20status%20eq%20%22PASSWORD_EXPIRED%22%20or%20status%20eq%20%22LOCKED_OUT%22%29
I’ll mark your answer as the solution.

4

I certainly think so - no one should have to read/write that atrocious URL!

Certainly not a bad submission for Okta Ideas.

Glad you found a workaround.