I have been attempting to configure SCIM-based user provisioning between our Okta tenant and our Hyperproof instance for the past three business days without success. The goal is to automate the creation, updating, and deactivation of user accounts within Hyperproof based on group assignments in Okta, as per our standard onboarding workflow. Despite following the documented integration guide, the provisioning cycle consistently fails, and Hyperproof support has been unable to provide a root-cause analysis.
My current configuration is as follows:
**Okta SCIM Connector Settings:**
* **SCIM connector base URL:** ` https://api.hyperproof.com/api/scim/v2`
* **Unique identifier field for users:** `userName`
* **Authentication mode:** HTTP Header
* **Authorization header:** Bearer Token with the API key generated from Hyperproof's "Security" > "API Keys" section (with full SCIM permissions).
**Okta Attribute Mappings (simplified):**
* `userName` -> `user.userName`
* `email` -> `user.emails[0].value`
* `givenName` -> `user.name.givenName`
* `familyName` -> `user.name.familyName`
* `active` -> `user.active`
The provisioning logs in Okta show a `200 OK` or `201 Created` response, but the user never appears in the Hyperproof organization's "People" list. When I enable debug-level logging in Okta, I can see the full request/response cycle. The POST request body sent to the Hyperproof SCIM endpoint appears correct, and the response contains a valid Hyperproof `id` field. However, the resource is not materialized in the application.
```json
// Example of Okta's POST request (anonymized)
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "[email protected]",
"name": {
"givenName": "John",
"familyName": "Doe"
},
"emails": [{
"primary": true,
"value": "[email protected]",
"type": "work"
}],
"active": true
}
```
**Troubleshooting steps already performed:**
* Verified the API key is valid and has not expired.
* Confirmed the Hyperproof organization ID is correctly appended in the bearer token context (as per the API key's intended use).
* Tested the SCIM endpoint with a direct cURL command, which also returns a successful `201` but no visible user.
* Ensured the user's email domain is not already associated with any existing Hyperproof account (even inactive ones).
* Reviewed Hyperproof audit logs; no provisioning events are recorded there, suggesting the request may be accepted by the gateway but not processed by the core application logic.
My primary hypothesis is a misalignment between the `userName` attribute mapping and Hyperproof's internal expectation. Some SCIM implementations expect `userName` to be the email address, while others expect a distinct username. The documentation is ambiguous on this point.
I am seeking input from anyone who has successfully implemented this integration. Specifically:
* Were any non-obvious attribute mappings required in Okta?
* Is there a specific Hyperproof organization role that must be assigned via the `roles` attribute in the SCIM payload for the user to become visible?
* Did you encounter a similar "silent success" scenario, and what was the ultimate resolution?
A secondary question pertains to performance: once operational, what is the observed latency between a group assignment change in Okta and user availability in Hyperproof? For our capacity planning, we need to understand if this is near-real-time or operates on a scheduled sync cycle.
You've got the foundational mapping correct, but a `200 OK` response can be misleading. It often means the HTTP request itself succeeded, but the payload may have been rejected by Hyperproof's SCIM endpoint due to a schema mismatch or a missing required field. You need to examine the *response body* from those `200` calls in the Okta logs, not just the status code.
Hyperproof's SCIM implementation likely requires specific, non-standard attributes beyond the core schema for a user to be provisioned correctly, such as a `department` or a custom externalId. Check their API documentation for any mandatory fields you haven't mapped. Also, verify the Bearer token is correctly scoped; an API key with "full SCIM permissions" might still lack a specific scope needed for user write operations.
Enable debug logging for the provisioning integration if possible, and compare the exact JSON payload Okta is sending against a sample from Hyperproof's documentation. The devil is in those details.
Every dollar counts.
Oh, that sounds really frustrating. I had a similar headache setting up SCIM with a different tool last year. The part that caught my eye is you mentioning the logs show a `200 OK`. I completely agree with the other reply about checking the response body, because that's exactly what tripped me up.
In my case, the tool would accept the request and return a `200`, but the user wouldn't actually be created. The response body had an error message buried in it saying something like `"error": "primaryEmail is a required field"` even though I'd mapped the email. The mapping syntax was just slightly off. Maybe Hyperproof's endpoint expects the email in a specific format or nested differently?
Did you get a chance to look at those raw logs yet? I'm curious what the actual response text says, if anything. Sometimes it's so subtle
Yeah, those 200/201 status codes will lull you into a false sense of security. Been there, got the sleep-deprived t-shirt! The others are spot on about digging into the response body.
One trick that saved me with a finicky SCIM endpoint was to test the actual API call directly. Use a tool like Postman or curl to send a minimal POST to Hyperproof's SCIM URL with your Bearer token, mimicking exactly what Okta sends. You'll often get a much clearer error message than what gets filtered through Okta's logs.
Also, double-check that `userName` mapping. Some systems are picky and need it to match the primary email exactly, while others treat it as a separate unique identifier. If it's expecting an email and you're sending something else, it might silently fail.
it worked on my machine
Right. The direct curl test bypasses Okta's opaque logging. But be ready for the other classic SCIM failure: Hyperproof might be validating the bearer token but rejecting the payload because it's not sending a `Content-Type: application/scim+json` header. Okta sometimes defaults to `application/json`, and some endpoints are pedantic about it.
If the curl works but Okta fails, you've found a connector config problem. If curl also fails, you'll get the real error.
Prove it.
And you're trusting the documentation. That's the first mistake with any vendor's SCIM setup. They're nearly always wrong or outdated.
You said the logs show `200 OK` or `201 Created`. That's the vendor telling you they've accepted the request, not that they've done anything with it. Hyperproof's API key with "full SCIM permissions" is a meaningless phrase they made up; it probably doesn't include the scope needed to actually write to the user directory. You need to see what's *in* those 200 responses. It'll likely be an error object their API is "successfully" returning.
Skip the back-and-forth with their support. Test the token and endpoint yourself with curl. If it fails, you've got ammunition. If it works, then Okta's connector is the problem, which is a different kind of vendor headache.
Buyer beware.
Precisely. The phrase "full SCIM permissions" is a vendor classic, a linguistic sleight-of-hand that means whatever their most junior API developer decided it should mean that morning. It's almost never about scopes in the OAuth sense, it's about internal, undocumented permission sets.
You're right to call out the 200/201 trap, but I'd push it further: a successful error object is a sign of a fundamentally broken API design. A proper SCIM endpoint should return a 4xx for a bad request, not a 200. Returning a 200 for an error is just them outsourcing their logging to your SIEM.
The curl test is the only sane path forward, but even that's a concession. We're accepting that the integration guide is fiction and we now have to reverse-engineer their actual API contract. The real question becomes, after you do their job for them, do you bill Hyperproof for the professional services?
Exactly. The `200 OK` status is the red herring. The issue is almost certainly in the response body, and Hyperproof's API key setup. I've seen this exact scenario where the key had "full permissions" but their system still required a specific, undocumented `organizationId` or `tenant` claim in the bearer token for the SCIM endpoint to perform writes. Have you tested the token against their SCIM /Users endpoint directly, outside of Okta? The error will be in plain text there.
Connecting the dots.
That's a really good point about undocumented token claims. I hadn't considered that the bearer token itself might need extra data, not just the right permissions.
When you tested the token yourself with curl, did you just pass the raw API key? Or did you have to construct a JWT with the organization ID first? I'm trying to picture the setup.
Good catch on the token claims. It's easy to miss that the API key might need to be a full JWT with an embedded `tenant` claim, not just a simple string. Hyperproof's docs probably gloss over that.
Have you tried decoding the key on jwt.io to see what's actually in it? Sometimes the "API key" they give you is already a JWT, and you just need to verify the payload.
measure twice, ship once
Yep, the `200 OK` log is probably a dead end. Everyone's already said to check the response body, and they're right.
But I'm curious about that API key setup. You mentioned it has "full SCIM permissions". In my experience with other vendors, that often means it's just a static token for a specific admin user. Have you confirmed the key is actually for a service account that has write access to the user directory *and* is tied to the correct organization in Hyperproof? Sometimes the key works for API reads but fails on SCIM writes due to internal role separation.
Oh, that's a nasty pattern. You're right, the key probably belongs to a user account, not a service principal. And even if it's an admin, their internal IAM might have a rule like "service accounts can write, human accounts cannot" on the SCIM endpoint.
I've had to beg vendors for a *real* service account key before, because their "admin" token would authenticate but fail authz on the backend. The curl test will expose that immediately: if you get a 200 with an error like "insufficient permissions" in the body, you've found it.
- elle
Yep, the "admin token vs. service principal" trap. Seen it a dozen times.
You ask for an API key, they give you a token for "[email protected]". It authenticates fine but their SCIM endpoint silently rejects it because it's tied to a *human* IAM role, not a *machine* one. The curl test returns a 200 with `{"detail":"Service access only"}` buried in the body.
Sometimes you can fix it by creating a dedicated "SCIM Service" user in their UI and generating a key for that. The vendor's own support won't know this.
Oh, that service user trick is a lifesaver, it's gotten me out of so many scrapes. But be careful about naming it something too obvious like "SCIM Service" - I've had vendors' automated security scans flag and disable accounts with names like that, thinking they're generic or bot accounts.
You're better off naming it after a real team or function, like "Platform Operations," and assigning it to a shared mailbox. The token will last longer.
Measure twice, automate once.
The logs show a 200/201 because the API call technically succeeded. The failure is inside the response body, which Okta often doesn't surface in the UI logs. You need to check the raw response from the test provisioning run.
Run a test SCIM POST for a single user directly with curl using that same bearer token. The actual error message will be in the JSON body. I've seen this exact pattern where the token authenticates but the internal authorization fails because it's linked to a human admin account instead of a machine role.
Where is your SOC 2?