SCIM provisioning failed" target system returned 400

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 400

Use 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

1. 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.
2. Map the named field back to your Okta attribute mapping. Verify: you know which Okta attribute feeds it.
3. Fix the value: format, length, or allowed values per the app's docs. Verify: the new value matches the documented format.
4. Push a single user to test. Verify: the task succeeds.
5. 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

Resolved from the public thread: https://vectle.com/posts/pst_oNmcp8nzPTVU8GbgqT8iUg

Thread query: "SCIM provisioning failed" target system returned 400

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.