SCIM
GET/scim/v2/ResourceTypes
curl -X GET "https://example.com/scim/v2/ResourceTypes"GET/scim/v2/Schemas
The third of the three discovery endpoints RFC 7644 requires. Absent, a client asking for it falls through to the plain-text 404 handler rather than a SCIM error body, and reads a conformant server as broken.
Only the attributes this server actually stores or acts on are declared, for the same
reason ServiceProviderConfig declares only what is built: a client adjusts its behaviour
to what it reads here.
Response Body
application/json
curl -X GET "https://example.com/scim/v2/Schemas"GET/scim/v2/ServiceProviderConfig
Okta reads this before its first provisioning call and adjusts behaviour to match, so every flag has to describe what is actually built rather than what is intended.
Response Body
application/json
curl -X GET "https://example.com/scim/v2/ServiceProviderConfig"GET/scim/v2/Users
The organization comes from the credential rather than the request, so a provisioning client can only ever see the directory it was issued for.
Authorization
bearer_token In: header
Query Parameters
int640 <= valueint640 <= valueResponse Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/scim/v2/Users"{ "Resources": [ null ], "itemsPerPage": 0, "schemas": [ "string" ], "startIndex": 0, "totalResults": 0}POST/scim/v2/Users
Authorization
bearer_token In: header
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
What a provisioning client sends to create a user.
Deliberately narrow. Everything else Okta may send is ignored rather than refused: a strict reading of unknown attributes turns a working integration into a support ticket the next time the customer edits their Okta profile mappings.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/scim/v2/Users" \ -H "Content-Type: application/json" \ -d '{ "userName": "string" }'{ "active": true, "displayName": "string", "emails": [ { "primary": true, "type": "string", "value": "string" } ], "externalId": "string", "id": "string", "meta": { "created": "string", "lastModified": "string", "location": "string", "resourceType": "string" }, "name": null, "schemas": [ "string" ], "userName": "string"}GET/scim/v2/Users/{id}
Authorization
bearer_token In: header
Path Parameters
Provisioned user id
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/scim/v2/Users/string"{ "active": true, "displayName": "string", "emails": [ { "primary": true, "type": "string", "value": "string" } ], "externalId": "string", "id": "string", "meta": { "created": "string", "lastModified": "string", "location": "string", "resourceType": "string" }, "name": null, "schemas": [ "string" ], "userName": "string"}PATCH/scim/v2/Users/{id}
Deactivation and a displayName push are acted on - the same two things PUT applies,
through the same door, so the two verbs cannot disagree about what a profile push does.
Anything else is refused rather than silently accepted: a client told its push landed
while nothing changed never converges.
Authorization
bearer_token In: header
Path Parameters
Provisioned user id
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X PATCH "https://example.com/scim/v2/Users/string"{ "active": true, "displayName": "string", "emails": [ { "primary": true, "type": "string", "value": "string" } ], "externalId": "string", "id": "string", "meta": { "created": "string", "lastModified": "string", "location": "string", "resourceType": "string" }, "name": null, "schemas": [ "string" ], "userName": "string"}DELETE/scim/v2/Users/{id}
Authorization
bearer_token In: header
Path Parameters
Provisioned user id
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X DELETE "https://example.com/scim/v2/Users/string"PUT/scim/v2/Users/{id}
Okta uses this for deprovisioning too when PATCH is not configured, so the body's
active is what decides. A replace that leaves the user active has nothing to do here.
Authorization
bearer_token In: header
Path Parameters
Provisioned user id
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X PUT "https://example.com/scim/v2/Users/string"{ "active": true, "displayName": "string", "emails": [ { "primary": true, "type": "string", "value": "string" } ], "externalId": "string", "id": "string", "meta": { "created": "string", "lastModified": "string", "location": "string", "resourceType": "string" }, "name": null, "schemas": [ "string" ], "userName": "string"}