ndovuscim

SCIM error decoder400 + invalidFilterRuns in your browser - nothing leaves this page.

400 (GET, POST, PUT, PATCH, DELETE): Bad Request: request is unparsable, syntactically incorrect, or violates schema. The body MAY carry a scimType from Table 9.

invalidFilter: The specified filter syntax was invalid (does not comply with Figure 1), or the specified attribute and filter comparison combination is not supported.

Applicability: GET (3.4.2), POST Search (3.4.3), PATCH Path Filter (3.5.2). The applicability column applies to the normal HTTP method and MAY apply within a bulk operation (Table 9 note).

Likely causes:
  • Syntax outside the Figure 1 ABNF: an unterminated string, a missing operator, trailing input.
  • An ordered comparison (gt, ge, lt, le) against a Boolean or Binary attribute; Table 3 routes it here.
  • An unrecognized operator: providers MUST reject it with invalidFilter (Section 3.4.2.2).
  • A provider declined a syntactically valid filter outside its documented subset; Zoom answers with its verbatim text below.

Error envelope (Section 3.12)

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:Error"
  ],
  "status": "400",
  "scimType": "invalidFilter",
  "detail": "Invalid filter syntax"
}

The Error schema is urn:ietf:params:scim:api:messages:2.0:Error; status is REQUIRED and expressed as a JSON string; scimType and detail are OPTIONAL.

Provider-verbatim error strings

providerverbatimmaps towhat it means
zoomThe current filter is not supported
developers.zoom.us SCIM2 reference, accessed 2026-11-01
400 invalidFilterZoom documents exactly two List filters (userName eq, externalId eq); anything else declines with this text.
slackunable_to_create_team_profile_fields
docs.slack.dev SCIM API docs, accessed 2026-11-01
400 invalidValue (shape)Slack answers with its own code instead of a scimType, and one invalid custom profile field drops the entire profile.
aws429 ThrottlingException
AWS IAM Identity Center user guide (limits), accessed 2026-11-01
429 ThrottlingExceptionWrite APIs 25 TPS and read APIs 40 TPS per Identity Store instance; each membership operation counts toward a separate throttle.
oktaRetry-After parsed only as integer seconds; HTTP-date or missing header defaults to a 5-minute wait
developer.okta.com SCIM concepts, accessed 2026-11-01
429 Retry-After ruleRetry-After is honored only as integer seconds; an HTTP-date or missing header defaults to a 5-minute wait, each subsequent failure doubles the wait, and after 10 attempts the task fails permanently.

Provider rows are verbatim strings from each provider's documentation, dated by retrieval; the mappings are this playground's teaching judgment, not provider statements.

RFC 7644 · SECTION 3.12 ERRORS

The error decoder

Map SCIM status codes and scimType values from RFC 7644 Section 3.12 to their causes, with provider-verbatim error strings beside each mapping.

Runs in your browser - nothing leaves this page.RFC 7644 Sections 3.12 and 7.5.2

The playground pairs each HTTP status from Table 8 with any Table 9 keyword, quotes the RFC's own description and applicability, and lists the likely causes for each scimType. Below the mapping sit four provider-verbatim strings, because production errors rarely arrive in the RFC's vocabulary. This page is a complement to conformance tools, not another validator: conformance suites assert what a good server returns; this playground reads what a real server said.

The history

Why errors need decoding at all

Section 3.12 defines one error envelope - schemas, status (REQUIRED, a JSON string), scimType (OPTIONAL), detail (OPTIONAL) - and two tables: Table 8 for statuses, Table 9 for the tenscimType keywords, all defined on HTTP 400. The RFC's own example needed an erratum: the 400 mutability example JSON shipped missing a comma (erratum 7898, verified), and the no-change PATCH example response carries headers that erratum 5295 reports. The canon is readable, but it is not pristine.

The wider failure is divergence. Providers answer with their own vocabulary where the RFC allows freedom: Slack returns unable_to_create_team_profile_fields instead of ascimType; AWS surfaces throttling as 429 ThrottlingException; Zoom declines unsupported filters with a fixed sentence; Okta's client behavior turns the Retry-After header's format into minutes of paused syncing. A provisioning connector that pattern-matches only the RFC shapes misreads all four, and the operational result is a quarantined sync job with a log line nobody can decode.

The decoder's rule: the status tells the client what class of thing happened; the scimType tells which rule fired; the provider string tells which implementation said it. Read in that order, most SCIM support tickets answer themselves.

The decision path

From status line to fix

The status selects the row; on 400 the scimType selects the keyword; Retry-After and the provider string select the response.

Error decision path: status class, then scimType keyword on 400, then provider-specific headers and stringsresponse arrivesstatus + Error bodystatus classTable 8scimType (400 only)Table 9, ten keywordsprovider layerRetry-After, codes4xx the request was wrong: fix the body, the filter, or the path401/403 the credentials are wrong: fix the token, not the request404 the target is wrong: check matching, not syntax409/412 the state is wrong: re-read the resource, retry conditionally429 the pace is wrong: honor Retry-After, then back off5xx the provider is wrong: log, quarantine, retry laterscimType is OPTIONAL and defined for 400 only (Table 9); its applicability column names the methods and sections it can arise on
The mechanics

The envelope, the tables, and the header

The envelope. Errors ride urn:ietf:params:scim:api:messages:2.0:Error withstatus REQUIRED and expressed as a JSON string, scimType OPTIONAL, anddetail OPTIONAL. Implementers MUST return the JSON body, not a bare status line.

Table 8. The status rows carry suggested explanations: 400 for unparsable or schema-violating requests; 401 for an invalid or missing authorization header; 403 for a permitted authentication acting without permission; 404 for a missing resource or endpoint; 409 for version conflicts and refused duplicates; 412 for a resource that changed underneath the write; 413 for bulk limits; 500 and 501 for the provider's own failures. 307 and 308 move the request; the temporary form keeps the original URI.

Table 9. Ten keywords, all on 400: invalidFilter, tooMany,uniqueness, mutability, invalidSyntax,invalidPath, noTarget, invalidValue,invalidVers, and sensitive. The applicability column names the method and section each can arise on, and the table's closing note extends that column to bulk operations. Two keywords are pure PATCH (invalidPath, noTarget); one is pure privacy (sensitive, the Section 7.5.2 rule against personal data in request URIs).

429 and Retry-After. Throttling is not a Table 8 row; it arrives as HTTP 429 (RFC 6585) with Retry-After. The header's format is where providers diverge: Okta's client honors it only as integer seconds, defaults to a five-minute wait on an HTTP-date or a missing header, doubles the wait per failure, and fails the task after ten attempts. AWS counts writes and reads against separate per-instance throttles and surfaces the rejection as ThrottlingException.

Reading provider strings. A verbatim string is evidence of one implementation at one date, not a second standard. The playground labels its four rows with the retrieval date and maps each to the nearest Table 9 shape as a teaching judgment, never as a provider statement.

Attacks and defenses

What each defense is for

FailureDefenseWhere it is defined
Personal data in filter query strings, logged end to end400 sensitive, and POST /.search with the filter in the bodyRFC 7644 Sections 7.5.2 and 3.4.3, Table 9
Distinguishing "user does not exist" from "you may not know" during probingKeep error shapes consistent; newer SCIM work extends the identical-error rule to pagination boundariesRFC 7644 Section 3.12; RFC 9865's security section
A client hammering a throttling provider because it ignored 429Honor Retry-After with the provider's documented format rules; back off on silenceRFC 6585; Okta and AWS provider documentation (dated in the provider rows)
One bad field dropping an entire profile update without an obvious causeMap provider-specific codes to a Table 9 shape so the log names the failing rule; Slack's custom-profile overflow is the case studySlack SCIM documentation (accessed 2026-11-01)
Retries that re-send a request the provider already applied409 and 412 mean re-read before rewrite; ETags make the retry conditionalRFC 7644 Sections 3.12 and 3.14
References