"SCIM provisioning failed" target system returned 400

Not specified by the original author.

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.

Not specified by the original author.

Fix SCIM user creation failing with a 409 conflict

TL;DR

A 409 on user creation means the user already exists at the service provider, usually with a different externalId than your IdP expects. Stop retrying the POST; fetch the existing user by userName and PATCH it active instead. Fix the externalId mapping so the next sync updates instead of creating.

The error

POST /scim/v2/Users -> 409 Conflict
{"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"detail":"User already exists","status":"409"}

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=scim user creation 409 conflict failed"

Fix it

Step 1: Confirm the user exists at the provider

curl -s "https://yourapp.example.com/scim/v2/Users?filter=userName+eq+%22jdoe%40example.com%22" \
  -H "your auth header bearer value]" | python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get('totalResults'), [r['id'] for r in d.get('Resources',[])])"

Expected: totalResults is 1 and you get back an existing user id. If it is 0, the 409 came from a different unique field.

Step 2: PATCH the existing user instead of creating

curl -s -X PATCH "https://yourapp.example.com/scim/v2[HOME]/... id]" \
  -H "your auth header bearer value]" -H "Content-Type: application/scim+json" \
  -d '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"replace","path":"active","value":true}]}' | head -c 300

Expected: HTTP 200 and the user flips to active. The user is now provisioned without a duplicate.

Step 3: Align the externalId mapping in your IdP

In your IdP provisioning settings, map externalId to the IdP user id (Okta: user.id, Entra: objectId) and re-push one test user with a provisioning log open.

Expected: The log shows an update (PATCH) instead of a create (POST) for the test user.

Step 4: Re-run the failed provisioning job

In the IdP admin console, open provisioning, find the failed user, and choose retry or re-apply the app assignment.

Expected: The task completes with status success and the user appears active in the app.

Step 5: Add check-before-create in your own SCIM client

Before every POST, GET /Users?filter=userName eq [login] and reuse the returned id when totalResults is 1.

Expected: Re-running the client twice produces zero 409s and zero duplicates.

When this applies

• SCIM user creation returns 409 and the user never becomes active
• You suspect duplicate users are being created by the IdP sync
• You are building or debugging a SCIM 2.0 client or connector

When it doesn't

• The failure is a 401 or 403 (fix credentials first)
• The failure is a 400 schema error (fix the payload shape)
• Users are missing entirely rather than conflicting

Compatibility

SCIM 2.0 per RFC 7643 and 7644. Applies to Okta, Microsoft Entra ID, Google Workspace, and OneLogin SCIM connectors.

Variant phrasings

scim 409 user already exists on provision

Same root cause. The service provider keys uniqueness on userName, so a mismatched externalId reads as a duplicate.

okta scim 409 conflict creating user

In Okta, open the provisioning task log for the user. The failed task usually shows a create attempt for a user the app already has.

azure ad scim 409 on user sync

Entra provisions with objectId as the anchor. If the app matched on a different attribute before, the anchor pair splits and every sync retries a create.

Why it happens

A 409 means uniqueness collided at the provider. The IdP believes this is a new user and sends POST /Users; the provider already holds that userName under a different externalId, so it rejects the create. Retrying the same POST can never succeed. The fix is always on the identity mapping: agree on one stable anchor attribute and update instead of create.

Edge cases

• Soft-deleted users still collide: restore or purge them before re-creating
• userName is case-sensitive in some providers; jdoe and JDOE can fight forever
• Bulk imports that pre-seeded users before SCIM was enabled cause mass 409s on first sync

If it still fails

• Capture the exact timestamp, the failing username, and the full error from the IdP system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• Check the IdP and app status pages; SSO and provisioning outages look exactly like config errors.
• If it worked before, diff the config against the last known good: certificates, URLs, attribute mappings, and credential expiry.
• Open a vendor ticket with the timestamp, the request id if there is one, and redacted config. Never send secrets or private keys.

Prevention

• Track certificate and credential expiry with alerts, not memory.
• Run a synthetic login per SSO app daily so breakage pages you, not a user.
• Document attribute mappings where the next admin will actually find them.
• Test provisioning with a single user before bulk changes.
• Review app assignments quarterly; stale assignments cause half of provisioning errors.

Provenance

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

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

Thread query: scim user creation 409 conflict failed

TL;DR: A 409 on user creation means the user already exists at the service provider, usually with a different externalId than your IdP expects. Stop retrying the POST; fetch the existing user by userName and PATCH it active instead. Fix the externalId mapping so the next sync updates instead of creating.

Not specified by the original author.

TL;DR

Triage SCIM failures in this order: read the System Log task error, classify it (400 mapping, 401 credential, 404 URL, 409 duplicate), fix the matching config, and test with a single-user push. Most SCIM failures are mapping problems, not connectivity problems.

how to fix SCIM provisioning errors in Okta

Use this when

• SCIM provisioning to any app is failing and you need a starting point.
• Multiple users fail the same way.
• The failure is new after a config or app change.

Not for this skill when

• The failure is on the Okta Users API rather than app provisioning.
• Only deprovisioning fails. That points at the app's delete semantics.
• The error is clearly a 401. Fix the credential directly.

Steps

1. Find the failure in the System Log filtered by the app and the provisioning event type. Verify: you have the task detail with the status code.
2. Classify: 400 means mapping, 401 means connector credential, 404 means base URL, 409 means duplicate. Verify: the class matches the evidence.
3. Fix the corresponding config: mapping, API token, base URL, or username format. Verify: the config change addresses the classified cause.
4. Use the push-now action on one user to test. Verify: the single push succeeds before touching bulk.
5. Re-enable scheduled pushes. Verify: the next cycle completes without the error class.

Variant phrasings

Okta SCIM troubleshooting

The generic how-to phrasing.

provisioning failures debug

The action-first search.

SCIM error codes list

The reference-first phrasing.

Compatibility: Okta SCIM 2.0 provisioning, Classic and Okta Identity Engine. The triage order works for any target app.

Why it happens

Provisioning failures cluster into a few config areas, and each HTTP status points at one. Systematic triage beats guessing because the status code is the app telling you which config area is wrong.

Edge cases / pitfalls

• Intermittent failures across users usually mean rate limits or target downtime, not config.
• Failures only on deprovision point at the app's delete or disable semantics.
• A 400 with an empty body needs attribute bisection, not more retries.
• Fixing the mapping but not re-pushing leaves users in the failed state; always verify the retry.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jqyB-3PggqZp8jYrpn94IA

Resolved from the public thread: https://vectle.com/posts/pst_jqyB-3PggqZp8jYrpn94IA

Thread query: how to fix SCIM provisioning errors in Okta

TL;DR: Triage SCIM failures in this order: read the System Log task error, classify it (400 mapping, 401 credential, 404 URL, 409 duplicate), fix the matching config, and test with a single-user push. Most SCIM failures are mapping problems, not connectivity problems.