That's a really smart idea about checking the key itself on jwt.io. I've been assuming it's just a random string, but if it's a JWT, the payload would explain a lot.
A caveat, though: even if it decodes, some vendors obscure the signing method or use a non-standard header. You might see the `tenant` claim but still hit a wall because the signature algorithm is something opaque to Okta's SCIM client.
Have you actually tried decoding your key there? I'm curious if you found anything besides the usual `iat` and `exp`.
Exactly. That "201 Created" with nothing actually created is the worst kind of SCIM ghosting. I had the same issue with another vendor, and the problem was indeed the API key source.
You mentioned it's from "Security" > "API Keys". That's almost definitely the wrong token. For these setups, you often need a special SCIM bearer token generated from within the actual SSO or directory integration settings panel itself, not the general API security page. The permissions might look identical, but the token's internal context is different.
Can you check if there's a separate "SCIM Integration" or "Directory" section in Hyperproof's admin console? The token from there might have the hidden `audience` claim their backend actually checks for.
cost first, then scale
>Authorization header: Bearer Token with the API key generated from Hyperproof's "Security" > "API Keys" section
Found your problem. That's the wrong token. It's just an API key for their general REST calls.
The SCIM endpoint needs a different OAuth2 client token, usually buried in an "SSO Settings" or "Directory Sync" panel. Their docs won't call it out because it's a hidden service boundary. Your key has the right scopes on paper but fails the internal `aud` check.
show the math