Ataccama ONE Agentic ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
latest (17.1.0) 17.0.0 16.3.x 16.2.0 16.1.0 16.0.0 15.4.0 15.3.0 15.2.0 15.1.0 14.5.x 13.9.x 13.8.x 13.7.x 13.6.x 13.5.0 13.4.x 13.3.x 13.2.x
User Community Service Desk Downloads

REST API

The REST API provides the ability to browse data, statuses, and parameters maintained by MDM via REST interfaces. The API supports REST Maturity Level 2.

By default, the REST API uses the default server port (8051) set in MDM Server Application Properties.

The path to REST API is /api/rest and it cannot be configured. The REST API only uses basic HTTP authentication. However, you can configure a more secure authentication method, see API Endpoint Required Role Configuration.

The following sections describe the uses of the REST API.

OpenAPI Swagger

The Swagger UI allows you to see a list of available REST API endpoints and operations in a browser-based HTML interface. The Swagger UI includes descriptions for all endpoints, parameters, and schemas.

Request
http://localhost:8051/swagger-ui.html
A list of available REST API endpoints and operations in Swagger

The OpenAPI specification is available at http://localhost:8051/v3/api-docs.

The Swagger is using the springdoc-openapi library (see Springdoc openAPI library) that can be configured using spring properties (see Springdoc openAPI properties).

Authenticating in Swagger UI

To authenticate in the Swagger UI, select Authorize in the upper-right portion of the page and enter your credentials. Alternatively, you can provide credentials directly in the URL: http://username:password@localhost:8051/swagger-ui.html.

Listing REST endpoints

A response contains a directory of exposed services and interfaces and additional information, including the RW mode.

Request
http://localhost:8051/api/rest/
Response 
{
  "name" : "REST API",
  "version" : "1.0",
  "rwmode" : "RW",
  "uris" : {
    "tasks" : "http://localhost:8051/api/rest/tasks",
    "eventHandlers" : "http://localhost:8051/api/rest/event-handlers",
    "instance" : "http://localhost:8051/api/rest/instance",
    "master" : "http://localhost:8051/api/rest/master",
    "persistence" : "http://localhost:8051/api/rest/persistence",
    "purge" : "http://localhost:8051/api/rest/purge",
    "parameters" : "http://localhost:8051/api/rest/parameters",
    "operationPlan" : "http://localhost:8051/api/rest/operation-plan",
    "sourceSystems" : "http://localhost:8051/api/rest/source-systems",
    "statistics" : {
      "instance" : "http://localhost:8051/api/rest/statistics/instance",
      "master" : "http://localhost:8051/api/rest/statistics/master"
    },
    "interfaces" : {
      "services" : "http://localhost:8051/api/rest/interfaces/services",
      "exports" : "http://localhost:8051/api/rest/interfaces/batch/exports",
      "loads" : "http://localhost:8051/api/rest/interfaces/batch/loads",
      "consumers" : "http://localhost:8051/api/rest/interfaces/streaming/consumers"
    }
  }
}

The rwmode field indicates the read/write mode of the engine. Possible values are RW (read-write) and RO (read-only).

Response status codes

The MDM REST API uses standard HTTP status codes for error and status reporting.

These codes are categorized as follows:

Category Description

2xx

Success

3xx

Redirection: this usually indicates a configuration error related to authentication, for example, the OAuth flow used.

4xx

Indicates a client error, an invalid request.

5xx

Indicates a server error.

Common error codes

The following is a more detailed list of error codes that the REST API can return.

Error code Description

400 Bad Request

The request is invalid. For example, there are required parameters missing, an error in JSON formatting, or some other error, as explained in the response.

401 Unauthorized

The client needs to authenticate to access the resource.

403 Forbidden

The client does not have permission to access the resource or perform the action in the request.

404 Not Found

An incorrect URL. This is usually an incorrect name of the entity, master view, or column.

500

A server error, for example, a configuration problem or failure during a write operation.

Error responses include a JSON body with the following structure:

Error response body
{
  "message": "Human-readable error description",
  "exception": "fully.qualified.ExceptionClassName"
}

The message field contains a description of what went wrong. The exception field contains the fully-qualified Java class name of the exception that caused the error.

Read records

A GET request is used to access instance and master layer information, entity information, records or a single record.

Instance layer

Endpoint Description

/instance

Returns a list of entities on the instance layer.

/instance/{entity}

Returns all the records of the selected instance entity.

/instance/{entity}/metadata

Returns the metadata of the selected instance entity: columns, relationships, and ways to access a particular record.

/instance/{entity}/{id}

Returns an instance record by its id.

/instance/{entity}/{origin}/{sourceId}

Returns an instance record by its origin and sourceId.

Master views

Endpoint Description

/master

Returns a list of master views.

/master/{view}

Returns a list of entities on the selected master view.

/master/{view}/{entity}

Returns all the records of the selected master view.

/master/{view}/{entity}/metadata

Returns the metadata of the selected master entity: columns and ways to access a particular record.

/master/{view}/{entity}/{id}

Returns a master record by its id.

/master/{view}/{entity}/{origin}/{sourceID}

Returns a master record by the origin and sourceId of an instance record.
If {origin} contains a # and is used in the URI, it must be escaped with %23.

Parameters

Results and their presentation can be customized with the following parameters:

Parameter Description

columns

Comma-separated list of columns that should be returned (by default all columns are returned).

offset

Used for paging. Offsets the first returned record, starts at 0.

page

Used for paging. Alternative to offset - returns nth page, that is, offset=page*count, starts at 0.

count

When used alone or with offset, limits the number of records returned. When used with page, defines the page size.

sort

Name of column to sort records by, optionally suffixed with :ASC or :DESC (default ordering is ASC)

<column_name>=<value>

Filters by the exact value of the column with wildcard support. Multiple values of one column are supported: separate them by a comma. System columns are also supported.

preload=<relationship1>,<relationship2>

Lists related records according to the provided relationships.

For each loaded relationship, you can apply filters such as LIKE (only for string columns), MATCH NON EMPTY, IS EMPTY, as well as logical operators like AND and OR.
Requests with parameters
GET /instance/{entity}?offset=2&count=5
GET /instance/{entity}?columns=src_first_name,src_sin&src_first_name=Joh*&sort=std_birth_date:DESC

GET /master/{view}/{entity}?offset=2&count=5
GET /master/{view}/{entity}?columns=cmo_first_name,cmo_sin&cmo_first_name=Joh*&sort=cmo_birthdate:DESC
GET /master/{view}/{entity}?eng_active=true
GET /instance/{entity}?preload=contacts,addresses
// advanced preload examples
GET /master/masters/party?preload=addresses(cmo_street=*Logan*,cmo_city=*nto,cmo_state=Ont*,cmo_zip=*)
GET /master/masters/party?preload=addresses(cmo_city=is empty,eng_creation_tid=74005)
GET /master/masters/party/1020?preload=addresses.instances,contacts
GET /master/masters/party/1020?preload=addresses(cmo_type=Residential,cmo_state=US)

Sample GET requests and responses

Request on the instance layer 
GET /instance/party/1007
Response 
{
    "type": "party",
    "metadata":
    {
        "id": 1007,
        "origin": "crm#customer#party",
        "sourceSystem": "crm",
        "active": true,
        "sourceTimestamp": "2015-07-23T14:14:04Z",
        "creationDate": "2017-09-08T15:39:59Z",
        "lastUpdateDate": "2017-09-08T15:40:03Z",
        "lastSourceUpdateDate": "2017-09-08T15:40:03Z",
        "activationDate": "2017-09-08T15:39:59Z",
        "creationTid": 1002,
        "lastUpdateTid": 2814,
        "lastSourceUpdateTid": 2814,
        "activationTid": 1002
    },
    "attributes":
    {
        "source_id": "1001",
        "master_id": 1238,
        "propose_id": 1273,
        "src_first_name": "DR. JOHN",
        ...
    },
    ...
}
Request on a master view 
GET /master/masters/party/1235
Response 
{
    "type": "party",
    "metadata": {
        "id": 1235,
        "active": true,
        "creationDate": "2017-09-08T15:39:59Z",
        "lastUpdateDate": "2017-09-08T15:39:59Z",
        "activationDate": "2017-09-08T15:39:59Z",
        "creationTid": 1002,
        "lastUpdateTid": 1002,
        "activationTid": 1002
    },
    "attributes": {
        "cmo_type": "P",
        "cmo_first_name": "John",
       ...
    }
}

Identify

The 'Identify' service answers the question, "is this record similar to any record stored in the hub?". Input is in the form of the instance entity, while similarity is defined by the matching rules of this entity. Output is either matching information and master record or nothing.

The service accepts POST requests at endpoint /master/{view}/{entity}/identify with the following structure:

Identify request 
POST /master/masters/party/identify
{
    "sourceSystem" : "life",
    "record" : {
        "attributes" : {
            "src_first_name" : "Anto",
            "src_last_name" : "Lese",
            "src_sin" : "387958572"
        },
        "relationships" : [{
            "contacts" : [{
                "attributes": {
                    "src_type" : "PHONE",
                    "src_value" : "416-206-1234"
                }
            },
            {
                "attributes": {
                    "src_type" : "EMAIL",
                    "src_value" : "alese@aol.com"
                }
            }]
        }]
    }
}

As an input, the service gets:

  • one record of the instance entity - attributes of origin SOURCE

  • (optional) records of related entities - attributes of origin SOURCE

The service cleanses input data and tries to match the record to records in the hub using matching rules. If the input record is matched to a master group, a master record is returned. For example, the response if the record is matched is:

Identify response 
{
    "matchMetadata" : {
        "matchRelatedId" : 1007,
        "matchQuality" : 0.0,
        "matchRuleName" : "name+sin"
    },
    "record" : {
        "type" : "party",
        "metadata" : {
            "id" : 1030
            // more metadata
        },
        "attributes" : {
            "cmo_name" : "John",
            // more attributes
        }
    }
}

If matching has proposals enabled, proposals are returned as well. It is possible to have only proposals in response (record matches only using proposal rules).

Identify response 
{
    "matchMetadata" : { /* ... */ },
    "record" : { /* ... */ },
    "proposals" : [ {
        "matchMetadata" : {
            "matchRelatedId" : 1007,
            "matchQuality" : 0.0,
            "matchRuleName" : "name+sin"
        },
        "record" : {
            "type" : "party",
            "metadata" : {
                "id" : 1030
                // more metadata
            },
            "attributes" : {
                "cmo_name" : "John",
                // more attributes
            }
        }
    },
    // more proposals

    ]
}

If there are too many proposals (more than the runtime parameter nme.services.range.maxCount, default 100), proposals are returned in a short format:

Identify response 
{
    "matchMetadata" : { /* filled */ },
    "record" : { /* */ },
    "proposals" : [ {
        "masterId" : 1012,
        "matchRelatedId" : 1007,
        "matchQuality" : 0.0,
        "matchRuleName" : "name+sin"
    }
    // more proposals
    ]
}

This services allows you to search for records by attributes and values using a POST request. For example, the following request searches for records with src_name values John or Paul and a std_Age value 42:

Search request 
POST /instance/party/search
{
"src_name" : ["John","Paul"],
"std_age" : 42
}

The request supports the following parameters:

Parameter Description

offset

Used for paging. Offsets the first returned record, starts at 0.

count

When used alone or with offset, limits the number of records returned.

You can also search for records on the master layer using a POST request.

Search request 
POST /master/{view}/{entity}/search
{
  "cmo_first_name" : ["John","Paul"],
  "cmo_age" : 42
}

The request supports the same offset and count query parameters as the instance search.

Parameter Description

offset

Used for paging. Offsets the first returned record, starts at 0.

count

When used alone or with offset, limits the number of records returned.

Read historical records

It is possible to get historical values of a record with a GET request.

History endpoints are only available when the history plugin is used. See History Plugin for configuration details.
Endpoint Description

/history

Returns the list of all historized entities.

/instance/{entity}/history/metadata

Returns the list of columns stored in the historized instance entity as configured in nme-history.xml. See History Plugin for more information.

/instance/{entity}/{id}/history

Returns historical instance records by the record id.

/instance/{entity}/{origin}/{source_id}/history

Returns historical instance records by origin and the record id.

/master/{view}/{entity}/{id}/history

Returns historical master records by the record id.

/master/{view}/{entity}/history/metadata

Returns the list of columns stored in the historized master entity as configured in nme-history.xml. See History Plugin for more information.

Set the timeframe

It is possible to limit the number of results by specifying the from, to, or at parameters in the request. The from and to parameters can be combined or used separately.

History request 
/master/masters/party/1734/history?from=2017-08-16T11:15:55Z&to=2017-08-25T11:15:55Z
History response 
[ {
  "type" : "partymasters",
  "metadata" : {
    "id" : 1734,
    "validFrom" : "2017-08-21T14:47:02Z",
    "validTo" : "2017-08-24T14:48:11Z",
    "active" : true
  },
  "attributes" : {
    "cmo_type" : "P",
    "cmo_first_name" : "John",
    "cmo_last_name" : "Smith",
    "cmo_gender" : "M",
    "cmo_birth_date" : "1978-11-16T00:00:00Z",
    "cmo_sin" : "95242433",
    "dq_indicator" : 100000,
    "dq_indicator_name" : "medium",
    "group_size" : 2,
    "published_by" : "admin"
  }
}, {
  "type" : "partymasters",
  "metadata" : {
    "id" : 1734,
    "validFrom" : "2017-08-16T14:37:15Z",
    "validTo" : "2017-08-21T14:47:02Z",
    "active" : true
  },
  "attributes" : {
    "cmo_type" : "P",
    "cmo_first_name" : "J",
    "cmo_last_name" : "Smith",
    "cmo_birth_date" : "1978-11-16T00:00:00Z",
    "cmo_sin" : "95242433",
    "dq_indicator" : 111003,
    "dq_indicator_name" : "medium",
    "group_size" : 1,
    "published_by" : "multiload"
  }
} ]

Modify records

Mapping of HTTP methods to change type is as usual in REST:

  • Insert via POST

  • Update via PUT

  • Deactivation via DELETE

However MDM can automatically adjust between create and update depending on whether the record is present in the MDM repository, that is, an attempt to update (PUT) a non-existing record is automatically changed to an insert operation (POST), and vice versa.

Record identification in requests

Records are identified by their id or a combination of origin and source_id (for instance records only). This identification can be sent in the URI or in the request body.

Record ID sent in the request URI 
PUT /instance/{entity}/{id}
POST /instance/{entity}/{origin}/{sourceId}
PUT/POST /api/rest/master/{entity}/{id}
If {origin} contains a hashtag symbol (#) and is used in the URI, it must be escaped with %23.
Record ID sent in the request body 
POST /instance/{entity}
{
    "origin" : "crm#customer#party",
    "source_id" : "cdr48"
}

All combinations of POST/PUT/DELETE and identification are supported to provide maximum integration flexibility. The only forbidden variant is sending id when creating a new record (MDM generates its own ids).

Source timestamp formatting

In POST and PUT requests, the value of source_timestamp must comply with the ISO 8601 standard for date and time formats. Z is treated as local (server) time zone, not as UTC.

Some of supported formats are:

  • yyyy-MM-dd’T’HH:mm:ss’Z'

  • yyyy-MM-dd’T’HH:mm:ss.SSS’Z'

  • yyyy-MM-dd’T’HH:mm:ss

  • yyyy-MM-dd’T’HH:mm:ss.SSS

  • yyyy-MM-dd’T’HH:mm:ssZ

Timestamp format examples
"2025-09-05T10:00:01Z"
"2025-09-05T10:00:02.345Z"
"2025-09-05T10:00:03"
"2025-09-05T10:00:05.678"
"2025-09-05T10:00:07+08:00"

Activate and deactivate records request example

Both instance and master records can be activated and deactivated repeatedly.

If the request is successful, the response contains a confirmation of the update. Depending on the action, the recordChange can be:

  • INSERT: A new record was created.

  • UPDATE: The record was updated (for example, the activity status was changed).

  • DELETE: The record was deleted.

  • NONE: No change was applied (for example, the record activity status remains the same).

  • PURGE: The record was purged.

If you try to remove the activity override on a record without an activity flag (for example, if you make the remove override request on the same record twice in a row), the request returns a 500 Internal Server Error HTTP status code. If the view, entity, or record do not exist (or their IDs are invalid), a 400 Bad Request HTTP status code is returned instead.

500 Internal Server Error HTTP status code 
{
  "message": "Server error",
  "exception": "Execution of rest.master.removeActivity service failed: There is no override value for eng_active on record party(159111)"
}

Instance layer

Activate record PUT request 
PUT /api/rest/instance/{entity}/{id}/activate
Deactivate record PUT request 
PUT /api/rest/instance/{entity}/{id}/deactivate
Remove activity override PUT request 
PUT /api/rest/instance/{entity}/{id}/remove-activity
Response 
{
  "id": 74006,
  "origin": "crm#customer#party",
  "source_id": "100",
  "recordChange": "NONE"
}

Master layer

Activate record PUT request 
PUT /api/rest/master/{viewName}/{entity}/{id}/activate
Deactivate record PUT request 
PUT /api/rest/master/{viewName}/{entity}/{id}/deactivate
Remove activity override PUT request 
PUT /api/rest/master/{viewName}/{entity}/{id}/remove-activity
Response 
{
  "id": 159111,
  "origin": null,
  "source_id": null,
  "recordChange": "UPDATE"
}

POST request example

Instance layer

Insert via a POST request 
POST /instance/party
{
    "origin" : "crm#customer#party",
    "source_id" : "cdr48",
    "source_timestamp" : "2015-07-23T14:14:04Z",
    "attributes" : {
        "src_first_name" : "Johny",
        "src_sin" : "547-954-624"
    }
}
Response 
{
    "result": "ok",
    "records": {
        "id": 4051,
        "origin": "crm#customer#party",
        "source_id": "cdr48-ase",
        "recordChange": "INSERT"
        "attributes": {
            "master_id": 7560
        }
    }
}

The master_id attribute is included in the response from instance write endpoints. This functionality is configured in the application.properties file (see MDM Features).

Insert with relationships via a POST request 
{
    "origin" : "PAS#policyrole#party",
    "source_id" : "6776",
    "source_timestamp" : "2019-03-27T00:00:00Z",
    "attributes" : {
        "src_name_first" : "LINDA",
        "src_name_last" : "CORRIE",
        "src_name_middle" : "",
        "src_gender" : "Female",
        "src_date_of_birth" : ""
    },
    "relationships": {
        "contact": [{
            "source_id":"670",
            "origin":"PAS#policyrole#contact",
            "attributes": {
                "party_source_id" : "671",
                "src_value": "5354856",
                "src_type" : "Home Phone"
            }
        }
        ]
    }
}
When inserting a record with relationships via a POST request, you will need to modify Parent Role / Child Role in the MDM Logical Model according to what is defined in your request. Alternatively, if you have no Parent or Child Role defined in the model, use rev_party_has_contact in place of contact in the request.

Master layer

Insert via a POST request 
POST http://localhost:8051/api/rest/master/masters/party
{
   "attributes": {
      "cmo_first_name": "rest3",
      "cmo_sin": "12345"
   },
   "relationships": {
       "addresses":  [{
           "attributes":{
               "cmo_street": "ab1",
               "cmo_city": "cd1"
           }
       },
       {
           "attributes":{
               "cmo_street": "ab2",
               "cmo_city": "cd2"
           }
       }]
   }
}
Response 
{
   "result": "ok",
   "records": {
       "id": 302003,
       "recordChange": "INSERT",
       "relationships": {
           "addresses": [
               {
                   "id": 302004,
                   "recordChange": "INSERT"
               },
               {
                   "id": 302005,
                   "recordChange": "INSERT"
               }
           ]
       }
   }
}

PUT request example

Instance layer

Update via a PUT request 
PUT /instance/party/crm%23customer%23party/1001
{
    "source_timestamp" : "2015-07-23T14:14:04Z",
    "attributes": {
        "src_first_name": "Dr. John",
        "src_sin": "764-785-685"
    },
    "relationships": {
        "id_documents": [{
            "source_id":"pass-94515",
            "origin":"crm#customer#id_document",
            "attributes": {
                "src_type" : "passport",
                "src_value" : "489465498",
                "party_source_id" : "1001"
            }
        }]
    }
}

The central entity was updated, related entities were ignored since the data in the request was the same as before.

Response 
{
    "result": "ok",
    "records": {
        "entity": {
            "action": "UPDATED",
            "id": 17603215,
            "origin": "crm#customer#party",
            "source_id": "12121212"
            "attributes": {
                "master_id": 7560
            }
        },
        "relationships": {
            "id_documents": {
                "entity": {
                    "action": "NONE",
                    "id": 2207,
                    "origin": "crm#customer#id_document",
                    "source_id": "100_id_card_1"
                }
            }
        }
    }
}

The master_id attribute is included in the response from instance write endpoints. This functionality is configured in the application.properties file (see MDM Features).

Master layer

Update via a PUT request 
PUT http://localhost:8051/api/rest/master/masters/party/302003
{

   "attributes": {
      "cmo_first_name": "rest81",
      "cmo_sin": "12"
   }
}
Response 
{
   "result": "ok",
   "records": {
       "id": 302003,
       "recordChange": "UPDATE"
   }
}

DELETE request example

Instance layer

Record deactivation via a DELETE request 
DELETE http://localhost:8051/api/rest/instance/party/17603215
<empty-body>
Response 
{
    "result": "ok",
    "records": {
        "entity": {
            "id": 20003264,
            "origin": "crm#customer#id_document",
            "source_id": "100_id_card_1666"
            "action": "DEACTIVATED",
        }
    }
}

Master layer

It is only possible to delete authored master records via the API. The DELETE request for these records causes an actual delete rather than a record deactivation (logical delete). For more information see Deletion strategy.
Record deletion via a DELETE request 
DELETE http://localhost:8051/api/rest/master/masters/party/302003
<empty-body>
Response 
{
   "result": "ok",
   "records": {
       "id": 302003,
       "recordChange": "DELETE"
   }
}

Override interfaces

Instance records

Requests on the instance layer use the following parameters for record identification.

Parameter Description

{entity}

Instance table name as defined in the model.

{id}

ID of the record.

You can use attributeName either in the URI or in the request body to specify one or more attributes involved in the request.

List record overrides

Use the following request to get the original value of the attribute before an override has been set. The request body is empty.

Request 
GET /instance/{entity}/{id}/override/{attributeName}
Response 
{
  "recordType": "instance",
  "entityType": "party",
  "recordId": 1982,
  "overrides": [
    {
      "attributeName": "src_first_name",
      "value": "John"
    }
  ]
}

Use the following request to get the list of all attributes with overrides and their values before the override has been set. The request body is empty.

Request 
GET /instance/{entity}/{id}/override
Response 
{
  "recordType": "instance",
  "entityType": "party",
  "recordId": 1982,
  "overrides": [
    {
      "attributeName": "src_first_name",
      "value": "John"
    },
    {
      "attributeName": "src_last_name",
      "value": "Smith"
    }
  ]
}
Set overrides

Use the following request to set an override on a particular attribute. Specify the attributeName and value in the request body. The response is empty.

Request 
PUT /instance/{entity}/{id}/override/{attributeName}
{
  "overrides": [
    {
      "attributeName": "src_first_name",
      "value": "John"
    }
  ]
}

Use the following request to set overrides on several attributes. Specify both the attributeName and value in the request body. The response is empty.

Request 
PUT /instance/{entity}/{id}/override
{
  "overrides": [
    {
      "attributeName": "src_first_name",
      "value": "John"
    },
    {
      "attributeName": "src_last_name",
      "value": "Smith"
    }
  ]
}
Delete overrides

Use the following request to delete an override on a particular attribute. Both the request and response body are empty.

Request 
DELETE /instance/{entity}/{id}/override/{attributeName}

Use the following request to delete all overrides currently set on a record. The response body is empty. You can optionally provide a request body to delete only specific overrides:

Selective delete request 
DELETE /instance/{entity}/{id}/override
{
  "attributes": ["src_first_name", "src_last_name"]
}
Request 
DELETE /instance/{entity}/{id}/override

Master records

Requests on the master layer use the following parameters for record identification.

Parameter Description

{view}

Name of the master layer/view

{entity}

Instance table name as defined in the model.

{id}

ID of the record.

You can use attributeName either in the URI or in the request body to specify one or more attributes involved in the request.

List record overrides

Use the following request to get the original value of the attribute before an override has been set. The request body is empty.

Request 
GET /master/{viewName}/{entity}/{id}/override/{attributeName}
Response 
{
  "recordType": "master",
  "entityType": "party",
  "recordId": 1982,
  "overrides": [
    {
      "attributeName": "cmo_first_name",
      "value": "John"
    }
  ],
  "viewName": "masters",
}

Use the following request to get the list of all attributes with overrides and their values before the override has been set. The request body is empty.

Request 
GET /master/{viewName}/{entity}/{id}/override
Response 
{
  "recordType": "master",
  "entityType": "party",
  "recordId": 1982,
  "overrides": [
    {
      "attributeName": "cmo_first_name",
      "value": "John"
    },
    {
      "attributeName": "cmo_last_name",
      "value": "Smith"
    }
  ],
  "viewName": "masters",
}
Set overrides

Use the following request to set overrides on one or several attributes. Specify both the attributeName and value in the request body. The response is empty.

Request 
PUT /master/{viewName}/{entity}/{id}/override
{
  "overrides": [
    {
      "attributeName": "cmo_first_name",
      "value": "John"
    },
    {
      "attributeName": "cmo_last_name",
      "value": "Smith"
    }
  ]
}
Delete overrides

Use the following request to delete an override on a particular attribute. Both the request and response body are empty.

Request 
DELETE /master/{viewName}/{entity}/{id}/override/{attributeName}

Use the following request to delete all overrides currently set on a record. The response body is empty. You can optionally provide a request body to delete only specific overrides:

Selective delete request 
DELETE /master/{viewName}/{entity}/{id}/override
{
  "attributes": ["cmo_first_name", "cmo_last_name"]
}
Request 
DELETE /master/{viewName}/{entity}/{id}/override

Task management

Tasks have the following lifecycle statuses:

Status Description

NEW

Task has been created but not yet started.

IN_PROGRESS

Task is being worked on.

RESOLVING

Task resolution is being processed by the engine.

RESOLUTION_FAILED

Engine failed to apply the task resolution. Task can be retried.

RESOLVED

Task has been successfully resolved.

DISCARDED

Task was discarded without resolution.

Tasks can have the following types:

Type Description

RECORD_CHANGE

Created when a record change requires manual review.

MANUAL_MATCH

Created for manual matching decisions.

MATCHING_PROPOSAL

Created when the engine proposes a match that needs review.

CREATE

Created for new record creation workflows.

GENERIC

General-purpose task type.

Single task operations

Assign task

Use the following request to assign a task to a group of team members or one team member:

Request
POST /api/rest/v2/tasks/{id}/assign

The request supports the following parameters:

Parameter Required Description

id

Yes

Task identifier.

user

No

Name of a new user assignee.

group

No

Name of a new group assignee.
Response
{
  "id": 17,
  "status": "NEW",
  "name": "Resolve DQ issues",
  "userAssignee": "jane.smith",
  "groupAssignee": "MDM_viewer",
  "workflowName": "consolidation",
  "workflowStep": "draft",
  "entityId": "contact.master.masters",
  "created": "2022-12-09T17:56:23.359Z",
  "createdBy": "jane.smith",
  "lastEdited": "2023-08-03T06:32:51.538Z",
  "lastEditedBy": "admin",
  "type": "RECORD_CHANGE",
  "severity": "LOW",
  "automationDefinitionId": null,
  "description": "Click on record edit to fix DQ issues.",
  "records": [
    {
      "id": 76628,
      "entityId": "contact.master.masters"
    },
    {
      "id": 76684,
      "entityId": "contact.master.masters"
    }
  ]
}

Get task detail

Use the following request to get task detail information (without comments and history):

Request
GET /api/rest/v2/tasks/{id}

The request uses the following parameter:

Parameter Required Description

id

Yes

Task identifier.
Response
{
  "id": 19,
  "status": "IN_PROGRESS",
  "name": "Missing PIDs",
  "userAssignee": "rachel.adams",
  "groupAssignee": "MDM_user",
  "workflowName": "consolidation",
  "workflowStep": "draft",
  "entityId": "party.master.masters",
  "created": "2022-12-09T17:58:33.517Z",
  "createdBy": "jane.smith",
  "lastEdited": "2023-08-02T19:28:46.761Z",
  "lastEditedBy": "admin",
  "type": "RECORD_CHANGE",
  "severity": "LOW",
  "automationDefinitionId": null,
  "description": "Click on record edit to start fixing DQ issues. You can also perform any other actions: add missing related data, activate or deactivate record, or split an instance from the master record.",
  "records": [
    {
      "id": 76083,
      "entityId": "party.master.masters"
    },
    {
      "id": 76080,
      "entityId": "party.master.masters"
    },
    {
      "id": 76078,
      "entityId": "party.master.masters"
    }
  ]
}

Get task history

Use the following request to get history for a specific task:

Request
GET /api/rest/v2/tasks/{id}/history

The request uses the following parameter:

Parameter Required Description

id

Yes

Task identifier.
Response
{
  "history": [
    {
      "userName": "jane.smith",
      "timeStep": "2022-12-09T16:55:45.897Z",
      "action": "CREATE",
      "step": null,
      "reassign": null,
      "comment": null,
      "migrationResult": null,
      "automatedTaskConfigId": null
    },
    {
      "userName": "john.taylor",
      "timeStep": "2022-12-09T17:08:29.717Z",
      "action": "CREATE_DRAFT",
      "step": null,
      "reassign": null,
      "comment": "ID: 8",
      "migrationResult": null,
      "automatedTaskConfigId": null
    }
  ]
}

The action field in the task history can have the following values:

Action Description

CREATE

Task was created.

MOVE

Task was moved to a new workflow step.

RESOLVE

Task was resolved.

DISCARD

Task was discarded.

COMMENT

A comment was added.

REASSIGN

Task was reassigned to a different user or group.

RESOLVE_FAIL

Task resolution failed.

LOAD

Task was loaded from an external source.

POST_ACTION

Post-resolution action was executed.

UPDATE

Task details were updated.

CREATE_DRAFT

A draft was created for the task.

PUBLISH_DRAFT

A draft was published.

PUBLISH_DRAFT_FAILED

Draft publication failed.

DISCARD_DRAFT

A draft was discarded.

MIGRATION

Task was migrated from a previous version.

CREATED_BY_AUTOMATED_TASK_CONFIG

Task was created using automated task configuration.

AUTOMATED_TASK_CONFIG_DELETED

The automated task configuration that created this task was deleted.

Get task comments

Use the following request to get comments for a specific task:

Request
GET /api/rest/v2/tasks/{id}/comments

The request uses the following parameter:

Parameter Required Description

id

Yes

Task identifier.
Response 
{
  "comments": [
    {
      "userName": "jane.smith",
      "timeStep": "2022-12-09T16:52:06.904Z",
      "comment": "I think we need to get back to the product team to see how we can improve their data before they reach us"
    }
  ]
}

Add task comment

Use the following request to add comments for a specific task:

Request
POST /api/rest/v2/tasks/{id}/comments

The request uses the following parameter:

Parameter Required Description

id

Yes

Task identifier.
Sample request 
POST /api/rest/v2/tasks/{id}/comments

Could you take a look at it, John?
Response 
{
  "comments": [
    {
      "userName": "jane.smith",
      "timeStep": "2023-08-03T06:15:48.127Z",
      "comment": "Could you take a look at it, John?"
    }
  ]
}

Delete task

Use the following request to delete a specific task. The response is empty.

Request
DELETE /api/rest/v2/tasks/{id}

The request uses the following parameter:

Parameter Required Description

id

Yes

Task identifier.

Bulk task operations

Create multiple tasks

Use the following request to create multiple tasks:

Request
POST /api/rest/v2/tasks
Sample request 
POST /api/rest/v2/tasks
[
  {
    "type": "RECORD_CHANGE",
    "name": "Missing PIDs",
    "description": "Click on record edit to start fixing DQ issues.",
    "records": [
      {
        "id": 56787,
        "entityId": "party.master.masters"
      }
    ],
    "workflowName": "consolidation",
    "workflowStep": "draft",
    "userAssignee": "admin",
    "groupAssignee": "MDM_user",
    "severity": "LOW",
    "linkAddress": "https://example.com/record/56787"
  }
]
Response 
{
  "createdTaskIds": [
    36
  ]
}
The POST /v2/tasks endpoint returns HTTP 201 Created on success, not 200 OK.

You can add a clickable link field to the task description section in the task detail in MDM Web App. To enable the functionality, configure the ataccama.one.mdm.task.link.enabled application property (see Task configuration).

Update multiple tasks

Use the following request to update multiple tasks:

Request
PATCH /api/rest/v2/tasks
Sample request 
PATCH /api/rest/v2/tasks
[
  {
    "taskId": 16,
    "userAssignee": "jane.smith",
    "groupAssignee": "MDM_viewer",
    "severity": "LOW"
  },
  {
    "taskId": 15,
    "name": "Matching issue (address)"
  }
]
Response 
{
  "tasks": [
    {
      "id": 16,
      "status": "IN_PROGRESS",
      "name": "Matching issue",
      "userAssignee": "jane.smith",
      "groupAssignee": "MDM_viewer",
      "workflowName": "consolidation",
      "workflowStep": "draft",
      "entityId": "party_proposal_k.match_proposal",
      "created": "2022-12-09T17:55:45.897Z",
      "createdBy": "jane.smith",
      "lastEdited": "2023-08-04T09:56:32.002Z",
      "lastEditedBy": "admin",
      "type": "MATCHING_PROPOSAL",
      "severity": "LOW",
      "automationDefinitionId": null,
      "description": "Fix this matching issue",
      "records": [
        {
          "id": 76108,
          "entityId": "party_proposal_k.match_proposal"
        },
        {
          "id": 76107,
          "entityId": "party_proposal_k.match_proposal"
        }
      ]
    },
    {
      "id": 15,
      "status": "IN_PROGRESS",
      "name": "Matching issue (address)",
      "userAssignee": "jane.smith",
      "groupAssignee": "MDM_viewer",
      "workflowName": "consolidation",
      "workflowStep": "draft",
      "entityId": "party_proposal_k.match_proposal",
      "created": "2022-12-09T17:53:34.651Z",
      "createdBy": "jane.smith",
      "lastEdited": "2023-08-04T09:56:32.002Z",
      "lastEditedBy": "admin",
      "type": "MATCHING_PROPOSAL",
      "severity": "LOW",
      "automationDefinitionId": null,
      "description": "Different addresses",
      "records": [
        {
          "id": 76111,
          "entityId": "party_proposal_k.match_proposal"
        },
        {
          "id": 76113,
          "entityId": "party_proposal_k.match_proposal"
        }
      ]
    }
  ]
}

You can add a clickable link field to the task description section in the task detail in MDM Web App. To enable the functionality, configure the ataccama.one.mdm.task.link.enabled application property (see Task configuration).

Get tasks

Use the following request to get tasks detail information (without comments and history):

Request
GET /api/rest/v2/tasks

The request supports the following parameters:

Parameter Required Description

active

Yes

Set to true to return active tasks, false to return closed tasks. Default value is true.

createdAfter

No

Filters tasks created after specified date (for example, 2022-12-09T16:27:40.359Z, 2011-12-03).

createdBefore

No

Filters tasks created before specified date (for example, 2022-12-09T16:27:40.359Z, 2011-12-03).

updatedAfter

No

Filters tasks updated after specified date (for example, 2022-12-09T16:27:40.359Z, 2011-12-03).

updatedBefore

No

Filters tasks updated before specified date (for example, 2022-12-09T16:27:40.359Z, 2011-12-03).

offset

No

Used for pagination. Defines how many items are skipped before returning results.

page

No

Used for pagination. Specifies the number of the page to return. The number of records on each page is defined by count.

count

No

Specifies the number of records included in the response.
Response 
{
  "tasks": [
    {
      "id": 19,
      "status": "IN_PROGRESS",
      "name": "Missing PIDs",
      "userAssignee": "rachel.adams",
      "groupAssignee": "MDM_user",
      "workflowName": "consolidation",
      "workflowStep": "draft",
      "entityId": "party.master.masters",
      "created": "2022-12-09T17:58:33.517Z",
      "createdBy": "jane.smith",
      "lastEdited": "2023-08-02T19:28:46.761Z",
      "lastEditedBy": "admin",
      "type": "RECORD_CHANGE",
      "severity": "LOW",
      "automationDefinitionId": null,
      "description": "Click on record edit to start fixing DQ issues. You can also perform any other actions: add missing related data, activate or deactivate record, or split an instance from the master record.",
      "records": [
        {
          "id": 76083,
          "entityId": "party.master.masters"
        },
        {
          "id": 76080,
          "entityId": "party.master.masters"
        },
        {
          "id": 76078,
          "entityId": "party.master.masters"
        }
      ]
    },
    {
      "id": 20,
      "status": "NEW",
      "name": "We need to fix this NPI!",
      "userAssignee": null,
      "groupAssignee": "MDM_user",
      "workflowName": null,
      "workflowStep": null,
      "entityId": "facility.master.provider",
      "created": "2022-12-09T18:06:35.521Z",
      "createdBy": "john.taylor",
      "lastEdited": "2022-12-09T18:06:35.521Z",
      "lastEditedBy": "john.taylor",
      "type": "RECORD_CHANGE",
      "severity": "HIGH",
      "automationDefinitionId": null,
      "description": "Click on record edit to fix DQ issues.",
      "records": [
        {
          "id": 81540,
          "entityId": "facility.master.provider"
        }
      ]
    },
    {
      "id": 21,
      "status": "NEW",
      "name": "New record - Mark Dough",
      "userAssignee": null,
      "groupAssignee": "MDM_user",
      "workflowName": null,
      "workflowStep": null,
      "entityId": "party.master.masters",
      "created": "2022-12-09T18:12:08.253Z",
      "createdBy": "john.taylor",
      "lastEdited": "2022-12-09T18:12:08.253Z",
      "lastEditedBy": "john.taylor",
      "type": "CREATE",
      "severity": "LOW",
      "automationDefinitionId": null,
      "description": "Mark Dough, born 1973-09-16. I will just write down what I know",
      "records": []
    }
  ]
}

Get tasks for specific record

Use the following request to get tasks for a specific record:

Request
GET /api/rest/v2/tasks/record/{recordId}

GET /api/rest/v2/tasks/record/{recordId}?entityId={entityId}

The request supports the following path and query parameters:

Parameter Required Description

recordId

Yes

Identifier of the MDM record (instance, master, or proposal) for which tasks are fetched.

entityId

No

Identifier of the MDM entity for which tasks are fetched.
Response 
{
  "tasks": [
    {
      "id": 19,
      "status": "IN_PROGRESS",
      "name": "Missing PIDs",
      "userAssignee": "rachel.adams",
      "groupAssignee": "MDM_user",
      "workflowName": "consolidation",
      "workflowStep": "draft",
      "entityId": "party.master.masters",
      "created": "2022-12-09T17:58:33.517Z",
      "createdBy": "jane.smith",
      "lastEdited": "2023-08-02T19:28:46.761Z",
      "lastEditedBy": "admin",
      "type": "RECORD_CHANGE",
      "severity": "LOW",
      "automationDefinitionId": null,
      "description": "Click on record edit to start fixing DQ issues. You can also perform any other actions: add missing related data, activate or deactivate record, or split an instance from the master record.",
      "records": []
    },
    {
      "id": 33,
      "status": "NEW",
      "name": "Issue with PID on personal record",
      "userAssignee": "",
      "groupAssignee": "MDM_user",
      "workflowName": "consolidation",
      "workflowStep": "draft",
      "entityId": "party.master.masters",
      "created": "2023-03-20T22:27:56.395Z",
      "createdBy": "admin",
      "lastEdited": "2023-03-20T22:27:56.395Z",
      "lastEditedBy": "admin",
      "type": "RECORD_CHANGE",
      "severity": "INTERMEDIATE",
      "automationDefinitionId": 1,
      "description": "Missing or invalid PID",
      "records": []
    }
  ]
}

Task workflow

Move task to a new step

Use the following request to move a task to a new workflow step, see Default master data workflow. To learn how to discard a task, see Discard task.

Request
POST /api/rest/v2/tasks/{id}/move/{transition}

The request supports the following parameters:

Parameter Required Description

id

Yes

Task identifier.

transition

Yes

Name of the transition, defined under GUI Configuration > Workflow Configuration, see Configuring Workflows.
Response 
{
  "id": 19,
  "status": "IN_PROGRESS",
  "name": "Missing PIDs",
  "userAssignee": null,
  "groupAssignee": "MDM_user",
  "workflowName": "consolidation",
  "workflowStep": "waiting_for_publish",
  "entityId": "party.master.masters",
  "created": "2022-12-09T17:58:33.517Z",
  "createdBy": "jane.smith",
  "lastEdited": "2023-08-04T10:29:46.101Z",
  "lastEditedBy": "admin",
  "type": "RECORD_CHANGE",
  "severity": "LOW",
  "automationDefinitionId": null,
  "description": "Fix DQ issues.",
  "records": [
    {
      "id": 76083,
      "entityId": "party.master.masters"
    },
    {
      "id": 76080,
      "entityId": "party.master.masters"
    },
    {
      "id": 76078,
      "entityId": "party.master.masters"
    }
  ]
}

Discard task

Use the following request to discard a specific task (for more information about discarding tasks, see Discard task). The response is empty.

Request
POST /api/rest/v2/tasks/{id}/discard

The request uses the following parameter:

Parameter Required Description

id

Yes

Task identifier.
Sample request 
POST /api/rest/v2/tasks/{id}/discard

Task discarded comment

Lookups management

The lookups management endpoint is available only if lookup synchronization is turned on. This is controlled using the following property:

ataccama.one.mdm.lookup.storage.enabled=true

For details, see MDM Server Application Properties > Lookups management.

To access the endpoint, you need manager-level access to the MDM Web App Admin Center. See MDM Server Application Properties > MDM Admin Center permissions.

The endpoint checks the MinIO folder specified in the ataccama.one.mdm.lookup.storage.remote-prefix property (default value: ext/). The folder needs to be present in both MinIO buckets (for upload and download).

Fetch lookup files

Use the following request to fetch lookup files from MinIO.

Request
POST /manager/api/lookups/fetch

If successful, the response returns a confirmation that lookup files have been retrieved.

Response 
{
    "name": "FetchLookups",
    "scope": "CONFIGURATION",
    "status": {
        "state": "FINISHED",
        "startedAt": "2025-08-15T05:22:21.221436328Z",
        "finishedAt": "2025-08-15T05:22:21.27714669Z",
        "errorMessage": null,
        "errorTrace": null
    }
}

The request supports the following query parameters:

Parameter Description

overrideExistingFiles

Set to true to replace all files in the local storage with files from the remote storage. By default, existing files (same path and name) in the local folder are not overwritten.

Can be used together with deleteOrphanFiles.

deleteOrphanFiles

Orphan files are files present in the local folder but not in a remote storage. Set to true to remove all such files from the local storage while keeping subfolders intact.

Can be used together with overrideExistingFiles.
Requests with parameters
POST /manager/api/lookups/fetch?overrideExistingFiles=true
POST /manager/api/lookups/fetch?deleteOrphanFiles=true
POST /manager/api/lookups/fetch?overrideExistingFiles=true&deleteOrphanFiles=true

Stream consumers

Use the following request to start a stream consumer <crm_stream_name>.

Request 
POST /api/rest/interfaces/streaming/consumers/<crm_stream_name>/start

Use the following request to stop a stream consumer <crm_stream_name>.

Request 
POST /api/rest/interfaces/streaming/consumers/<crm_stream_name>/stop

Use the following request to start all stream consumers.

Request 
POST /api/rest/interfaces/streaming/consumers/start

Use the following request to stop all stream consumers.

Request 
POST /api/rest/interfaces/streaming/consumers/stop

Purge

Use the following request to initiate a housekeeping procedure. Completely purges all records with eng_existing=0 and whose deletion was already provided (that is, exported) in all configured incremental batch exports. This also deletes merge proposals of the deleted records.

To check if record deletion was provided in an incremental batch export, you can compare the record deletion_tid and the batch export TREF values in the _EXPORT_REG table. Record deletion has been already provided if deletion_tid is lower than TREF of batch exports.

Because of this, records that were deleted after executing some incremental batch export are not purged. To force purging of such records, you can provide the names of incremental batch exports that should be ignored in the request body.

Request 
POST /api/rest/purge/
{"ignored": ["incrementalBatchExport1", "incrementalBatchExport2"]}

The operation is visible in the MDM Web App Admin Center under Orchestration > MD Process Monitoring > Data Statistics (see Administration).

Persistence

Get persistence layers

Use the following request to get information about all registered persistence layers and their LTC (Long Transaction Cleanup) statistics:

Request 
GET /api/rest/persistence
Response 
{
  "persistence": [
    {
      "name": "vldb",
      "ltcStats": {
        "ltcCount": 42,
        "timeSpent": "PT10M35S",
        "transactionsCount": 1523,
        "running": false,
        "lastError": null
      }
    }
  ]
}

Index management

Use the following request to drop indices in VLDB persistences. If some indices were created/deleted manually by a user, the operation will fail.

Request 
DELETE /api/rest/persistence/indices

Use the following request to create indices in VLDB persistences. If some indices were created/deleted manually by a user, the operation will fail.

Request 
POST /api/rest/persistence/indices

Use the following request to start the LTC (transaction garbage collector) for all VLDB persistences.

Request 
POST /api/rest/persistence/triggerLtc

Use the following request to start the LTC for the VLDB persistence {name}.

Request 
POST /api/rest/persistence/{name}/triggerLtc

System parameters

Prints out the currently set runtime parameters (see Runtime Parameters).

http://localhost:9090/api/rest/parameters

Source systems

List the source systems and information about them.

/source-systems
/source-systems/{name}
List all source systems response 
{
  "sources": [
    {
      "name": "crm",
      "uri": "http://localhost:8051/api/rest/source-systems/crm"
    },
    {
      "name": "erp",
      "uri": "http://localhost:8051/api/rest/source-systems/erp"
    }
  ]
}
Source system detail response 
{
  "name": "crm",
  "origins": [
    {
      "name": "crm#customer#party",
      "id": 1,
      "entityName": "party",
      "entityUri": "http://localhost:8051/api/rest/instance/party"
    },
    {
      "name": "crm#customer#address",
      "id": 2,
      "entityName": "address",
      "entityUri": "http://localhost:8051/api/rest/instance/address"
    }
  ]
}

Tasks (system tasks)

Provides information about active and finished system tasks, identical to what is provided on the Task Execution screen in the MDM Web App Admin Center (see Monitoring). Query parameters offset and count are not required; if they are not present, default values are used instead.

/tasks
/tasks?offset=0&count=5
/tasks/active
/tasks/active?offset=0&count=5
/tasks/finished
/tasks/finished?offset=0&count=5
/tasks/task/{id}

Cancel or stop system task

Cancels a queued system task (status WAITING) or stops a running system task (status RUNNING).

Depending on the initial status, the task then moves to CANCELING and then CANCELED, or to STOPPING and then STOPPED, respectively.

/tasks/task/{id}/terminate
Request example
curl -u {admin_username}:{admin_password} --basic {URL}/api/rest/tasks/task/{task_id}/terminate

Event handlers

Provides information about the event handlers, identical to what is provided on the Event Handlers tab in the MDM Web App Admin Center (see Interfaces).

Query parameters offset and count are not required; if they are not present, default values are used instead.

/event-handlers
/event-handlers?offset=0&count=5
/event-handlers/finished
/event-handlers/finished?offset=0&count=5
/event-handlers/finished/{id}

Event handler state

You can query and change the state of individual event handlers.

Get event handler state

Use the following request to get the current state of an event handler:

Request
GET /api/rest/event-handlers/{name}/state
Response 
{
  "state": "ACTIVE"
}

The state field can have the following values:

State Description

ACTIVE

Handler is processing events as expected.

SWITCHING_TO_ACTIVE

Handler is transitioning to active state.

SWITCHING_TO_INACTIVE

Handler is draining current events before becoming inactive.

INACTIVE

Handler is paused and not processing events.

DISABLED

Handler is not configured or permanently turned off.

Change event handler state

Use the following request to change the state of an event handler:

Request 
PATCH /api/rest/event-handlers/{name}/state
{
  "state": "INACTIVE"
}

The handler might transition through intermediate states (for example, SWITCHING_TO_INACTIVE) before reaching the target state.

Statistics

Shows various statistics regarding instance types, instance records, master views, and their records. The information is identical to what is provided under Orchestration > MD Process Monitoring > Data Statistics in the MDM Web App Admin Center (see Administration).

/statistics/instance
/statistics/master

Instance statistics

Response 
{
  "statistics": {
    "party": {
      "active": 15234,
      "inactive": 421,
      "total": 15655,
      "details": {
        "crm": {
          "active": 8120,
          "inactive": 210,
          "total": 8330
        },
        "erp": {
          "active": 7114,
          "inactive": 211,
          "total": 7325
        }
      }
    }
  }
}

Master statistics

Response 
{
  "statistics": {
    "partymasters": {
      "name": "party",
      "view": "masters",
      "active": 12500,
      "inactive": 302,
      "total": 12802
    }
  }
}

Other interfaces

The endpoints indicated below show interfaces which provide information about MDM configuration.

  1. Services: Shows a list of deployed native SOAP services and their endpoints.

  2. Batch exports and batch loads: Show a list of available batch operations.

  3. Streaming consumers: Shows a list of streaming consumers which are configured, get name and status.

  4. Operation plan: Shows the order of executing different consolidation subtasks in the MDM engine when loading or processing data (that is, cleansing, matching and merging of specific entities).

/interfaces/services
/interfaces/batch/exports
/interfaces/batch/loads
/interfaces/streaming/consumers
/operation-plan

Operation plan

The operation plan shows the order of executing different consolidation subtasks in the MDM engine.

Response 
{
  "plan": [
    {
      "name": "cleanse_party",
      "provided": ["CLEANSED_party"],
      "required": [],
      "read": [
        { "name": "party", "uri": "http://localhost:8051/api/rest/instance/party" }
      ],
      "written": [
        { "name": "party", "uri": "http://localhost:8051/api/rest/instance/party" }
      ]
    },
    {
      "name": "match_party",
      "provided": ["MATCHED_party"],
      "required": ["CLEANSED_party"],
      "read": [
        { "name": "party", "uri": "http://localhost:8051/api/rest/instance/party" }
      ],
      "written": [
        { "name": "partymasters", "uri": "http://localhost:8051/api/rest/master/masters/party" }
      ]
    }
  ]
}

Was this page useful?