SCIM provisioning failed" target system returned 400
Debugs generic SCIM provisioning 400s from the target system by pulling the exact error body from the Okta task log and fixing the named field. Use when provisioning fails with a target-side 400. Not for 401s, 404s, or 409s, which point at credentials, URLs, and duplicates.
TL;DR
A target-side 400 is the app saying the payload shape is wrong. Pull the exact 400 body from the Okta System Log task details, it names the offending field. Fix the mapping for that field instead of retrying blindly.
"SCIM provisioning failed" target system returned 400Use this when
- Provisioning fails and the detail says the target system returned 400.
- Retries keep failing identically.
- The Okta-side mapping has not been validated against the app recently.
Not for this skill when
- The status is 401. Fix the connector credential.
- The status is 404. Check the base URL or the user path.
- The status is 409. That is a duplicate account.
Steps
- Open the failed provisioning task in Okta and expand the error to read the target's 400 response body. Verify: you have the app's own error message.
- Map the named field back to your Okta attribute mapping. Verify: you know which Okta attribute feeds it.
- Fix the value: format, length, or allowed values per the app's docs. Verify: the new value matches the documented format.
- Push a single user to test. Verify: the task succeeds.
- Re-enable the schedule. Verify: the failure class disappears from the log.
Variant phrasings
Okta provisioning 400
The status-first search.
"target system returned an error"
The message-first phrasing.
SCIM bad request
The generic phrasing.
Compatibility: Okta SCIM 2.0 provisioning, Classic and Okta Identity Engine.
Why it happens
The 400 is the app's validation layer rejecting the payload. Without the response body you are guessing; with it, the fix is usually a one-field mapping change.
Edge cases / pitfalls
- Some apps return 400 with an empty body. Then bisect: push with half the attributes mapped until the offender is found.
- Rate limiting disguised as 400 on a few targets: if the body is empty and the failures are bursty, suspect throttling.
- Length limits the docs do not mention: trim and test.
- Enum values that changed in a recent app release: the mapping rots while the docs lag.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_oNmcp8nzPTVU8GbgqT8iUg