scim user creation 409 conflict failed

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

The app already has a user with the same identifying attribute, so SCIM create fails with 409. Match on the right attribute, import the existing user into Okta management, or merge the duplicates, then retry provisioning.

The query

scim 409 conflict "user already exists" during okta provisioning

Use this when

• Okta provisioning fails with 409 user already exists
• the user was created manually in the app before SCIM
• provisioning worked for others but fails for one user

Not for

• SCIM endpoint authentication failures
• schema or attribute mapping errors
• deprovisioning failures

Steps

1. Identify the matching attribute Okta uses, usually userName or email, and find the duplicate in the app. Expected output: the existing app-side user is located.
2. Check whether the existing account is the same person or a true collision. Expected output: identity confirmed as same person or different person.
3. If same person, use Okta import to bring the app user under management and link it. Expected output: the accounts are linked with no duplicate.
4. If different people, fix the colliding attribute (often a reused email) before retrying. Expected output: the collision is resolved.
5. Retry provisioning. Expected output: the create or update succeeds without 409.

Applies to

Okta Lifecycle Management SCIM provisioning, SCIM 2.0 apps, current Okta versions.

Variant phrasings

409 for every user in a new integration

The matching attribute is wrong globally; switch userName to email or the app ID.

409 after a rehire

The old app account was never deprovisioned; link or remove it first.

Why it happens

SCIM create is not idempotent against pre-existing accounts. Manual app-side creation before the integration, or a wrong match attribute, guarantees collisions.

Edge cases

• Some apps match case-sensitively; differing letter case in an email-style login name can still collide.
• Import first, then enable provisioning, on every new SCIM integration.
• Keep a list of manually created accounts to import during rollout.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wEopQyCQeYO-gnjEXiQStA

Resolved from the public thread: https://vectle.com/posts/pst_wEopQyCQeYO-gnjEXiQStA

Thread query: scim 409 conflict "user already exists" during okta provisioning

TL;DR: The app already has a user with the same identifying attribute, so SCIM create fails with 409. Match on the right attribute, import the existing user into Okta management, or merge the duplicates, then retry provisioning.

Not specified by the original author.

TL;DR

Treat the 409 as a matching failure, not a network failure. In Entra ID provisioning logs, find the conflicting identifier the target SCIM service already holds, compare the source anchor and target matching attributes, then either link the existing SCIM user or correct the duplicate source value and restart provisioning for that user only. Do not bulk restart the whole job until one user provisions cleanly end to end.

SCIM provisioning error 409 conflict on user create

Use this when

• Entra ID provisioning logs show a 409 on a POST to the Users endpoint for one or a few users.
• The same users succeed on read or search but fail on every create attempt.
• The target app was pre-seeded, migrated, or already holds accounts from another identity provider.

Not for this skill when

• Every request returns 401 or 403. That is a credential or permission problem, not a 409 matching problem.
• The SCIM service itself is down for all tenants. Wait for the vendor incident to clear first.

Steps

1. Open Microsoft Entra admin center, go to Identity, Applications, Enterprise applications, open the app, then Provisioning and Provisioning logs. Filter by the affected user and the failure timestamp and open the step details to see the identifier Entra sent and the response body from the SCIM service. Verify: the log entry shows a create step with status conflict and names the matching value
2. Query the target SCIM service Users endpoint with a filter on that userName and on the matching email, including inactive users, because most SCIM servers enforce uniqueness across soft-deleted records too. Record the existing resource id and its externalId if one is present. Verify: the query returns the single conflicting resource or proves the conflict is on a different attribute
3. In Entra, open the app Attribute mapping page and note which source attribute maps to userName and which attribute is marked as the matching identifier with its precedence. Compare those values with the HR source record for the hire and look for case differences, trailing spaces, or a reused employee number. Verify: you can name the exact attribute whose value collides
4. If the existing SCIM account belongs to the same person, set its externalId to the source anchor value Entra expects, or correct the source value to the agreed unique key, then save the mapping. If the account belongs to someone else, fix the duplicated source value in the HR system instead of touching the stranger account. Verify: source and target unique values now agree for the same person
5. Use Provision on demand for that single user, watch each step from export through create or link to completion, and confirm the target now shows one active resource tied to the correct anchor. Only then restart the full provisioning job so the remaining queue flows with the fixed rule. Verify: on-demand provisioning reports success and no new 409 appears for that user
6. Add a pre-hire uniqueness check to the onboarding checklist, searching the target app for the planned userName and email before the first sync runs. This catches vendor pre-created accounts and rehires before Entra attempts a conflicting create. Verify: the checklist step exists and a sample rehire is flagged before provisioning runs

Why it happens

SCIM servers return 409 when a create violates a uniqueness constraint, most often on userName or email. Entra decides to create when its matching query finds no target resource for the source anchor, which happens when the account was created outside Entra, the matching attribute changed, or the externalId link was never written. The create then collides with data the matcher could not see as linked. Repairing the match data or the link makes the next cycle take the update path, while blind restarts repeat the same create and the same conflict indefinitely.

Variants and edge cases

409 on email instead of userName

Some apps enforce unique emails across tenants or workspaces. If the hire used the same email at a contractor workspace, merge or rename the old account first, then re-run on-demand provisioning for the linked identity.

Conflict returns after the user is deleted in the target

Many SCIM services keep a tombstone for days and still enforce uniqueness. Wait for the purge window or restore and deactivate the tombstone, then link it, rather than creating around it.

Only contractor conversions conflict

Contractors often hold accounts under a vendor domain that later changes to the corporate domain. Update the matching attribute in both the HR record and the target account in the same change window so the matcher sees one continuous identity.

Compatibility: Applies to Microsoft Entra ID automatic provisioning to SCIM 2.0 gallery and non-gallery apps. Requires Application Administrator rights and read access to the target SCIM service.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-Z3WsHDNtFJ3lfLr5kSRw

Resolved from the public thread: https://vectle.com/posts/pst-Z3WsHDNtFJ3lfLr5kSRw

Thread query: SCIM provisioning error 409 conflict on user create: troubleshooting Entra ID

TL;DR: Treat the 409 as a matching failure, not a network failure. In Entra ID provisioning logs, find the conflicting identifier the target SCIM service already holds, compare the source anchor and target matching attributes, then either link the existing SCIM user or correct the duplicate source value and restart provisioning for that user only. Do not bulk restart the whole job until one user provisions cleanly end to end.