# Fix SCIM PATCH operation failing with schema violation

## TL;DR
A schema violation on PATCH means the operation references an attribute path the provider does not support, or sends a value of the wrong type. Validate the path against the provider's schema endpoint first. Then rewrite the patch to use only supported paths and types.

## The error
```text
PATCH /scim/v2[HOME]/... -> 400 Bad Request
{"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"scimType":"invalidPath","detail":"Schema violation","status":"400"}
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=scim patch operation failed schema violation"
```

## Fix it

### Step 1: Fetch the provider's schema

```bash
curl -s "https://yourapp.example.com/scim/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:User" \
  -H "your auth header bearer value]" | python3 -m json.tool | head -60
```

Expected: You see the real attribute list. Any path you patch must appear here.

### Step 2: Check your failing path against it

```bash
Compare the path in your PATCH operation with the schema attributes, watching for case and sub-attribute names.
```

Expected: You find the mismatch: a wrong path, a wrong type, or an extension schema you never declared.

### Step 3: Declare extension schemas when patching extension attributes

```bash
Add the extension schema URI to the schemas array of the PATCH body.
```

Expected: The provider accepts the operation instead of rejecting the path.

### Step 4: Fix the value type

```bash
Send booleans as booleans and multi-valued attributes as arrays, not strings.
```

Expected: The PATCH returns 200.

### Step 5: Replay the original failing operation

```bash
Re-run the exact PATCH that failed, with the corrected path and types.
```

Expected: 200 with the attribute updated as expected.

## When this applies

- SCIM PATCH calls fail with schema violation or invalidPath
- Some attributes update fine while others always fail
- You are building a SCIM client against a new provider

## When it doesn't

- PATCH returns 404 (the user id is wrong, not the schema)
- PATCH returns 401 (fix auth first)
- The whole payload is rejected (check Content-Type is application/scim+json)

## Compatibility

SCIM 2.0 PATCH per RFC 7644 section 3.5.2. Provider schema support varies.

## Variant phrasings

### scim invalidpath error on patch

invalidPath is the scimType for this. The schema endpoint is the source of truth for valid paths.

### scim patch schema violation extension attribute

Extension attributes need their schema URI declared in the request. Without it, the path looks invalid.

### scim 400 bad request patch user

When the scimType is invalidValue instead, the path is fine but the value type is wrong.

## Why it happens

SCIM providers each implement a subset of the schema, and PATCH paths are validated strictly. A path that works against one provider fails against another that never implemented that attribute. Extension attributes add a second trap: the path is only valid when the extension schema URI is declared in the request.

## Edge cases

- Some providers accept a path on create but reject it on PATCH; test both
- Case matters: userName and username are different paths to a strict provider
- Bulk PATCH operations fail the whole batch on one bad path in some implementations

## 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_fjC4Ey2oocSXIjCJGyN6GA