Last modified 03 May 2023 21:50 +02:00

Version: 4.4
Status: Public
Stability: STABLE, only backward-compatible changes expected
Platform: RESTful interface
Dependencies: Data Model, Common schema, Query schema
Responsible person: Katarina Bolemant



MidPoint "REST API" is an HTTP-based application programming interface. This interface is a set of web resources that provide access to internal midPoint functionality.

Terminology note

We call this interface "REST API" even though it is in fact not entirely RESTful. This API is not hypertext-based. Hypertext is not intended paradigm for this interface. Also, we are not strictly restful in some details. E.g. there are combined web resources that perhaps should be modeled as many smaller web resources if we would follow a strict RESTful approach. However that would be painfully inefficient to use. There are also some parts that are obviously RPC-based. We are doing this to make the API practical as practicality is our highest priority. Yes, we should not call this interface "REST". But almost everyone else does call things like this "REST", and almost everyone expects to see a "REST" interface, so please excuse us.

Use of HTTP Verbs

MidPoint REST API tries to adhere to the usual HTTP verbs and tries to maintain their original meaning:

Verb Meaning and usage


Information retrieval. Returns the state of the web resource. Also used to execute searches.


Create new web resource. This usually means creation of a new object. However, the client has to provide a complete object, including the identifier (URI). Which is not entirely practical, as this means that the client needs to know how to properly construct the URI. Therefore this operation is seldom used.


POST is used for several purposes:

  • Create new web resources without the need to know the URI. POST to a collection web resource will result that a new sub-resource is created.

  • As an equivalent for PATCH operation (see below). Some HTTP clients have problems when using non-standard verbs. Therefore we provide POST as an alternative way to modify objects.

  • To pass data to an RPC-like operation.


Modification of existing web resource. Usually modification of existing midPoint object. This is non-standard HTTP verb. The usage of PATCH is preferred because its meaning is much more clear than the desperately overloaded meaning of POST. However, POST is provided as an equivalent to PATCH for HTTP clients that have problems with non-standard verbs.


Delete existing resource. This is used mostly to delete objects.

Safe GET

HTTP GET is a safe operation. The use of GET does not change the state of a web resource. GET will never cause a (direct) modification. This is given by the REST architectural style. We consider this to be a very good idea and this approach is adopted by midPoint REST API.

However, object retrieval in midPoint can have side effects. Maybe midPoint will find out that an account that HTTP GET is trying to retrieve does not exist. In that case midPoint consistency mechanism may be triggered and it can modify the state of the midPoint objects. Therefore there may be indirect changes in the objects even if GET is used. However, those changes are not direct consequence of the GET operation. Those are consequence of changed environment, and they are only discovered when GET operation is in progress. Those changes would happen anyway, whether GET is used or not. It just may take a bit longer for midPoint to discover that. Therefore we still consider GET to be a safe operation.

Web Resource Types

MidPoint REST API is not entirely RESTful. There are operations that would be very difficult and very inefficient if modeled as pure RESTful web resource - just because the very nature of those operations is to invoke an operation. Therefore the API web resources are divided into two broad categories:

  • Create-Read-Update-Delete (CRUD) web resources: Those resources try to adhere to the RESTful approach as close as possible (a.k.a. "almost real REST web resources"). Those resources support the full range of HTTP verbs and they almost behave in a way that can be expected from a RESTful API. Those resources can be subdivided into two groups:

    • Individual web resources usually represent a single midPoint object. They are used to retrieve a specific object, modify it, delete it - and in the very impractical case of PUT also create it. Typical example is a web resource that represents a single user (e.g. URI …​/ws/rest/users/ca8fb11c-72ae-11e7-a09e-9f03da78ca34).

    • Collection web resources represents collection of objects such as "all users" or "all roles". Those resources can be used to list and search for objects of a particular type (GET operation). Collection resources may also be used to create new objects of a particular type (POST operation). Typical example is a web resource that represents all users (e.g. URI …​/ws/rest/users).

  • Remote Procedure Call (RPC) web resources: Those are simply endpoints for RPC-like operations. They typically support only POST operation. There are also two sub-groups:

    • Object-related RPC operations: Operations that deal with a specific midPoint object. They are hierarchically located in the namespace of that object. Typical examples are operations to suspend and resume tasks (e.g. URI …​/ws/rest/tasks/e630b1fe-72af-11e7-8500-771f92d1099a/suspend). Even though they are located in the namespace of (REST-like) object web resource, those are in fact almost pure RPC operations. Speaking strict REST those operations might in fact be modeled as state changes in the object (web resource) that they "belong" to. But we have decided to model those operations as RPC-like for several reasons. Those are non-trivial operations that may have complex consequences, the operations may fail in a non-trivial way, we may need to execute them in an asynchronous mode in the future and so on. Modeling those as state changes would pollute both the server and the client code with a lot of special-case-handling code and it would make everything more complex and fragile. Therefore we have decided not to follow strict REST guidelines here and to model those operations as RPC.

    • Global RPC operations: Operations that do not deal with any specific object, operations that deal with broad selection of objects or simply operations that cannot be classified to any of the above categories. Typical example is an execution of a bulk action.

Creation of New Resources

According to REST architectural style the web resources should be created by PUT operation. However, this assumes that the client knows the URI and therefore it is not very practical. E.g. URI of most midPoint objects contains Object ID, which may or may not be provided by the client. In case that the OID is server-generated the PUT operation is out of question. But even if the OID is client-generated this would expect that the client knows how to construct a URI, which is not very RESTful. Therefore the PUT operation is not very practical.

The usual way how to create a new object in midPoint REST API is to use POST operation to a collection resource. E.g. new user is created by posting the user object to "users" collection (…​/ws/rest/users). MidPoint will react by creating a new user object and publishing that as a new web resource (with new URI). MidPoint REST API will respond with and redirection HTTP status (3xx) pointing client to the new URI.

Return Values

GET operations are supposed to return data. GET invoked on REST-like resources returns what anyone would probably expect: either individual midPoint object or a collection of midPoint objects. All such resources are supposed to behave in the same way, regardless of their type. PUT/POST/PATCH/DELETE for those resources also works in the same way. It returns HTTP status code or indicates an error or asynchronous operation (see below).

However, the situation is very different for the RPC-like resources. The indication of error and asynchronous processing is the same here. But all the rest is different. Those operations usually take data using the body of a POST request. And the data format may be completely different for each operation. The output also differs a lot. Success/failure is always indicated by the HTTP error code. But the data returned on success vary according to the definition of the specific web resource that is used. This is quite expected as those are essentially procedure calls.

Operation success and errors are always indicated by the HTTP error code. MidPoint REST API maintains the original HTTP meaning of the error code classes:

Error code Meaning


Information. Stay tuned, operation is in progress.


Success. Operation finished successfully. There are two custom codes:

  • 250 for partial error which means that during processing some error occurred but some changes was executed.

  • 240 for handled error which means that there was originally error, but midPoint was able to fix this using its consistency mechanism.

In this two cases, midPoint returns the OperationResult where there details of executed operations can be found.


Redirection or "in progress". This is returned mostly to indicate two cases:

  • Operation has finished, but the results are not in this resource. Redirection is issues to point the client to the results. Typical example is creation of an object with POST to a collection web resource. In this case a new object is created, new URI is assigned and the client is redirected to this URI. Retrieving that URI provides created object and 200 status code, indicating that the operation is finished.

  • Operation is in progress (asynchronous operation). In this case midPoint API redirects the client to a task object that can be used to track progress of the operation.


Client errors. The client has sent request that cannot be processed. This indicates usual situation that are well handled by the midPoint code. Maybe the client request to create conflicting object, delete non-existent object, modification that violates the schema and so on. The OperationResult structure is usually provided in the response to provide more details about the situation.


Server errors. Situations that the server cannot handle and where the cause is unknown. This usually means bugs in the code, insufficient resources such as RAM or disk space, unforeseen failures in the infrastructure and so on. The OperationResult structure might or might not be provided in this case. Some errors are so severe that the structured error information might not be available.

Status codes and the indication of errors and asynchronous processing applies uniformly to all midPoint web resources (both RESTful and RPC).

Synchronous and Asynchronous Operations

Most midPoint operations are currently implemented in a synchronous fashion. When talking about REST API this means that they will not return HTTP response until they are finished. When the operation is finished, midPoint will respond with success (2xx) or error (4xx, 5xx). If new resource is created, redirect status (3xx) is indicated. Retrieving that resource should result in success (2xx).

There are also some operations that are executed asynchronously. In that case midPoint returns HTTP response as soon as the operation is initiated. The status in the response will indicate redirection (3xx). The redirection target is a task that can be used to track operation progress.


Use basic authentication. Username and password should correspond to the username and password of appropriately privileged midPoint user. For example, the default ones are:

Username: administrator

Password: 5ecr3t

Supported media types

The following formats and related media types are supported:

Format Media type


application/xml, application/*+xml, text/xml




application/yaml, application/yml, application/*+yaml, application/*+yml, text/yaml, text/yml, text/*+yaml, text/*+yml
Note: There is no official registered media type.

Some operations return plain text only (text/plain).

Supported object types

Currently supported object types are listed in the following table.

class REST type























































Table 1. Supported types.

Supported operations

The base URL of REST API is http://localhost:8080/midpoint/ws/rest (alternatively to /ws/rest paths /api/model and /rest/model are also supported).

  • Use the base URL + path from the table below to request concrete operation.

  • Supply the {type} with the specific type of object you want to add (or modify, delete, search, etc). Supported types are listed in Table 1 above.

  • Supply the {oid} with the specific oid of your object.

  • Some operations support specifying options influencing the operation execution, e.g. if the execution is made in raw mode, or the shadows are not fetched from the resource, etc. Supported options column shows supported options for different operations. To specify option, use query parameters, e.g. http://localhots:8080/midpoint/api/model/users*?options=raw*

Operation name Operation type Path Supported options Data Response

Create new object




Object to create in the XML form

  • 201 Created, Location set to point to the newly created object

  • 240 Handled error, OperationResult is returned in the body

  • 250 Partial error, OperationResult is returned in the body

Create or update object




Object to create in the XML form

  • 201 Created, Location set to point to the newly created object

  • 240 Handled error, OperationResult is returned in the body

  • 250 Partial error, OperationResult is returned in the body

Get object





  • 200 OK, current object in the response body

Modify object




Modifications in XML format

Delete object





Test (configured) Resource





  • 200 OK, result of the test operation in the body

Import from Resource





  • 303 See Other, Location set to point to the concrete "import" task

Find owner of shadow





  • 200 OK, owner of the shadow returned in the response body

Import shadow





  • 200 OK, result of the import operation in the body





Query in XML format

  • 200 OK, list of found objects in the body

Suspend tasks





  • 204 No Content

Resume tasks





  • 202 Accepted

Schedule task now





  • 202 Accepted

Notify change




Resource object shadow change description

  • 200 OK

Generate value for concrete object




Policy for items describing how to generate the value (PolicyItemsDefinitionType)

Generate value





Validate value for concrete object





Validate value





Get user’s value policy




  • 200 OK, value policy for user in the response body

Get 'self'




  • 200 OK, current object in the response body

Search objects by type




  • 200 OK, list of object of specified type in the response body

Reset credentials




ExecuteCredentialResetRequestType - specify reset method and new password

  • 200 OK, ExecuteCredentialResetResponseType returned in the body.

Execute script





  • 200 OK, ExecuteScriptResponseType returned in the body

  • 201 Created, Location set to point to the newly created Task object. Only applicable is asynchronous=true parameter is used.

  • 240 Handled error, OperationResult is returned in the body

  • 250 Partial error, OperationResult is returned in the body

Usage samples

If you are using file as a source for the data in the REST call with curl, please, don’t forget to use '@' before the path to your file.

Sometimes the newlines are not correctly handled during the transfer. (See MID-5229.) If that occurs, please use --data-binary instead of -d.

The source files used here for the samples can be found at our git repository.

Create new Resource (OpenDJ)

curl --user administrator:5ecr3t -H "Content-Type: application/xml" -X POST http://localhost:8080/midpoint/ws/rest/resources -d @pathToMidpointGit\samples\rest\opendj-resource-sync.xml -v

Create or Update object

curl --user administrator:5ecr3t -H "Content-Type: application/xml" -X PUT http://localhost:8080/midpoint/ws/rest/resources/ef2bc95b-76e0-48e2-86d6-3d4f02d3e1a2 -d @pathToMidpointGit\samples\rest\opendj-resource-sync.xml -v

Get object

curl --user administrator:5ecr3t -X GET http://localhost:8080/midpoint/ws/rest/resources/ef2bc95b-76e0-48e2-86d6-3d4f02d3e1a2
Get Object in JSON format
curl --user administrator:5ecr3t -H "Accept: application/json" -X GET

Test Resource (OpenDJ)

curl --user administrator:5ecr3t -X POST http://localhost:8080/midpoint/ws/rest/resources/ef2bc95b-76e0-48e2-86d6-3d4f02d3e1a2/test

Import accounts from resource (Account object class from OpenDJ)

curl --user administrator:5ecr3t -H "Content-Type: application/xml" -X POST http://localhost:8080/midpoint/ws/rest/resources/ef2bc95b-76e0-48e2-86d6-3d4f02d3e1a2/import/AccountObjectClass

Find owner of shadow

curl --user administrator:5ecr3t -X GET http://localhost:8080/midpoint/ws/rest/shadows/d0133de0-0d7b-4a36-9d9d-98640216804a/owner

(Note: d0133de0-0d7b-4a36-9d9d-98640216804a is expected to be the OID of a shadow. If you would like to really execute this command, replace it by a concrete OID from your repository.)

Modify object (assign account)

Modifies the user "administrator":

curl --user administrator:5ecr3t -H "Content-Type: application/xml" -X PATCH http://localhost:8080/midpoint/ws/rest/users/00000000-0000-0000-0000-000000000002 -d @pathToMidpointGit\samples\rest\modification-assign-account.xml


Search all accounts:

curl --user administrator:5ecr3t -H "Content-Type: application/xml" -X POST http://localhost:8080/midpoint/ws/rest/shadows/search -d @pathToMidpointGit\samples\rest\query-all-accounts.xml

Search all users:

curl --user administrator:5ecr3t -H "Content-Type: application/xml" -X POST http://localhost:8080/midpoint/ws/rest/users/search -d @pathToMidpointGit\samples\rest\query-all-users.xml

Notify change

curl --user administrator:5ecr3t -H "Content-Type: application/xml" -X POST http://localhost:8080/midpoint/ws/rest/notifyChange -d @pathToMidpointGit\samples\rest\notify-change-modify-password.xml -v


Version Date Description Change Author


December 2015

Declared as stable version

Radovan Semancik


untracked improvements

Katarina Valalikova

April 2013

Initial version

Katarina Valalikova

See Also

Was this page helpful?
Thanks for your feedback