Skip to end of metadata
Go to start of metadata

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

This feature is available in midPoint version 3.0 and later.



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:

VerbMeaning and usage
GETInformation retrieval. Returns the state of the web resource. Also used to execute searches.
PUTCreate 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.
PATCHModification 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.
DELETEDelete 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 exists. 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 an 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 on 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 codeMeaning
1xxInformation. Stay tuned, operation is in progress.
2xxSuccess. Operation finished successfully.

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 an 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

For now, we support only XML (application/xml). In the near future it is planned to support JSON and YAML.

Supported object types

Currently supported object types are listed in the following table.

classREST type

Table 1. Supported types.

Supported operations

The base URL of REST API is http://localhost:8080/midpoint/ws/rest .

  • Use the base URL + path from the table below to request concrete operation. 
  • Supply the {type} with the concrete 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 concrete oid of your object.


Operation nameOperation typePathDataResponse
Create new objectPOST


Object to create in the XML form201 Created, Location set to point to the newly created object
Create or update objectPUT


Object to create in the XML form201 Created, Location set to point to the newly created object
Get objectGET/{type}/{oid}-

200 OK, current object in the response body

Modify object  PATCH, POST/{type}/{oid}Modifications in XML format204 No Content
Delete objectDELETE/{type}/{oid}-204 No Content

Test (configured) Resource

POST/resources/{oid}/test-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



Query in XML format200 OK, list of found objects in the body
Suspend tasksPOST/tasks/{oid}/suspend-204 No Content
Resume tasksPOST/tasks/{oid}/resume-202 Accepted
Schedule task nowPOST/tasks/{oid}/run-202 Accepted
Notify changePOST/notifyChangeResource object shadow change description200 OK


Sample usage

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


Create new Resource (OpenDJ)

curl.exe --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.exe --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.exe --user administrator:5ecr3t -X GET http://localhost:8080/midpoint/ws/rest/resources/ef2bc95b-76e0-48e2-86d6-3d4f02d3e1a2

Test Resource (OpenDJ)

curl.exe --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.exe --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.exe --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.exe --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.exe --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.exe --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.exe --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





Change Author

3.3December 2015Declared as stable versionRadovan Semancik
 2013-2015untracked improvements

Katarina Valalikova


April 2013

Initial version

Katarina Valalikova


None. Swagger definition is planned in the future.

See Also

  • No labels