E0000047 API validation failed" SCIM user create
Fixes Okta E0000047 SCIM user-create failures by reading the target app's SCIM schema and correcting the attribute mapping. Use when provisioning returns E0000047 on user create. Not for 409 duplicate-user conflicts or 401 connector auth failures.
TL;DR
E0000047 means the SCIM request reached the target app but the app rejected the payload. The fix is on the mapping side: check the app's SCIM attribute requirements, especially required fields and their formats, then force a re-provision.
"E0000047 API validation failed" SCIM user createUse this when
- Okta provisioning to a SCIM app fails with E0000047 on user create.
- The Okta side looks fine but the target app keeps rejecting.
- The failure started after an app or mapping change.
Not for this skill when
- The error is a 409 conflict. That is a duplicate user, a different fix.
- The connector itself cannot authenticate. That is a credential problem.
- Users fail on update but create works. Check the update mapping separately.
Steps
- Open the failed provisioning task in the Okta System Log and read the full error detail. Verify: you have the target app's rejection reason, not just the Okta code.
- Read the target app's SCIM schema for the User resource, noting required attributes. Verify: you know exactly which fields the app demands.
- Open the app's Provisioning settings, then the To App attribute mapping. Verify: every required target field is mapped from a non-empty Okta attribute.
- Fix formats the app is picky about: userName shape, email validity, name parts. Verify: the mapped values match the app's documented format.
- Force a re-provision for one affected user. Verify: the task succeeds, then re-enable scheduled provisioning.
Variant phrasings
SCIM 400 bad request
The underlying HTTP status behind E0000047.
"failed to create user" SCIM
The symptom-level phrasing.
Okta provisioning error E0000047
The code-first search.
Compatibility: Okta SCIM 2.0 provisioning, Classic and Okta Identity Engine. Target-app specifics vary; the triage order does not.
Why it happens
Each app implements SCIM slightly differently. Okta's default profile mapping sends a standard attribute set, and apps with stricter schemas reject fields that are missing, malformed, or unexpected. The rejection surfaces as E0000047 on the Okta side.
Edge cases / pitfalls
- Apps that require the email address as userName while Okta sends a login that is not an email.
- Apps that reject profile updates to name fields after create but accept them on create.
- Trial or sandbox app orgs where user creation is disabled entirely.
- Custom attributes the app documents but its SCIM endpoint does not actually accept.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_QWsbveA1hSD5BG6efpM93Q