# Alliant API # Overview The Alliant User Applications include the Alliant API application, which is a Representational State Transfer (REST) Application Programming Interface (API) feature that allows you to interact with the Alliant system programmatically. You can use Alliant API to perform the following: - Create data in the Alliant system. - Read data from the Alliant system. - Update data in the Alliant system. - Delete data from the Alliant system. - Use an Alliant Tool on an Item (for example, set a Contract to **Complete**). Alliant API is based on REST principles. All interactions with Alliant API are made using standard Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) requests to a set of predefined endpoints (resources). Alliant API endpoints accept and return data in JavaScript Object Notation (JSON) format. Alliant API has the same hardware and software requirements as Alliant UI, and is installed and configured during the Alliant UI installation. When Alliant UI and Alliant API are installed, a Help Page is available from the Alliant Instance on the Web Server at **{base address}/{AlliantInstance}/api/help** (for example, **[http://WebServer/AlliantWebServerInstance/api/help](http://webserver/AlliantWebServerInstance/api/help)**). # Glossary The following Alliant terms and concepts are related to Alliant API: ## Adjustments on Tab Adjustments on Tab are Adjustments that are added to an Item directly from a User-Defined Tab (UD Tabs) on the Item window in Alliant Administration or Alliant UI. Adjustments on Tab must be associated with an Adjustment Type that is configured to use only one Detail Type. The Status for an Adjustment on Tab generally corresponds to the Status of the Item with which it is associated. In Alliant API, when you submit or receive data that includes Adjustments on Tab data, the Adjustments on Tab names include the **a_** prefix and are based on the name of the tab to which they are attached (for example, when the Adjustments are on a tab called **Advance Schedule**, the Adjustments on Tab name is `a_Advance Schedule`). Adjustments on Tab include Adjustment Details and Adjustment Control Totals subproperties: ``` "a_{AdjustmentOnTabName}":{ "adjustmentDetails": [{}, {}, ... ], "adjustmentTotals": [{}, {}, ... ] } ``` The `adjustmentDetails` property contains Adjustment Details data Items. Each Adjustment Details Item contains properties that represent the fields defined for the Adjustments on Tab. Some of these properties represent Reference fields. It is required that the `_action` subproperty is present for each Adjustment Details Item included in a request body for a Create or Update request. The value of the `_action` subproperty specifies the Action to perform on the Adjustment Details data Item. The following Actions are available for Adjustment Details data Items: - **add** -- specify this action when you want to add an Adjustment Item. - **update** -- specify this action when you want to update data for an Adjustment Item. - **delete** -- specify this action when you want to delete an Adjustment Item. The `adjustmentTotals` property contains Adjustment Control Total data Items for the Adjustments on Tab. Adjustment Control Totals are not present in a response and are not valid in a request body when the Entry Format for the corresponding Adjustment Type is not configured to use Adjustment Control Totals. Adjustment Control Totals have either one or two Items based on the associated Entry Format. When you submit Adjustment data in a create or update request, include all of the properties that are applicable based on the associated Adjustment Type or Entry Format. ## Child Collection Set of Data Items that are directly associated with a main (parent) Data Item of a resource. Child Collection Data Items include specific sets of properties that define each Item. For example, a Contact Item contains the Physical Addresses Child Collection, which defines the Physical Addresses that are related to a Contact. Additionally, each Physical Address includes multiple properties that are used to identify the Address (address1, city, postalCode, and so forth). Child Collection Data Items are accessed only from the parent resource (for example, you can only change a Physical Address by accessing the specific Contact and editing the information for the Physical Address for that Contact). ## Cross-reference Collection Set of Data Items that can exist independently in the Alliant system and can also be associated with other Alliant Data Items (for example, Adjustments in the Contract module). Unlike Child Collection, Cross-Reference Items can be accessed from their own specific resource (except for delete) or from a parent resource. ## Reference Properties Reference properties are properties that refer to existing Items in the Alliant system (for example, a Contact includes the `Contact Type` reference property). The names of reference properties are always suffixed with **Reference**. Reference properties are objects that include subproperties that identify the referenced Item. In a request, reference properties can identity Items using one of the subproperties below: - `_objectRef` -- identifies the Item by a positive integer value that corresponds to an `_objectId` value for an Item in the same request. Specifying an `_objectRef` value for a corresponding `_objectId` value sets the Reference property value to the Item identified by the `_objectId` value. - `_fromContext` -- identifies the Item from the context when the value is **true** (for example, when you submit a request for a specific Contract, the context is the Contract specified in the request resource). - `_useLicensor` -- identifies the Item from the `licensorContactReference` field value when the value is **true**. This property is only valid for the `actualStartDateItemReference`, `actualEndDateItemReference`, `estimatedStartDateItemReference`, and `estimatedEndDateItemReference` reference properties available on the IP Rights and IP Rights Template Rights data items. - `_useLicensee` -- identifies the Item from the `licenseeContactReference` field value when the value is **true**. This property is only valid for the `actualStartDateItemReference`, `actualEndDateItemReference`, `estimatedStartDateItemReference`, and `estimatedEndDateItemReference` reference properties available on the IP Rights and IP Rights Template Rights data items. - `guid` -- identifies the Item from the GUID (or Unique Identity) value that you specify. - `sid` -- identifies the Item from the System ID value that you specify. - `id` -- identifies the Item from the Alliant **ID** field value that you specify. - `name` -- identifies the Item from the Alliant **Name** field value that you specify. - `description` -- identifies the Item from the Alliant **Description** field value that you specify. - `displayName` -- identifies the Item from the **Display Name** value for the Item. When you specify more than one of the above subproperties in the request body, the value is taken from the first property that is available in the following order: `_objectRef`, `_fromContext`, `_useLicensor`, `_useLicensee`, `guid`, `sid`, `id`, `name`, `description`, `displayName` Reference properties include the following subproperties when returned in a response: - `_type` -- identifies the Alliant Datatype for the Item Type (for example, **Contract**, **Contact**, **Period**, and so forth). Types correspond to the names of resources accessible from the API endpoints (for example, api/data/**period**). - `displayName` -- specifies the **Display Name** value for the Item. and one of the subproperties below: - `guid` -- specifies the GUID (or Unique Identity) value for the Item. - `_fromContext` -- specifies when the Item is identified from the context. The value for this property is always **true** when returned in a response. When an Item is identified from the context, the guid property is not returned in the response. - `_useLicensor` -- specifies when the Item is identified from the `licensorContactReference` value. The value for this property is always **true** when returned in a response. This property is only valid for the `actualStartDateItemReference`, `actualEndDateItemReference`, `estimatedStartDateItemReference`, and `estimatedEndDateItemReference` reference properties available on the IP Rights and IP Rights Template Rights data items. When this property is included in the response, the `guid`, `fromContext`, and `useLicensee` properties are not returned in the response. - `_useLicensee` -- specifies when the Item is identified from the `licenseeContactReference` value. The value for this property is always **true** when returned in a response. This property is only valid for the `actualStartDateItemReference`, `actualEndDateItemReference`, `estimatedStartDateItemReference`, and `estimatedEndDateItemReference` reference properties available on the IP Rights and IP Rights Template Rights data items. When this property is included in the response, the `guid`, `fromContext`, and `useLicensor` properties are not returned in the response. ## Response Details Level The level of detail for Items returned in a response is determined by the Verbosity parameters. You specify the Verbosity for Items in a response using the following request query parameters: `minimal`, `verbose`, `default`, `include`, and `exclude`. ## User-Defined Datatypes Datatypes defined in Alliant to specify the valid values for a User-Defined Field (UD Fields). ## User-Defined Fields User-Defined Fields (UD Fields) are fields that are defined in Alliant for customizing Transaction Characteristics. The names of properties representing UD Fields are prefixed by **ud_** or by **udLookup_** (for UD Fields configured to use Lookup values) followed by the name of a UD Field (for example, **ud_field1** or **udLookup_field1**). When the Datatype for a UD Field is one of the Alliant Transaction Characteristics or a User-Defined Datatype, the API property representing the UD Field is a Reference property (for example, **ud_field1Reference** or **udLookup_field1Reference**). When a UD Field is configured to use Lookup values, the API property representing the UD Field is an object with the **udLookupItems** array subproperty. Entry format and lookup type of UD Field determine properties of each object in **udLookupItems** array. # Data Types | DataType | Format | | --- | --- | | DateTime | String representing dates in ISO8601 (for example, **"2017-02-07T08:29:11.893"**). | | Date Range | An object with `start` and `end` properties for a range of values. Either DateTime or **"min"/"max"** are valid as `start` and `end` values. When `start` and `end` values are the same, a single DateTime is valid. No value is represented by **null** (for example, **{"start": "2017-02-07","end": "2018-02-07"}**, **{"start": "min","end": "max"}**, **"2018-02-07"**, or **null**). | | Flag/Boolean | Either Boolean **true**/**false** or string "**Y**"/"**N**" are accepted. The values are saved in the database as "**Y**"/"**N**". Values "**Y**"/"**N**" are converted to Boolean and are returned as **true**/**false**. | | Integer | 32-bit Integer between negative 2,147,483,648 and positive 2,147,483,647. | | Integer Range | An object with `start` and `end` properties for a range of values. Either an Integer or **"min"/"max"** are valid as `start` and `end` values. When `start` and `end` values are the same, a single Integer is valid. No value is represented by **null** (for example, **{"start": 1,"end": 100}**, **{ "start": "min", "end": "max"}**, **1000**, or **null**). | | Percent Range/Real Range | An object with `start` and `end` properties for a range of values. Either Real/Percent or **"min"/"max"** are valid as `start` and `end` values. When `start` and `end` values are the same, a single Real/Percent is valid. No value is represented by **null** (for example, **{"start": 0.25,"end": 1.25}**, **{ "start": "min", "end": "max"}**, **10.25**, or **null**). | | Real/Percent | Decimal number in the range of SQL Decimal (25,9) Datatype. | | Small Integer | 16-bit Integer between negative 32768 and positive 32767. | | String/Text | Any sequence of UNICODE characters enclosed in double quotes. Special characters are escaped. | | Unique Identity | String representing a valid GUID (for example, **"guid": "29c78a53-5545-4465-ad6e-db2ae1f09877"**). | # Permissions Your Alliant System Administrator must configure User Group permissions in Alliant Security to allow Users access to data in the Alliant system. The permissions necessary for Alliant API depend on the modules that you want to access and the Actions that you want to perform. **Note**: When a User submits a Multiple-Item Read request for a module other than Contracts for which they do not have the **View** Action assigned, the request succeeds but the response contains data in **Minimal** verbosity format. When a User submits a Multiple-Item Read request for Contracts and they do not have the **View** Action assigned for Contracts, the request succeeds but the response contains data in **Minimal** verbosity format, excluding Contracts for which the User does not have access based on the values in the **Owner Group** and **View Access Group** fields for each Contract. This restriction applies only when your Alliant system is configured to use the Contract Access by User Group feature. # Response Formats ## Standard Response Alliant API returns responses in JSON format. The property names in a response are in camel case notation starting with a lowercase letter. Every response from Alliant API has the following format: ``` { "result": {}, "errors": [], "warnings": [], "hasErrors": false, "hasWarnings": false } ``` The response properties are as follows: - **result** -- this property is an object. This property contains the data for a request, when applicable, or returns null when no data is returned. When you request an Item or Items, the Item data returns in this property. When you create or update an Item, the data for the new or updated Item returns in this property. - **errors** -- this property is an array. This property contains any Errors that occur while processing the request. - **warnings** -- this property is an array. This property contains any Warnings related to the request. - **hasErrors** -- this property is a boolean. This property contains **true** when there are Errors in the **errors** property. This property contains **false** when there are no Errors in the **errors** property. - **hasWarnings** -- this property is a boolean. This property contains **true** when there are Warnings in the **warnings** property. This property contains **false** when there are no Warnings in the **warnings** property. # Multiple-Item Format Alliant API returns responses in JSON format. The property names in a response are in camel case notation starting with a lowercase letter. When you use Alliant API to request data for multiple Items, the data is returned in the following format: ``` { "result": { "previousPageUrl": null, "nextPageUrl": null, "itemCount": X, "totalItemCount": X, "items": [] }, "errors": [], "warnings": [], "hasErrors": false, "hasWarnings": false } ``` The response properties are as follows: - **result** -- this property is an object. This property contains the data for a request, when applicable, or returns null when no data is returned. When you request an Item or Items, the Item data returns in this property. When you create or update an Item, the data for the new or updated Item returns in this property. - **previousPageUrl** -- this property is a string. This property contains a URL for the previous set of results when there are more Items found than the request specifies to return. When you are currently accessing the first page, this property has a null value. - **nextPageUrl** -- this property is a string. This property contains a URL for the next set of results when there are more Items found than the request specifies to return. When you are currently accessing the last page, this property has a null value. - **itemCount** -- this property is an integer. This property specifies the number of Items returned for the request. - **totalItemCount** -- this property is an integer. This property specifies the total number of Items in the Alliant system that match the request criteria. - **items** -- this property is an array. This property displays the Item data for each Item returned in the request. - **errors** -- this property is an array. This property contains any Errors that occur while processing the request. - **warnings** -- this property is an array. This property contains any Warnings related to the request. - **hasErrors** -- this property is a boolean. This property contains **true** when there are Errors in the **errors** property. This property contains **false** when there are no Errors in the **errors** property. - **hasWarnings** -- this property is a boolean. This property contains **true** when there are Warnings in the **warnings** property. This property contains **false** when there are no Warnings in the **warnings** property. # Errors and Warnings Format Each object in **errors** or **warnings** array has the following format: ``` { "message":"value", "type":"value", "subType":"value", "itemType":"value", "itemKey":"value", "field":"value", "guid":"value", "sid":1001, "sequenceNumber":1001, "largeSequenceNumber":1001, "id":"value", "description":"value", "name":"value", "value":"value", "LogId":123456, "dateTime":"value" } ``` The properties are as follows: - **message** -- contains text describing the Error or Warning. This property is always present. - **type** -- specifies the type of the Error or Warning. This property is always present. The following Error Types are possible: - **General** -- indicates a general Error or Warning. - **Usage** -- indicates a usage Error or Warning. - **Serialization** -- indicates a serialization Error or Warning. - **NotApplicable** -- indicates a not applicable Error or Warning. - **NotAvailable** -- indicates a not available Error or Warning. - **Lock** -- indicates an Error related to Alliant locking. This error can be retried. - **Concurrency** -- indicates a concurrency Error or failed Timestamp check. Concurrency errors can be retried. - **Security** -- indicates an authentication or authorization Error. - **DatabaseDeadlock** -- indicates a Database deadlock Error. This error can be retried. - **subType** -- contains the System ID value for the Validation Rule that caused the Error or Warning when the Error or Warning relates to failing a validation check. This property returns only for Validation Error Types. - **itemType** -- contains the Item Type value for the Item that caused the Error or Warning. This property does not return for every Error Type. - **itemKey** -- contains the Item Key value in a string for the Item that caused the Error or Warning. This property does not return for every Error Type. Values are separated by commas when more than one value returns in the response. - **field** -- contains the field name for the Item that caused the Error or Warning. This property does not return for every Error Type. - **guid** -- contains the Unique Identity value for the Item that caused the Error or Warning. This property does not return for every Error Type. - **sid** -- contains the System ID value for the Item that caused the Error or Warning. This property does not return for every Error Type. - **sequenceNumber** -- contains the Sequence Number of a Child, Cross-Reference, or UD Field Lookup Item that caused the Error or Warning. This property does not return for every Error Type. - **largeSequenceNumber** -- contains the Large Sequence Number of a Child, Cross-Reference, or UD Field Lookup Item that caused the Error or Warning. This property does not return for every Error Type. - **id** -- contains the ID value for the Item that caused the Error or Warning. This property does not return for every Error Type. - **description** -- contains the Description value for the Item that caused the Error or Warning. This property does not return for every Error Type. - **name** -- contains the Name value for the Item that caused the Error or Warning. This property does not return for every Error Type. - **value** -- contains the ID of the Reference Item that was not found and caused the Error or Warning when a referenced Item in a request was not found in the Alliant system. This property does not return for every Error Type. - **logId** -- contains the Log ID for the Error message when an Error or Warning is logged to the Alliant Database. This property does not return for every Error Type. - **dateTime** -- contains the Date and Time for the Error message when an Error or Warning is logged to the Alliant Database. This property does not return for every Error Type. **Note:** When the request fails with the 500 status code, a single **message** field is returned. Version: 8.1 SP4 License: © Rightsline Software, Inc. ## Security ### HeaderToken 'Most endpoints use a token-based authentication. You must provide an Alliant session Security Token in the HTTP **X-AlliantSession** request header. You can use the [login endpoint](#operation/post-security-login) to acquire an Alliant session Security Token.' Type: apiKey In: header Name: X-AlliantSession ### BasicAuth Login endpoints use Basic Authentication. Basic Authentication is described in [RFC7617](https://datatracker.ietf.org/doc/html/rfc7617) by the Internet Engineering Task Force. See also https://en.wikipedia.org/wiki/Basic_access_authentication for further information. Type: http Scheme: basic ### BearerAuth 'Login endpoints use Bearer Token Authentication. Users can generate Bearer API Tokens that are associated with their Alliant User in the Alliant UI application or by using [Create a new User API Token](#operation/post-data-userApiTokens). Bearer Token Authentication is described in [RFC6750](https://datatracker.ietf.org/doc/html/rfc6750) by the Internet Engineering Task Force.' Type: http Scheme: bearer Bearer Format: Opaque ## Download OpenAPI description [Alliant API](https://alliant.redocly.app/_bundle/@v8.1SP4/Alliant%20API%20Definition%20Release.yaml) ## Security The Security API is a set of endpoints that allow your applications to log on, log off, and discover Alliant System and Application Layers. ### Login - [POST /api/security/login](https://alliant.redocly.app/alliant-api-definition-release/security/post-security-login.md): Log in to Alliant to acquire an Alliant session Security Token. An Alliant session Security Token is returned in token response property. It is valid until the time indicated in the expires response property or until a you logout. You must pass the Alliant session Security Token to all requests that require TokenAuth in the HTTP X-AlliantSession request header. ### Logout - [POST /api/security/logout](https://alliant.redocly.app/alliant-api-definition-release/security/post-security-logout.md): Log off the Alliant User associated with an Alliant session Security Token provided in the request. This request invalidates the Alliant session Security Token. ### List the Alliant System Layers - [GET /api/security/systemLayers](https://alliant.redocly.app/alliant-api-definition-release/security/get-security-systemlayers.md): Request a list of the Alliant System Layers that are available on the Alliant Web Server. ### List the Alliant Application Layers for an Alliant System Layer - [GET /api/security/systemLayers/{systemLayer}/applicationLayers](https://alliant.redocly.app/alliant-api-definition-release/security/get-security-systemlayers-systemlayer-applicationlayers.md): Request a list of the Alliant Application Layers that are available for a System Layer on the Alliant Web Server. ## Adjustments ### Get multiple Adjustments - [GET /api/data/adjustmentHeaders](https://alliant.redocly.app/alliant-api-definition-release/adjustments/get-data-adjustmentheaders.md): Read the data for multiple Adjustments. Adjustments are manually created item used to change the Alliant system data. All Adjustment information can be included in future Calculations. An Adjustment item can include Import Adjustments, Contract Adjustments, Calculation Adjustments, or any combination of these three types of Adjustments. An Import Adjustment is used to make changes to imported data. A Contract Adjustment is used to add transactions to a specific Contract. A Calculation Adjustment is used to change calculated data. ### Create a new Adjustment - [POST /api/data/adjustmentHeaders](https://alliant.redocly.app/alliant-api-definition-release/adjustments/post-data-adjustmentheaders.md): Create an Adjustment. Adjustments are manually created item used to change the Alliant system data. All Adjustment information can be included in future Calculations. An Adjustment item can include Import Adjustments, Contract Adjustments, Calculation Adjustments, or any combination of these three types of Adjustments. An Import Adjustment is used to make changes to imported data. A Contract Adjustment is used to add transactions to a specific Contract. A Calculation Adjustment is used to change calculated data. ### Get a single Adjustment - [GET /api/data/adjustmentHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/get-data-adjustmentheaders-guid.md): Read the data for a specific Adjustment. Adjustments are manually created item used to change the Alliant system data. All Adjustment information can be included in future Calculations. An Adjustment item can include Import Adjustments, Contract Adjustments, Calculation Adjustments, or any combination of these three types of Adjustments. An Import Adjustment is used to make changes to imported data. A Contract Adjustment is used to add transactions to a specific Contract. A Calculation Adjustment is used to change calculated data. ### Delete an Adjustment - [DELETE /api/data/adjustmentHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/delete-data-adjustmentheaders-guid.md): Delete a specific Adjustment. Adjustments are manually created item used to change the Alliant system data. All Adjustment information can be included in future Calculations. An Adjustment item can include Import Adjustments, Contract Adjustments, Calculation Adjustments, or any combination of these three types of Adjustments. An Import Adjustment is used to make changes to imported data. A Contract Adjustment is used to add transactions to a specific Contract. A Calculation Adjustment is used to change calculated data. ### Update an Adjustment - [PUT /api/data/adjustmentHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/put-data-adjustmentheaders-guid.md): Update the data for a specific Adjustment. Adjustments are manually created item used to change the Alliant system data. All Adjustment information can be included in future Calculations. An Adjustment item can include Import Adjustments, Contract Adjustments, Calculation Adjustments, or any combination of these three types of Adjustments. An Import Adjustment is used to make changes to imported data. A Contract Adjustment is used to add transactions to a specific Contract. A Calculation Adjustment is used to change calculated data. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. Note: When you submit a request to add or delete Child or Cross-reference Items, the request is not idempotent. When you specify an _action value for a Child or Cross-reference Item, the action supercedes the behaviour indicated by the HTTP verb for the Child or Cross-reference Item. In this scenario, the request is similar to an HTTP PATCH request. ### Update an Adjustment - [PATCH /api/data/adjustmentHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/patch-data-adjustmentheaders-guid.md): Update the data for a specific Adjustment. Adjustments are manually created item used to change the Alliant system data. All Adjustment information can be included in future Calculations. An Adjustment item can include Import Adjustments, Contract Adjustments, Calculation Adjustments, or any combination of these three types of Adjustments. An Import Adjustment is used to make changes to imported data. A Contract Adjustment is used to add transactions to a specific Contract. A Calculation Adjustment is used to change calculated data. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. Note: As well as partial updates, it is possible to use an _action to add or delete records. When there is an _action included within the body, then this action supercedes the behaviour indicated by the HTTP verb. ### Execute the Approve Tool on an existing Adjustment - [PUT /api/data/adjustmentHeaders/approve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/put-data-adjustmentheaders-approve-guid.md): Execute the Approve Tool on an existing Adjustment. ### Execute the Clear Tool on an existing Adjustment - [PUT /api/data/adjustmentHeaders/clear/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/put-data-adjustmentheaders-clear-guid.md): Execute the Clear Tool on an existing Adjustment. ### Execute the ClearRequest Tool on an existing Adjustment - [PUT /api/data/adjustmentHeaders/clearRequest/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/put-data-adjustmentheaders-clearrequest-guid.md): Execute the ClearRequest Tool on an existing Adjustment. ### Execute the Complete Tool on an existing Adjustment - [PUT /api/data/adjustmentHeaders/complete/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/put-data-adjustmentheaders-complete-guid.md): Execute the Complete Tool on an existing Adjustment. ### Copy an existing Adjustment - [PUT /api/data/adjustmentHeaders/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/put-data-adjustmentheaders-copy-guid.md): Copy a specific Adjustment. > This PUT does not behave as a standard HTTP PUT and is _NOT_ idempotent. This PUT will create a new resource. Its behaviour is that of a POST and it should be treated as such. ### Execute the In Setup Tool on an existing Adjustment - [PUT /api/data/adjustmentHeaders/insetup/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/put-data-adjustmentheaders-insetup-guid.md): Execute the In Setup Tool on an existing Adjustment. ### Execute the Post Tool on an existing Adjustment - [PUT /api/data/adjustmentHeaders/post/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/put-data-adjustmentheaders-post-guid.md): Execute the Post Tool on an existing Adjustment. ### Get multiple Adjustment Types - [GET /api/data/adjustmentTypeHeaders](https://alliant.redocly.app/alliant-api-definition-release/adjustments/get-data-adjustmenttypes.md): Read the data for multiple Adjustment Type Items. Alliant Adjustment Types specify the setup and default information for creating Adjustments. ### Get a single Adjustment Type - [GET /api/data/adjustmentTypeHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/adjustments/get-data-adjustmenttypeheaders-guid.md): Read the data for a single Adjustment Type Item. Alliant Adjustment Types specify the setup and default information for creating Adjustments. ## Computed Dates ### Get multiple Computed Dates - [GET /api/data/computedDateHeaders](https://alliant.redocly.app/alliant-api-definition-release/computed-dates/get-data-computeddateheaders.md): Read the data for multiple Computed Dates. ### Get a single Computed Date - [GET /api/data/computedDateHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/computed-dates/get-data-computeddateheaders-guid.md): Read the data for a specific Computed Date. ### Use the In Use Tool on a Computed Date - [PUT /api/data/computedDateHeaders/inUse/{guid}](https://alliant.redocly.app/alliant-api-definition-release/computed-dates/put-data-computeddateheaders-inuse-guid.md): Use the In Use Tool on a Computed Date. ### Use the Resolve Tool on a Computed Date - [PUT /api/data/computedDateHeaders/resolve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/computed-dates/put-data-computeddateheaders-resolve-guid.md): Use the Resolve Tool on a Computed Date. ## Contacts ### Get multiple Contacts - [GET /api/data/contacts](https://alliant.redocly.app/alliant-api-definition-release/contacts/get-data-contacts.md): Read the data for multiple Contacts. A Contact is an individual or business for which you want to maintain information in the Alliant system. A Contact can represent a Participant or Recipient in a Contract, can be associated with a Participant in a Contract, can represent a guild, and so forth. For example, you can set up a Contact that represents the accountant for a Participant, and add this Contact as a Statement Recipient to the Recipient Group for the Participant in a Contract. You can use the Alliant system to maintain information regarding Contact names, addresses, company names, and so forth. ### Create a new Contact - [POST /api/data/contacts](https://alliant.redocly.app/alliant-api-definition-release/contacts/post-data-contacts.md): A Contact is an individual or business for which you want to maintain information in the Alliant system. A Contact can represent a Participant or Recipient in a Contract, can be associated with a Participant in a Contract, can represent a guild, and so forth. For example, you can set up a Contact that represents the accountant for a Participant, and add this Contact as a Statement Recipient to the Recipient Group for the Participant in a Contract. You can use the Alliant system to maintain information regarding Contact names, addresses, company names, and so forth. When you want to create a Contact with Recipient Groups, if you simply want to default the contact to be its own recipient as part of your POST, simply include: JSON { "contactRecipientGroups": [ { "_action": "add", "contactRecipientGroupDetails": [ { "_action": "add" } ] } ], "contactAddresses": [ { "_action": "add", "addressTypeReference": { "displayName": "Business" }, "countryReference": { "displayName": "United States of America" }, "stateReference": { "displayName": "Iowa" }, "city": "1", "postalCode": "1" } ] } When you want to create a Contact with a linked Adjustment, you must first submit a POST Request to create the Contact. You must then submit a PUT or PATCH Request to update the Contact with the Adjustment information. The id and sortByName properties are required. The formattedName property is also required; however, when any of following properties are provided, Alliant API generates a value the formattedName property when it is not provided: firstName, lastName, middleName, namePrefix, nameSuffix, or companyName. ### Get a single Contact - [GET /api/data/contacts/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contacts/get-data-contacts-guid.md): Read the data for a specific Contact. A Contact is an individual or business for which you want to maintain information in the Alliant system. A Contact can represent a Participant or Recipient in a Contract, can be associated with a Participant in a Contract, can represent a guild, and so forth. For example, you can set up a Contact that represents the accountant for a Participant, and add this Contact as a Statement Recipient to the Recipient Group for the Participant in a Contract. You can use the Alliant system to maintain information regarding Contact names, addresses, company names, and so forth. ### Delete a Contact - [DELETE /api/data/contacts/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contacts/delete-data-contacts-guid.md): Delete a specific Contact. A Contact is an individual or business for which you want to maintain information in the Alliant system. A Contact can represent a Participant or Recipient in a Contract, can be associated with a Participant in a Contract, can represent a guild, and so forth. For example, you can set up a Contact that represents the accountant for a Participant, and add this Contact as a Statement Recipient to the Recipient Group for the Participant in a Contract. You can use the Alliant system to maintain information regarding Contact names, addresses, company names, and so forth. ### Update a Contact - [PUT /api/data/contacts/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contacts/put-data-contacts-guid.md): A Contact is an individual or business for which you want to maintain information in the Alliant system. A Contact can represent a Participant or Recipient in a Contract, can be associated with a Participant in a Contract, can represent a guild, and so forth. For example, you can set up a Contact that represents the accountant for a Participant, and add this Contact as a Statement Recipient to the Recipient Group for the Participant in a Contract. You can use the Alliant system to maintain information regarding Contact names, addresses, company names, and so forth. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, Child Data Item, Cross-Reference Item, or Adjustments on Tab Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items, Child Data Items, and Adjustments on Tab: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. When you want to create a Contact with a linked Adjustment, you must first submit a POST Request to create the Contact. You must then submit a PUT or PATCH Request to update the Contact with the Adjustment information. Note: When you submit a request to add or delete Child or Cross-reference Items, the request is not idempotent. When you specify an _action value for a Child or Cross-reference Item, the action supercedes the behaviour indicated by the HTTP verb for the Child or Cross-reference Item. In this scenario, the request is similar to an HTTP PATCH request. ### Update a Contact - [PATCH /api/data/contacts/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contacts/patch-data-contacts-guid.md): Update the data for a specific Contact. A Contact is an individual or business for which you want to maintain information in the Alliant system. A Contact can represent a Participant or Recipient in a Contract, can be associated with a Participant in a Contract, can represent a guild, and so forth. For example, you can set up a Contact that represents the accountant for a Participant, and add this Contact as a Statement Recipient to the Recipient Group for the Participant in a Contract. You can use the Alliant system to maintain information regarding Contact names, addresses, company names, and so forth. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, Child Data Item, Cross-Reference Item, or Adjustments on Tab Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items, Child Data Items, and Adjustments on Tab: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. When you want to create a Contact with Recipient Groups, you must first submit a POST Request to create the Contact with the Recipient Groups, but without Recipient Group Details. You must then submit a PUT or PATCH Request to update the Recipient Groups with the necessary Recipient Group Details. When you want to create a Contact with a linked Adjustment, you must first submit a POST Request to create the Contact. You must then submit a PUT or PATCH Request to update the Contact with the Adjustment information. Note: As well as partial updates, it is possible to use an _action to add or delete records. When there is an _action included within the body, then this action supercedes the behaviour indicated by the HTTP verb. ### Copy an existing Contact - [PUT /api/data/contacts/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contacts/put-data-contacts-copy-guid.md): Copy a specific Contact. > This PUT does not behave as a standard HTTP PUT and is _NOT_ idempotent. This PUT will create a new resource. Its behaviour is that of a POST and it should be treated as such. ### Use the In Use Tool on a Contact - [PUT /api/data/contacts/inUse/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contacts/put-data-contacts-inuse-guid.md): Use the In Use Tool on a Contact. ### Execute the Resolve Tool on an existing Contact - [PUT /api/data/contacts/resolve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contacts/put-data-contacts-resolve-guid.md): Execute the Resolve Tool on an existing Contact. Note: You must enable at least one of the Resolve Types. ### Verify an existing Contact - [PUT /api/data/contacts/verify/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contacts/put-data-contacts-verify-guid.md): Verify an existing Contact ### Verify all Contacts - [PUT /api/data/contacts/verifyAll](https://alliant.redocly.app/alliant-api-definition-release/contacts/put-data-contacts-verifyall.md): Verify all existing Contacts. ## Contact Lists ### Get multiple Contact Lists - [GET /api/data/contactListHeaders](https://alliant.redocly.app/alliant-api-definition-release/contact-lists/get-data-contactlistheaders.md): Read the data for multiple Contact Lists. A Contact List identifies a dynamic set of Contacts and Contact Lists. You create a Contact List by including and excluding specific Contacts and Contact Lists. Currently, you can use Contact Lists only for Internet Delivery purposes. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Create a Contact List - [POST /api/data/contactListHeaders](https://alliant.redocly.app/alliant-api-definition-release/contact-lists/post-data-contactlistheaders.md): Create a Contact List. A Contact List identifies a dynamic set of Contacts and Contact Lists. You create a Contact List by including and excluding specific Contacts and Contact Lists. Currently, you can use Contact Lists only for Internet Delivery purposes. If getOrCreateWithHashCategory query parameter is added then this endpoint gets an existing User-Defined Contact List or creates a new Contact List. If an existing User-Defined Contact List matches List Definition specified in a request (ListDetails and ListXrefs) for a Hash Category specified as a value of getOrCreateWithHashCategory query parameter then this Contact List is returned in a response. In this case, the successful response is indicated with a 200 status code. If no Contact List matches List Definition and Hash Category, then a new Contact List is created. In this case, the successful response is indicated with a 201 status code. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Get a single Contact List - [GET /api/data/contactListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contact-lists/get-data-contactlistheaders-guid.md): Read the data for a specific Contact List. A Contact List identifies a dynamic set of Contacts and Contact Lists. You create a Contact List by including and excluding specific Contacts and Contact Lists. Currently, you can use Contact Lists only for Internet Delivery purposes. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Delete a Contact List - [DELETE /api/data/contactListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contact-lists/delete-data-contactlistheaders-guid.md): Delete a specific Contact List. A Contact List identifies a dynamic set of Contacts and Contact Lists. You create a Contact List by including and excluding specific Contacts and Contact Lists. Currently, you can use Contact Lists only for Internet Delivery purposes. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Update a Contact List - [PUT /api/data/contactListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contact-lists/put-data-contactlistheaders-guid.md): Update the data for a specific Contact List. A Contact List identifies a dynamic set of Contacts and Contact Lists. You create a Contact List by including and excluding specific Contacts and Contact Lists. Currently, you can use Contact Lists only for Internet Delivery purposes. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item or Cross-Reference Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add - specify this action when you want to add a new Item. · delete - specify this action when you want to delete an Item. · update - specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add - specify this action when you want to add a Cross-Reference Item. · update - specify this action when you want to update data for a Cross-Reference Item. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. Note: When you submit a request to add or delete Child or Cross-reference Items, the request is not idempotent. When you specify an _action value for a Child or Cross-reference Item, the action supercedes the behaviour indicated by the HTTP verb for the Child or Cross-reference Item. In this scenario, the request is similar to an HTTP PATCH request. ### Update a Contact List - [PATCH /api/data/contactListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contact-lists/patch-data-contactlistheaders-guid.md): Update the data for a specific Contact List. A Contact List identifies a dynamic set of Contacts and Contact Lists. You create a Contact List by including and excluding specific Contacts and Contact Lists. Currently, you can use Contact Lists only for Internet Delivery purposes. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item or Cross-Reference Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add - specify this action when you want to add a new Item. · delete - specify this action when you want to delete an Item. · update - specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add - specify this action when you want to add a Cross-Reference Item. · update - specify this action when you want to update data for a Cross-Reference Item. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. Note: As well as partial updates, it is possible to use an _action to add or delete records. When there is an _action included within the body, then this action supercedes the behaviour indicated by the HTTP verb. ### Copy an existing Contact List - [PUT /api/data/contactListHeaders/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contact-lists/put-data-contactlistheaders-copy-guid.md): Copy a specific Contact List. > This PUT does not behave as a standard HTTP PUT and is _NOT_ idempotent. This PUT will create a new resource. Its behaviour is that of a POST and it should be treated as such. ### Execute the Resolve Tool for an existing Contact List - [PUT /api/data/contactListHeaders/resolve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contact-lists/put-data-contactlistheaders-resolve-guid.md): Execute the Resolve Tool on an existing Contact List. ## Contracts ### Get multiple Contracts - [GET /api/data/contracts](https://alliant.redocly.app/alliant-api-definition-release/contracts/get-data-contracts.md): Read the data for multiple Contacts. A Contract is an on-line data item that relates to a legal agreement between your company and an individual or company. In general, each Contract can define the related Participants, Recipients, Recipient Groups, Products, Deals, IP Rights, IP Rights Templates, Statement Schedule, Scope, System Events, User-Defined Fields (UD Fields), and so forth. ### Create a new Contract - [POST /api/data/contracts](https://alliant.redocly.app/alliant-api-definition-release/contracts/post-data-contracts.md): Create a Contract. A Contract is an on-line data item that relates to a legal agreement between your company and an individual or company. In general, each Contract can define the related Participants, Recipients, Recipient Groups, Products, Deals, IP Rights, IP Rights Templates, Statement Schedule, Scope, System Events, User-Defined Fields (UD Fields), and so forth. When you want to create a Contract with a linked Adjustment, you must first submit a POST Request to create the Contract. You must then submit a PUT or PATCH Request to update the Contract with the Adjustment information. When you want to create a Contract with a linked IP Right, you must first submit a POST Request to create the Contract. You must then submit a PUT or PATCH Request to update the Contract with the IP Right information. ### Get a single Contract - [GET /api/data/contracts/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/get-data-contracts-guid.md): Read the data for a specific Contract. A Contract is an on-line data item that relates to a legal agreement between your company and an individual or company. In general, each Contract can define the related Participants, Recipients, Recipient Groups, Products, Deals, IP Rights, IP Rights Templates, Statement Schedule, Scope, System Events, User-Defined Fields (UD Fields), and so forth. ### Delete a Contract - [DELETE /api/data/contracts/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/delete-data-contracts-guid.md): Delete a specific Contract. A Contract is an on-line data item that relates to a legal agreement between your company and an individual or company. In general, each Contract can define the related Participants, Recipients, Recipient Groups, Products, Deals, IP Rights, IP Rights Templates, Statement Schedule, Scope, System Events, User-Defined Fields (UD Fields), and so forth. ### Update a Contract - [PUT /api/data/contracts/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/put-data-contracts-guid.md): Update the data for a specific Contract. A Contract is an on-line data item that relates to a legal agreement between your company and an individual or company. In general, each Contract can define the related Participants, Recipients, Recipient Groups, Products, Deals, IP Rights, IP Rights Templates, Statement Schedule, Scope, System Events, User-Defined Fields (UD Fields), and so forth. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, Child Data Item, Cross-Reference Item, or Adjustments on Tab Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items, Child Data Items, and Adjustments on Tab: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. When you want to create a Contract with a linked Adjustment, you must first submit a POST Request to create the Contract. You must then submit a PUT or PATCH Request to update the Contract with the Adjustment information. When you want to create a Contract with a linked IP Right, you must first submit a POST Request to create the Contract. You must then submit a PUT or PATCH Request to update the Contract with the IP Right information. Note: When you submit a request to add or delete Child or Cross-reference Items, the request is not idempotent. When you specify an _action value for a Child or Cross-reference Item, the action supercedes the behaviour indicated by the HTTP verb for the Child or Cross-reference Item. In this scenario, the request is similar to an HTTP PATCH request. ### Update a Contract - [PATCH /api/data/contracts/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/patch-data-contracts-guid.md): Update the data for a specific Contract. A Contract is an on-line data item that relates to a legal agreement between your company and an individual or company. In general, each Contract can define the related Participants, Recipients, Recipient Groups, Products, Deals, IP Rights, IP Rights Templates, Statement Schedule, Scope, System Events, User-Defined Fields (UD Fields), and so forth. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, Child Data Item, Cross-Reference Item, or Adjustments on Tab Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items, Child Data Items, and Adjustments on Tab: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. When you want to create a Contract with a linked Adjustment, you must first submit a POST Request to create the Contract. You must then submit a PUT or PATCH Request to update the Contract with the Adjustment information. When you want to create a Contract with a linked IP Right, you must first submit a POST Request to create the Contract. You must then submit a PUT or PATCH Request to update the Contract with the IP Right information. Note: As well as partial updates, it is possible to use an _action to add or delete records. When there is an _action included within the body, then this action supercedes the behaviour indicated by the HTTP verb. ### Execute the Approve Tool on an existing Contract - [PUT /api/data/contracts/approve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/put-data-contracts-approve-guid.md): Execute the Approve Tool on an existing Contract. ### Execute the Complete Tool on an existing Contract - [PUT /api/data/contracts/complete/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/put-data-contracts-complete-guid.md): Execute the Complete Tool on an existing Contract. ### Execute the Copy Tool on an existing Contract - [PUT /api/data/contracts/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/put-data-contracts-copy-guid.md): Execute the Copy Tool on an existing Contract. ### Execute the In Setup Tool on an existing Contract - [PUT /api/data/contracts/insetup/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/put-data-contracts-insetup-guid.md): Execute the In Setup Tool on an existing Contract. ### Execute the Model Tool on an existing Contract - [PUT /api/data/contracts/model/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/put-data-contracts-model-guid.md): Execute the Model Tool on an existing Contract. ### Execute the Resolve Tool on an existing Contract - [PUT /api/data/contracts/resolve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/put-data-contracts-resolve-guid.md): Execute the Resolve Tool on an existing Contract. Note: You must enable at least one of the Resolve Types. ### Execute the Revise Tool on an existing Contract - [PUT /api/data/contracts/revise/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contracts/put-data-contracts-revise-guid.md): Execute the Revise Tool on an existing Contract. ### Get multiple Contracts by referenced Participants - [GET /api/data/contractByReferencedParticipants](https://alliant.redocly.app/alliant-api-definition-release/contracts/get-data-contractbyreferencedparticipants.md): Read the data for multiple Contracts by referenced Participants. ### Get multiple Contracts by referenced User1s - [GET /api/data/contractByReferencedUser1s](https://alliant.redocly.app/alliant-api-definition-release/contracts/get-data-contractbyreferenceduser1s.md): Read the data for multiple Contracts by referenced User1s. ### Get multiple Contracts by referenced User4s - [GET /api/data/contractByReferencedUser4s](https://alliant.redocly.app/alliant-api-definition-release/contracts/get-data-contractbyreferenceduser4s.md): Read the data for multiple Contracts by referenced User4s. ## Contract Lists ### Get multiple Contract Lists - [GET /api/data/contractListHeaders](https://alliant.redocly.app/alliant-api-definition-release/contract-lists/get-data-contractlistheaders.md): Read the data for multiple Contract Lists. A Contract List identifies a dynamic set of Contracts and Contract Lists. You create a Contract List by including and excluding specific Contracts and Contract Lists. Currently, you can use Contract Lists only for Internet Delivery purposes. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Create a Contract List - [POST /api/data/contractListHeaders](https://alliant.redocly.app/alliant-api-definition-release/contract-lists/post-data-contractlistheaders.md): Create a Contract List. A Contract List identifies a dynamic set of Contracts and Contract Lists. You create a Contract List by including and excluding specific Contracts and Contract Lists. Currently, you can use Contract Lists only for Internet Delivery purposes. If getOrCreateWithHashCategory query parameter is added then this endpoint gets an existing User-Defined Contract List or creates a new Contract List. If an existing User-Defined Contract List matches List Definition specified in a request (ListDetails and ListXrefs) for a Hash Category specified as a value of getOrCreateWithHashCategory query parameter then this Contract List is returned in a response. In this case, the successful response is indicated with a 200 status code. If no Contract List matches List Definition and Hash Category, then a new Contract List is created. In this case, the successful response is indicated with a 201 status code. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Get a single Contract List - [GET /api/data/contractListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-lists/get-data-contractlistheaders-guid.md): Read the data for a specific Contract List. A Contract List identifies a dynamic set of Contracts and Contract Lists. You create a Contract List by including and excluding specific Contracts and Contract Lists. Currently, you can use Contract Lists only for Internet Delivery purposes. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Update a Contract List - [PUT /api/data/contractListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-lists/put-data-contractlistheaders-guid.md): Update the data for a specific Contract List. A Contract List identifies a dynamic set of Contracts and Contract Lists. You create a Contract List by including and excluding specific Contracts and Contract Lists. Currently, you can use Contract Lists only for Internet Delivery purposes. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item or Cross-Reference Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. Note: When you submit a request to add or delete Child or Cross-reference Items, the request is not idempotent. When you specify an _action value for a Child or Cross-reference Item, the action supercedes the behaviour indicated by the HTTP verb for the Child or Cross-reference Item. In this scenario, the request is similar to an HTTP PATCH request. ### Update a Contract List - [PATCH /api/data/contractListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-lists/patch-data-contractlistheaders-guid.md): Update the data for a specific Contract List. A Contract List identifies a dynamic set of Contracts and Contract Lists. You create a Contract List by including and excluding specific Contracts and Contract Lists. Currently, you can use Contract Lists only for Internet Delivery purposes. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item or Cross-Reference Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. Note: As well as partial updates, it is possible to use an _action to add or delete records. When there is an _action included within the body, then this action supercedes the behaviour indicated by the HTTP verb. ### Delete a Contract List - [DELETE /api/data/contractListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-lists/delete-data-contractlistheaders-guid.md): Delete a specific Contract List. A Contract List identifies a dynamic set of Contracts and Contract Lists. You create a Contract List by including and excluding specific Contracts and Contract Lists. Currently, you can use Contract Lists only for Internet Delivery purposes. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Copy an existing Contract List - [PUT /api/data/contractListHeaders/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-lists/put-data-contractlistheaders-copy-guid.md): Copy a specific Contract List. > This PUT does not behave as a standard HTTP PUT and is _NOT_ idempotent. This PUT will create a new resource. Its behaviour is that of a POST and it should be treated as such. ### Execute the Resolve Tool for an existing Contract List - [PUT /api/data/contractListHeaders/resolve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-lists/put-data-contractlistheaders-resolve-guid.md): Execute the Resolve Tool on an existing Contract List. ## Contract Groups ### Get multiple Contract Groups - [GET /api/data/contractGroups](https://alliant.redocly.app/alliant-api-definition-release/contract-groups/get-data-contractgroups.md): Read the data for multiple Contract Groups. ### Create a Contract Group - [POST /api/data/contractGroups](https://alliant.redocly.app/alliant-api-definition-release/contract-groups/post-data-contractgroups.md): Create a Contract Group. ### Get a single Contract Group - [GET /api/data/contractGroups/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-groups/get-data-contractgroups-guid.md): Read the data for a specific Contract Group. ### Update a Contract Group - [PUT /api/data/contractGroups/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-groups/put-data-contractgroups-guid.md): Update the data for a specific Contract Group. ### Update a Contract Group - [PATCH /api/data/contractGroups/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-groups/patch-data-contractgroups-guid.md): Update the data for a specific Contract Group. ### Delete a Contract Group - [DELETE /api/data/contractGroups/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-groups/delete-data-contractgroups-guid.md): Delete a specific Contract Group. ### Use the In Use Tool on a Contract Group - [PUT /api/data/contractGroups/inUse/{guid}](https://alliant.redocly.app/alliant-api-definition-release/contract-groups/put-data-contractgroups-inuse-guid.md): Use the In Use Tool on a Contract Group. ## Download Endpoints ### Download a specific Contact Attachment. - [GET /api/data/download/contactAttachments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/download-endpoints/get-data-download-contactattachments-guid.md): Download a specific Contact Attachment. You can get the Download URL for each Contact Attachment from the _downloadUrl property in the contactAttachments collection for each Contact. ### Download a specific Contract Attachment. - [GET /api/data/download/contractAttachments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/download-endpoints/get-data-download-contractattachments-guid.md): Download a specific Contract Attachment. You can get the Download URL for each Contract Attachment from the _downloadUrl property in the contractAttachments collection for each Contract. ### Download a specific Deal Attachment. - [GET /api/data/download/dealAttachments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/download-endpoints/get-data-download-dealattachments-guid.md): Download a specific Deal Attachment. You can get the Download URL for each Deal Attachment from the _downloadUrl property in the dealAttachments collection for each Deal. ### Download a specific IP Right Attachment. - [GET /api/data/download/ipRightAttachments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/download-endpoints/get-data-download-iprightattachments-guid.md): Download a specific IP Right Attachment. You can get the Download URL for each IP Right Attachment from the _downloadUrl property in the ipRightAttachments collection for each IP Right. ### Download a specific IP Rights Template Right Attachment. - [GET /api/data/download/ipRightTemplateRightAttachments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/download-endpoints/get-data-download-iprighttemplaterightattachments-guid.md): Download a specific IP Rights Template Right Attachment. You can get the Download URL for each IP Right Template Right Attachment from the _downloadUrl property in the ipRightTemplateRightAttachments collection for each IP Right Template Right. ### Download a specific Note Attachment. - [GET /api/data/download/noteAttachment/{guid}](https://alliant.redocly.app/alliant-api-definition-release/download-endpoints/get-data-download-noteattachment-guid.md): Download a specific Note Attachment. You can get the Download URL for each Note Attachment from the _downloadUrl property in the noteAttachments collection in the associated Notes collection for each Item, when applicable. ### Download a specific Statement. - [GET /api/data/download/statementResultSummary/{guid}](https://alliant.redocly.app/alliant-api-definition-release/download-endpoints/get-data-download-statementresultsummary-guid.md): Download a specific Statement. You can get the Download URL for a Statement Result from the _downloadUrl property when you GET the information for a Statement Result Summary. ### Download a specific Transaction Characteristic Item Attachment - [GET /api/data/download/userXAttachments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/download-endpoints/get-data-download-userxattachments-guid.md): Download a specific Transaction Characteristic Item Attachment. You can get the Download URL for each Transaction Characteristic Item Attachment from the _downloadUrl property in the userXAttachments collection for each Transaction Characteristic Item. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ## IP Rights ### Get multiple IP Rights - [GET /api/data/ipRights](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/get-data-iprights.md): Read the data for multiple IP Rights. ### Create a new IP Right - [POST /api/data/ipRights](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/post-data-iprights.md): Create an IP Right. ### Get a single IP Right - [GET /api/data/ipRights/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/get-data-ipright-guid.md): Read the data for a specific IP Right. ### Update an IP Right - [PUT /api/data/ipRights/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/put-data-ipright-guid.md): Update the data for a specific IP Right. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. ### Update an IP Right - [PATCH /api/data/ipRights/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/patch-data-ipright-guid.md): Update the data for a specific IP Right. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. ### Delete an IP Right - [DELETE /api/data/ipRights/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/delete-data-iprights-guid.md): Delete a specific IP Right. ### Add IP Rights from an IP Rights Template - [PUT /api/data/ipRights/addFromTemplate](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/put-data-iprights-addfromtemplate.md): Add IP Rights from an IP Rights Template. ### Execute the Copy Tool on an existing IP Right - [PUT /api/data/ipRights/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/put-data-iprights-copy-guid.md): Execute the Copy Tool on an existing IP Right to copy the IP Right. ### Use the In Use Tool on an IP Right - [PUT /api/data/ipRights/inUse/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/put-data-iprights-inuse-guid.md): Use the In Use Tool on an IP Right. ### Use the Resolve Tool on an IP Right - [PUT /api/data/ipRights/resolve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights/put-data-iprights-resolve-guid.md): Use the Resolve Tool on an IP Right. ## IP Rights Templates ### Get multiple IP Rights Template Headers - [GET /api/data/ipRightsEntryTemplateHeaders](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/get-data-iprightsentrytemplateheaders.md): Read the data for multiple IP Rights Template Headers. ### Create an IP Rights Template Header - [POST /api/data/ipRightsEntryTemplateHeaders](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/post-data-iprightsentrytemplateheaders.md): Create an IP Rights Template Header. ### Get a single IP Rights Template Header - [GET /api/data/ipRightsEntryTemplateHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/get-data-iprightsentrytemplateheaders-guid.md): Read the data for a specific IP Rights Template Header. ### Update an IP Rights Template Header - [PUT /api/data/ipRightsEntryTemplateHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/put-data-iprightsentrytemplateheaders-guid.md): Update the data for a specific IP Rights Template Header. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item or Child Data Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items and Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. ### Update an IP Rights Template Header - [PATCH /api/data/ipRightsEntryTemplateHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/patch-data-iprightsentrytemplateheaders-guid.md): Update the data for a specific IP Rights Template Header. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item or Child Data Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items and Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. ### Delete an IP Rights Template Header - [DELETE /api/data/ipRightsEntryTemplateHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/delete-data-iprightsentrytemplateheaders-guid.md): Delete a specific IP Rights Template Header. ### Execute the Copy Tool on an existing IP Rights Template Header - [PUT /api/data/ipRightsEntryTemplateHeaders/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/put-data-iprightsentrytemplateheaders-copy-guid.md): Execute the Copy Tool on an existing IP Rights Template Header. ### Use the In Use Tool on an IP Rights Template Header - [PUT /api/data/ipRightsEntryTemplateHeaders/inUse/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/put-data-iprightsentrytemplateheaders-inuse-guid.md): Use the In Use Tool on an IP Rights Template Header. ### Use the Resolve Tool on an IP Rights Template Header - [PUT /api/data/ipRightsEntryTemplateHeaders/resolve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/put-data-iprightsentrytemplateheaders-resolve-guid.md): Use the Resolve Tool on an IP Rights Template Header. ### Get multiple IP Rights Template Parameters - [GET /api/data/ipRightsParmColumns](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/get-data-iprightsparmcolumns.md): Read the data for multiple IP Rights Template Parameters. ### Get a single IP Rights Template Parameter - [GET /api/data/ipRightsParmColumns/{guid}](https://alliant.redocly.app/alliant-api-definition-release/ip-rights-templates/get-data-iprightsparmcolumns-guid.md): Read the data for a specific IP Rights Template Parameter. ## Payments ### Get multiple Payments - [GET /api/data/payments](https://alliant.redocly.app/alliant-api-definition-release/payments/get-data-payments.md): Read the data for multiple Payments. ### Create a new Payment - [POST /api/data/payments](https://alliant.redocly.app/alliant-api-definition-release/payments/post-data-payments.md): Create a new payment. ### Get a single Payment - [GET /api/data/payments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/get-data-payments-guid.md): Read the data for a specific Payment. A Payment is an on-line data item that relates to a legal agreement between your company and an individual or company. In general, each Payment can define the related Participants, Recipients, Recipient Groups, Products, Deals, IP Rights, IP Rights Templates, Statement Schedule, Scope, System Events, User-Defined Fields (UD Fields), and so forth. ### Delete a Payment - [DELETE /api/data/payments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/delete-data-payemnts-guid.md): Delete a specific Payment. TODO for Product Team ### Update a Payment - [PUT /api/data/payments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/put-data-payments-guid.md): Update the data for a specific Payment. TODO for Product Team The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, Child Data Item, Cross-Reference Item, or Adjustments on Tab Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items, Child Data Items, and Adjustments on Tab: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. Note: When you submit a request to add or delete Child or Cross-reference Items, the request is not idempotent. When you specify an _action value for a Child or Cross-reference Item, the action supercedes the behaviour indicated by the HTTP verb for the Child or Cross-reference Item. In this scenario, the request is similar to an HTTP PATCH request. ### Update a Payment - [PATCH /api/data/payments/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/patch-data-payments-guid.md): Update the data for a specific Payment. TODO For Product Team The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, Child Data Item, Cross-Reference Item, or Adjustments on Tab Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items, Child Data Items, and Adjustments on Tab: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. Note: As well as partial updates, it is possible to use an _action to add or delete records. When there is an _action included within the body, then this action supercedes the behaviour indicated by the HTTP verb. ### Execute the Approve Tool on an existing Payment - [PUT /api/data/payments/approve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/put-data-payments-approve-guid.md): Execute the Approve Tool on an existing Payment. ### Execute the Complete Tool on an existing Payment - [PUT /api/data/payments/complete/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/put-data-payment-complete-guid.md): Execute the Complete Tool on an existing Payment. ### Execute the Copy Tool on an existing Payment - [PUT /api/data/payments/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/put-data-payments-copy-guid.md): Execute the Copy Tool on an existing Payment. ### Execute the Hold Tool on an existing Payment - [PUT /api/data/payments/hold/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/put-data-payment-hold-guid.md): Execute the Hold Tool on an existing Payment. ### Execute the In Setup Tool on an existing Payment - [PUT /api/data/payments/insetup/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/put-data-payment-insetup-guid.md): Execute the In Setup Tool on an existing Payment. ### Execute the Release Tool on an existing Payment - [PUT /api/data/payments/release/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/put-data-payment-release-guid.md): Execute the Release Tool on an existing Payment. ### Execute the Paid Tool on an existing Payment - [PUT /api/data/payments/paid/{guid}](https://alliant.redocly.app/alliant-api-definition-release/payments/put-data-payment-paid-guid.md): Execute the Paid Tool on an existing Payment. ## Process Server Groups ### Get multiple Process Server Groups - [GET /api/data/processServerGroups](https://alliant.redocly.app/alliant-api-definition-release/process-server-groups/get-data-processservergroups.md): Read the data for multiple Process Server Groups. ### Create a new Process Server Group - [POST /api/data/processServerGroups](https://alliant.redocly.app/alliant-api-definition-release/process-server-groups/post-data-processservergroups.md): Create a Process Server Group. ### Get a single Process Server Group - [GET /api/data/processServerGroups/{guid}](https://alliant.redocly.app/alliant-api-definition-release/process-server-groups/get-data-processservergroups-guid.md): Read the data for a specific Process Server Group. ### Delete a Process Server Group - [DELETE /api/data/processServerGroups/{guid}](https://alliant.redocly.app/alliant-api-definition-release/process-server-groups/delete-data-processservergroups-guid.md): Delete a specific Process Server Group. ### Update a Process Server Group - [PUT /api/data/processServerGroups/{guid}](https://alliant.redocly.app/alliant-api-definition-release/process-server-groups/put-data-processservergroups-guid.md): Update the data for a specific Process Server Group. ### Update a Process Server Group - [PATCH /api/data/processServerGroups/{guid}](https://alliant.redocly.app/alliant-api-definition-release/process-server-groups/patch-data-processservergroups-guid.md): Update the data for a specific Process Server Group. ## Scheduled Tasks ### Get multiple Scheduled Task Summaries - [GET /api/data/scheduledTaskSummaries](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/get-data-scheduledtasksummaries.md): Read the data for multiple Scheduled Task Summaries. ### Get a single Scheduled Task Summary - [GET /api/data/scheduledTaskSummary/{guid}](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/get-data-scheduledtasksummaries-guid.md): Read the data for a specific Scheduled Task Summary. ### Execute the Approve Tool on a collection of Scheduled Task Summaries - [PUT /api/data/scheduledTaskSummary/approve](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-approve.md): Execute the Approve Tool on a collection of Scheduled Task Summaries. You must specify the collection of Scheduled Tasks that you want to approve the $filter parameter or $filter property in a request body. ### Execute the Approve Tool on a single Scheduled Task Summary Item - [PUT /api/data/scheduledTaskSummary/approve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-approve-guid.md): Execute the Approve Tool on a single Scheduled Task Summary Item. ### Execute the Assign Tool on a collection of Scheduled Task Summaries - [PUT /api/data/scheduledTaskSummary/assign](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-assign.md): Execute the Assign Tool on a collection of Scheduled Task Summaries. You must specify the collection of Scheduled Tasks that you want to assign using the $filter parameter or $filter property in a request body. ### Execute the Assign Tool on a single Scheduled Task Summary Item - [PUT /api/data/scheduledTaskSummary/assign/{guid}](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-assign-guid.md): Execute the Assign Tool on a single Scheduled Task Summary Item. ### Execute the Clear Tool on a collection of Scheduled Task Summaries - [PUT /api/data/scheduledTaskSummary/clear](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-clear.md): Execute the Clear Tool on a collection of Scheduled Task Summaries. You must specify the collection of Scheduled Tasks that you want to clear using the $filter parameter or $filter property in a request body. ### Execute the Clear Tool on a single Scheduled Task Summary Item - [PUT /api/data/scheduledTaskSummary/clear/{guid}](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-clear-guid.md): Execute the Clear Tool on a single Scheduled Task Summary Item. ### Execute the Hold Tool on a collection of Scheduled Task Summaries - [PUT /api/data/scheduledTaskSummary/hold](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-hold.md): Execute the Hold Tool on a collection of Scheduled Task Summaries. You must specify the collection of Scheduled Tasks that you want to hold using the the $filter parameter or $filter property in a request body. ### Execute the Hold Tool on a single Scheduled Task Summary Item - [PUT /api/data/scheduledTaskSummary/hold/{guid}](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-hold-guid.md): Execute the Hold Tool on a single Scheduled Task Summary Item. ### Execute the Release Tool on a collection of Scheduled Task Summaries - [PUT /api/data/scheduledTaskSummary/release](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-release.md): Execute the Release Tool on a collection of Scheduled Task Summaries. You must specify the collection of Scheduled Tasks that you want to hold using the $filter parameter or $filter property in a request body. ### Execute the Release Tool on a single Scheduled Task Summary Item - [PUT /api/data/scheduledTaskSummary/release/{guid}](https://alliant.redocly.app/alliant-api-definition-release/scheduled-tasks/put-data-scheduledtasksummaries-release-guid.md): Execute the Release Tool on a single Scheduled Task Summary Item. ## Statement Results ### Get multiple Statement Result Summaries - [GET /api/data/statementResultSummaries](https://alliant.redocly.app/alliant-api-definition-release/statement-results/get-data-statementresultsummaries.md): Read the data for multiple Statement Result Summaries ### Get a single Statement Result Summary - [GET /api/data/statementResultSummaries/{guid}](https://alliant.redocly.app/alliant-api-definition-release/statement-results/get-data-statementresultsummaries-guid.md): Read the data for a specific Statement Result Summary. ## Submitted Tasks ### Get multiple Submitted Tasks - [GET /api/data/submittedTasks](https://alliant.redocly.app/alliant-api-definition-release/submitted-tasks/get-data-submittedtasks.md): Read the data for multiple Submitted Tasks. ### Get a single Submitted Task - [GET /api/data/submittedTasks/{guid}](https://alliant.redocly.app/alliant-api-definition-release/submitted-tasks/get-data-submittedtasks-guid.md): Read the data for a specific Submitted Task. ### Update a Submitted Task - [PUT /api/data/submittedTasks/{guid}](https://alliant.redocly.app/alliant-api-definition-release/submitted-tasks/put-data-submittedtasks-guid.md): Update the data for a specific Submitted Task. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. ### Update a Submitted Task - [PATCH /api/data/submittedTasks/{guid}](https://alliant.redocly.app/alliant-api-definition-release/submitted-tasks/patch-data-submittedtasks-guid.md): Update the data for a specific Submitted Task. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. ### Delete a Submitted Task - [DELETE /api/data/submittedTasks/{guid}](https://alliant.redocly.app/alliant-api-definition-release/submitted-tasks/delete-data-submittedtasks-guid.md): Delete a specific Submitted Task. ### Execute the Resubmit Tool on a single Submitted Task - [PUT /api/data/submittedTasks/resubmit/{guid}](https://alliant.redocly.app/alliant-api-definition-release/submitted-tasks/put-data-submittedtasks-resubmit-guid.md): Execute the Resubmit Tool on a single Submitted Task. ### Execute the Cancel Tool on a single Submitted Task - [PUT /api/data/submittedTasks/cancel/{guid}](https://alliant.redocly.app/alliant-api-definition-release/submitted-tasks/put-data-submittedtasks-cancel-guid.md): Execute the Cancel Tool on a single Submitted Task. ### Get multiple Submitted Task Messages - [GET /api/data/submittedTaskMessages](https://alliant.redocly.app/alliant-api-definition-release/submitted-tasks/get-data-submittedtaskmessages.md): Read the data for multiple Submitted Task Messages. ### Get a single Submitted Task Message - [GET /api/data/submittedTaskMessages/{guid}](https://alliant.redocly.app/alliant-api-definition-release/submitted-tasks/get-data-submittedtaskmessages-guid.md): Read the data for a specific Submitted Task Message. ## Transaction Characteristics ### Get multiple Transaction Characteristic Items - [GET /api/data/userXs](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristics/get-data-userxs.md): Read the data for multiple Transaction Characteristic Items. The 20 Transaction Characteristics (User1 through User20) that allow you to customize your Alliant system using the business terms with which you are familiar, and to define as much, or as little, information about a Transaction Characteristic as you require. Each user-customizable Transaction Characteristic can be customized by specifying a name (such as Products, Languages, Distributors, and so forth), assigning Admin Classes, configuring User-Defined Tabs, and adding User-Defined Fields, Adjustments, Data Queries, and Web Pages to the UD Tabs. You can then create the Transaction Characteristic Items that are used throughout your Alliant system. User-customizable Transaction Characteristics can be selected for use for Participants, User-Defined Event Types, Statement Groups, Payment Methods, or Countries, and can be configured to use the Automatic ID Generation feature. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ### Create a new Transaction Characteristic Item - [POST /api/data/userXs](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristics/post-data-userxs.md): Create a Transaction Characteristic Item. The 20 Transaction Characteristics (User1 through User20) that allow you to customize your Alliant system using the business terms with which you are familiar, and to define as much, or as little, information about a Transaction Characteristic as you require. Each user-customizable Transaction Characteristic can be customized by specifying a name (such as Products, Languages, Distributors, and so forth), assigning Admin Classes, configuring User-Defined Tabs, and adding User-Defined Fields, Adjustments, Data Queries, and Web Pages to the UD Tabs. You can then create the Transaction Characteristic Items that are used throughout your Alliant system. User-customizable Transaction Characteristics can be selected for use for Participants, User-Defined Event Types, Statement Groups, Payment Methods, or Countries, and can be configured to use the Automatic ID Generation feature. When you want to create a Transaction Characteristic Item with a linked Adjustment, you must first submit a POST Request to create the Transaction Characteristic Item. You must then submit a PUT or PATCH Request to update the Transaction Characteristic Item with the Adjustment information. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ### Get a single Transaction Characteristic Item - [GET /api/data/userX/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristics/get-data-userx-guid.md): Read the data for a specific Transaction Characteristic Item. The 20 Transaction Characteristics (User1 through User20) that allow you to customize your Alliant system using the business terms with which you are familiar, and to define as much, or as little, information about a Transaction Characteristic as you require. Each user-customizable Transaction Characteristic can be customized by specifying a name (such as Products, Languages, Distributors, and so forth), assigning Admin Classes, configuring User-Defined Tabs, and adding User-Defined Fields, Adjustments, Data Queries, and Web Pages to the UD Tabs. You can then create the Transaction Characteristic Items that are used throughout your Alliant system. User-customizable Transaction Characteristics can be selected for use for Participants, User-Defined Event Types, Statement Groups, Payment Methods, or Countries, and can be configured to use the Automatic ID Generation feature. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ### Update a Transaction Characteristic Item - [PUT /api/data/userX/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristics/put-data-userx-guid.md): Update the data for a specific Transaction Characteristic Item. The 20 Transaction Characteristics (User1 through User20) that allow you to customize your Alliant system using the business terms with which you are familiar, and to define as much, or as little, information about a Transaction Characteristic as you require. Each user-customizable Transaction Characteristic can be customized by specifying a name (such as Products, Languages, Distributors, and so forth), assigning Admin Classes, configuring User-Defined Tabs, and adding User-Defined Fields, Adjustments, Data Queries, and Web Pages to the UD Tabs. You can then create the Transaction Characteristic Items that are used throughout your Alliant system. User-customizable Transaction Characteristics can be selected for use for Participants, User-Defined Event Types, Statement Groups, Payment Methods, or Countries, and can be configured to use the Automatic ID Generation feature. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, Child Data Item, Cross-Reference Item, or Adjustments on Tab Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items, Child Data Items, and Adjustments on Tab: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. When you want to create a Transaction Characteristic Item with a linked Adjustment, you must first submit a POST Request to create the Transaction Characteristic Item. You must then submit a PUT or PATCH Request to update the Transaction Characteristic Item with the Adjustment information. Note: When you submit a request to add or delete Child or Cross-reference Items, the request is not idempotent. When you specify an _action value for a Child or Cross-reference Item, the action supercedes the behaviour indicated by the HTTP verb for the Child or Cross-reference Item. In this scenario, the request is similar to an HTTP PATCH request. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ### Update a Transaction Characteristic Item - [PATCH /api/data/userX/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristics/patch-data-userx-guid.md): Update the data for a specific Transaction Characteristic Item. The 20 Transaction Characteristics (User1 through User20) that allow you to customize your Alliant system using the business terms with which you are familiar, and to define as much, or as little, information about a Transaction Characteristic as you require. Each user-customizable Transaction Characteristic can be customized by specifying a name (such as Products, Languages, Distributors, and so forth), assigning Admin Classes, configuring User-Defined Tabs, and adding User-Defined Fields, Adjustments, Data Queries, and Web Pages to the UD Tabs. You can then create the Transaction Characteristic Items that are used throughout your Alliant system. User-customizable Transaction Characteristics can be selected for use for Participants, User-Defined Event Types, Statement Groups, Payment Methods, or Countries, and can be configured to use the Automatic ID Generation feature. The request body that you submit should include all of the properties that you want to update. When you want to update a UD Field Lookup Item, Child Data Item, Cross-Reference Item, or Adjustments on Tab Item, you must specify a value for the _action subproperty. The following actions are available for UD Field Lookup Items, Child Data Items, and Adjustments on Tab: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. When you want to create a Transaction Characteristic Item with a linked Adjustment, you must first submit a POST Request to create the Transaction Characteristic Item. You must then submit a PUT or PATCH Request to update the Transaction Characteristic Item with the Adjustment information. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ### Delete a Transaction Characteristic Item - [DELETE /api/data/userX/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristics/delete-data-userx-guid.md): Delete a specific Transaction Characteristic Item. The 20 Transaction Characteristics (User1 through User20) that allow you to customize your Alliant system using the business terms with which you are familiar, and to define as much, or as little, information about a Transaction Characteristic as you require. Each user-customizable Transaction Characteristic can be customized by specifying a name (such as Products, Languages, Distributors, and so forth), assigning Admin Classes, configuring User-Defined Tabs, and adding User-Defined Fields, Adjustments, Data Queries, and Web Pages to the UD Tabs. You can then create the Transaction Characteristic Items that are used throughout your Alliant system. User-customizable Transaction Characteristics can be selected for use for Participants, User-Defined Event Types, Statement Groups, Payment Methods, or Countries, and can be configured to use the Automatic ID Generation feature. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ### Copy an existing Transaction Characteristic Item - [PUT /api/data/userXs/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristics/put-data-userxs-copy.md): Copy a specific Transaction Characteristic Item. > This PUT does not behave as a standard HTTP PUT and is _NOT_ idempotent. This PUT will create a new resource. Its behaviour is that of a POST and it should be treated as such. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ### Execute the Resolve Tool for an existing Transaction Characteristic Item - [PUT /api/data/userXs/resolve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristics/put-data-userxs-resolve.md): Resolve a specific Transaction Characteristic Item. Note: You must enable at least one of the Resolve Types. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ## Transaction Characteristic Lists ### Get multiple Transaction Characteristic Lists - [GET /api/data/userXListHeaders](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-lists/get-data-userxlistheaders.md): Read the data for multiple Transaction Characteristic Lists. A Transaction Characteristic List identifies a dynamic set of Transaction Characteristic Items and Transaction Characteristic Lists (for example, a Product List that includes a set of Product Items and other Product Lists). You create a Transaction Characteristic List by including and excluding specific Transaction Characteristic Items and Transaction Characteristic Lists. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Create a Transaction Characteristic List - [POST /api/data/userXListHeaders](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-lists/post-data-userxlistheaders.md): Create a Transaction Characteristic List. A Transaction Characteristic List identifies a dynamic set of Transaction Characteristic Items and Transaction Characteristic Lists (for example, a Product List that includes a set of Product Items and other Product Lists). You create a Transaction Characteristic List by including and excluding specific Transaction Characteristic Items and Transaction Characteristic Lists. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). If getOrCreateWithHashCategory query parameter is added then this endpoint gets an existing User-Defined Transaction Characteristic List or creates a new Transaction Characteristic List. If an existing User-Defined Transaction Characteristic List matches List Definition specified in a request (ListDetails and ListXrefs) for a Hash Category specified as a value of getOrCreateWithHashCategory query parameter then this Transaction Characteristic List is returned in a response. In this case, the successful response is indicated with a 200 status code. If no Transaction Characteristic List matches List Definition and Hash Category, then a new Transaction Characteristic List is created. In this case, the successful response is indicated with a 201 status code. Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Get a single Transaction Characteristic List - [GET /api/data/userXListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-lists/get-data-userxlistheaders-guid.md): Read the data for a specific Transaction Characteristic List. A Transaction Characteristic List identifies a dynamic set of Transaction Characteristic Items and Transaction Characteristic Lists (for example, a Product List that includes a set of Product Items and other Product Lists). You create a Transaction Characteristic List by including and excluding specific Transaction Characteristic Items and Transaction Characteristic Lists. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Update a Transaction Characteristic List - [PUT /api/data/userXListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-lists/put-data-userxlistheaders-guid.md): Update the data for a specific Transaction Characteristic List. A Transaction Characteristic List identifies a dynamic set of Transaction Characteristic Items and Transaction Characteristic Lists (for example, a Product List that includes a set of Product Items and other Product Lists). You create a Transaction Characteristic List by including and excluding specific Transaction Characteristic Items and Transaction Characteristic Lists. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item or Cross-Reference Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. Note: When you submit a request to add or delete Child or Cross-reference Items, the request is not idempotent. When you specify an _action value for a Child or Cross-reference Item, the action supercedes the behaviour indicated by the HTTP verb for the Child or Cross-reference Item. In this scenario, the request is similar to an HTTP PATCH request. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Update a Transaction Characteristic List - [PATCH /api/data/userXListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-lists/patch-data-userxlistheaders-guid.md): Update the data for a specific Transaction Characteristic List. A Transaction Characteristic List identifies a dynamic set of Transaction Characteristic Items and Transaction Characteristic Lists (for example, a Product List that includes a set of Product Items and other Product Lists). You create a Transaction Characteristic List by including and excluding specific Transaction Characteristic Items and Transaction Characteristic Lists. The request body that you submit should include all of the properties that you want to update. When you want to update a Child Data Item or Cross-Reference Item, you must specify a value for the _action subproperty. The following actions are available for Child Data Items: · add – specify this action when you want to add a new Item. · delete – specify this action when you want to delete an Item. · update – specify this action when you want to update data for an Item. The following actions are available for Cross-Reference Items: · add – specify this action when you want to add a Cross-Reference Item. · update – specify this action when you want to update data for a Cross-Reference Item. Note: As well as partial updates, it is possible to use an _action to add or delete records. When there is an _action included within the body, then this action supercedes the behaviour indicated by the HTTP verb. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Delete a Transaction Characteristic List - [DELETE /api/data/userXListHeaders/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-lists/delete-data-userxlistheaders-guid.md): Delete a specific Transaction Characteristic List. A Transaction Characteristic List identifies a dynamic set of Transaction Characteristic Items and Transaction Characteristic Lists (for example, a Product List that includes a set of Product Items and other Product Lists). You create a Transaction Characteristic List by including and excluding specific Transaction Characteristic Items and Transaction Characteristic Lists. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). Note: The List Details that you access in Alliant API reflect the List definition and not the resolved set of Items and Lists ultimately defined by the List. ### Copy an existing Transaction Characteristic List - [PUT /api/data/userXListHeaders/copy/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-lists/put-data-userxlistheaders-copy-guid.md): Copy a specific Transaction Characteristic List. > This PUT does not behave as a standard HTTP PUT and is _NOT_ idempotent. This PUT will create a new resource. Its behaviour is that of a POST and it should be treated as such. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ### Execute the Resolve Tool for an existing Transaction Characteristic List - [PUT /api/data/userXListHeaders/resolve/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-lists/put-data-userxlistheaders-resolve-guid.md): Execute the Resolve Tool on an existing Transaction Characteristic List. Note: This endpoint description applies to all 20 user-customizible Transaction Characteristics (User1-User20). Make sure that you replace UserX or udKeyX with the appropriate Transaction Characteristic value in the endpoint URI and property names (for example, User1 or udKey1). ## Miscellaneous Endpoints ### Get multiple Access Levels - [GET /api/data/accessLevels](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-accesslevels.md): Read the data for multiple Access Level Items. Alliant Access Levels define the level of access an Alliant User has to certain data (for example, Normal or Supervisor). ### Get a single Access Level - [GET /api/data/accessLevels/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-accesslevels-guid.md): Read the data for a single Access Level Item. Alliant Access Levels define the level of access an Alliant User has to certain data (for example, Normal or Supervisor). ### Get multiple Access Types - [GET /api/data/accessTypes](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-accesstypes.md): Read the data for multiple Access Type Items. Alliant Access Types define the type of access an Alliant User has to certain data (for example, View or Modify). ### Get a single Access Type - [GET /api/data/accessTypes/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-accesstypes-guid.md): Read the data for a single Access Type Item. Alliant Access Types define the type of access an Alliant User has to certain data (for example, View or Modify). ### Get multiple AddressFormats - [GET /api/data/addressFormats](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-addressformats.md): Read the data for multiple AddressFormats. ### Get a single AddressFormat - [GET /api/data/addressFormats/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-addressformat-guid.md): Read the data for a specific AddressFormat. ### Get multiple AddressTypes - [GET /api/data/addressTypes](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-addresstypes.md): Read the data for multiple AddressTypes. ### Get a single AddressType - [GET /api/data/addressTypes/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-addresstype-guid.md): Read the data for a specific AddressType. ### Get multiple ApplErrorMessageLogs - [GET /api/data/applErrorMessageLogs](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-applerrormessagelogs.md): Read the data for multiple ApplErrorMessageLogs. ### Get a single ApplErrorMessageLog - [GET /api/data/applErrorMessageLogs/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-applerrormessagelog-guid.md): Read the data for a specific ApplErrorMessageLog. ### Get multiple Authentication Methods - [GET /api/data/authenticationMethods](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-authenticationmethods.md): Read the data for multiple Authentication Method Items. ### Get a single Authentication Method - [GET /api/data/authenticationMethods/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-authenticationmethods-guid.md): Read the data for a single Authentication Method Item. ### Get multiple Authentication Types - [GET /api/data/authenticationTypes](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-authenticationtypes.md): Read the data for multiple Authentication Type Items. ### Get a single Authentication Type - [GET /api/data/authenticationTypes/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-authenticationtypes-guid.md): Read the data for a single Authentication Type Item. ### Get multiple Certificate Types - [GET /api/data/certificateTypes](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-certificatetypes.md): Read the data for multiple Certificate Type Items. ### Get a single Certificate Type - [GET /api/data/certificateTypes/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-certificatetypes-guid.md): Read the data for a single Certificate Type Item. ### Get multiple ContractByReferencedContacts - [GET /api/data/contractByReferencedContacts](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-contractbyreferencedcontacts.md): Read the data for multiple ContractByReferencedContacts. ### Get multiple Countries - [GET /api/data/countries](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-countrys.md): Read the data for multiple Countries. ### Get a single Country - [GET /api/data/countries/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-country-guid.md): Read the data for a specific Country. ### Get multiple EmailTypes - [GET /api/data/emailTypes](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-emailtypes.md): Read the data for multiple EmailTypes. ### Get a single EmailType - [GET /api/data/emailTypes/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-emailtype-guid.md): Read the data for a specific EmailType. ### Get multiple File System Locations - [GET /api/data/fileSystemLocations](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-filesystemlocations.md): Read the data for multiple File System Location Items. ### Get a single File System Location - [GET /api/data/fileSystemLocations/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-filesystemlocations-guid.md): Read the data for a single File System Location Item. ### Get multiple Periods - [GET /api/data/periods](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-periods.md): Read the data for multiple Periods. ### Get a single Period - [GET /api/data/periods/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-period-guid.md): Read the data for a specific Period. ### Get multiple States - [GET /api/data/states](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-states.md): Read the data for multiple States. ### Get a single State - [GET /api/data/states/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-state-guid.md): Read the data for a specific State. ### Get multiple SystemErrorMessageLogs - [GET /api/data/systemErrorMessageLogs](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-systemerrormessagelogs.md): Read the data for multiple SystemErrorMessageLogs. ### Get a single SystemErrorMessageLog - [GET /api/data/systemErrorMessageLogs/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-systemerrormessagelog-guid.md): Read the data for a specific SystemErrorMessageLog. ### Get multiple UDFs - [GET /api/data/udfs](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-udfs.md): Read the data for multiple UDFs. ### Get a single UDF - [GET /api/data/udfs/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-udf-guid.md): Read the data for a specific UDF. ### Get multiple WebServiceLogs - [GET /api/data/webServiceLogs](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-webservicelogs.md): Read the data for multiple WebServiceLogs. ### Get a single WebServiceLog - [GET /api/data/webServiceLogs/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-webservicelog-guid.md): Read the data for a specific WebServiceLog. ### Get multiple Transfer Types - [GET /api/data/transferTypes](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-transfertypes.md): Read the data for multiple Transfer Type Items. ### Get a single Transfer Type - [GET /api/data/transferTypes/{guid}](https://alliant.redocly.app/alliant-api-definition-release/miscellaneous-endpoints/get-data-transfertypes-guid.md): Read the data for a single Transfer Type Item. ## User API Tokens User API Tokens are Bearer tokens associated with an Alliant User that allow your applications to authenticate with the Alliant API without using username and password credentials. You can create, read, and delete User API Tokens using these endpoints. ### Get User API Tokens - [GET /api/data/userApiTokens](https://alliant.redocly.app/alliant-api-definition-release/user-api-tokens/get-data-userapitokens.md): Read User API Tokens for the authenticated user. ### Create a new User API Token - [POST /api/data/userApiTokens](https://alliant.redocly.app/alliant-api-definition-release/user-api-tokens/post-data-userapitokens.md): Create a new User API Token for the authenticated user. User API Tokens are Bearer tokens that allow your applications to authenticate with the Alliant API without using username and password credentials. Tokens can optionally be set to expire on a specific date, or left with no expiration. Important: The token value is returned only in the response to a successful Create (POST) request. Store the token value securely immediately after creation, as it cannot be retrieved again. To authenticate using a User API Token, pass the token value in the HTTP Authorization request header using the Bearer scheme. Only users with permissions to "Access the User API Tokens window" are allowed to create new User API Tokens. ### Get a single User API Token - [GET /api/data/userApiTokens/{guid}](https://alliant.redocly.app/alliant-api-definition-release/user-api-tokens/get-data-userapitokens-guid.md): Read the data for a specific User API Token. User API Tokens are Bearer tokens that allow your applications to authenticate with the Alliant API without using username and password credentials. Note: The token value is not returned by this endpoint. The token value is only available in the response to the Create (POST) request. ### Delete a User API Token - [DELETE /api/data/userApiTokens/{guid}](https://alliant.redocly.app/alliant-api-definition-release/user-api-tokens/delete-data-userapitokens-guid.md): Delete a specific User API Token. Once deleted, the token can no longer be used to authenticate with the Alliant API. ## Transaction Import "You can use Alliant API to Import Transaction data to the Alliant system by sending requests with pages of Transaction data to the Import Transaction endpoints. When all of the Transactions in an Import Transaction Batch have been sent, you use the `Submit` parameter to submit the Import Batch Job for processing by the Import Batch Service. When you want to Import Transaction data into the Alliant system, you must first create the Import Transaction Batch using the HTTP POST **api/Import/Transactions/Batch** endpoint. You can send the first page of Transaction data with the POST endpoint. When the Import Transaction Batch includes only a single page of Transaction data that is included in the POST request, you can create the Import Transaction Batch and submit it for processing in the same request using the `Submit` parameter. When the Import Transaction Batch includes multiple pages of Transaction data, you send each page of Transactions and submit the batch for processing using the HTTP PATCH **api/Import/Transactions/Batch/{batchId}** endpoint after the Import Transaction Batch is created using the HTTP POST endpoint. You can read the data for an Import Transaction Batch using the HTTP GET **api/Import/Transactions/Batch/{batchId}** endpoint. When you want to clear the Transactions from an Import Transaction Batch, you can use the HTTP POST **api/Import/Transactions/Batch/{batchId}/clear**." ### Create an Import Transaction Batch - [POST /api/import/transactions/batch](https://alliant.redocly.app/alliant-api-definition-release/transaction-import/post-import-transactions-batch.md): When you want to Import Transaction data into the Alliant system, you must first issue this endpoint to create the Import Transaction Batch. The POST Request Body must include the Import File Name, the page size (the number of Transactions to be submitted per batch), and the total number of Transactions. When a batch of Transaction data is included in the initial POST Request, the POST Request Body also includes a Description for the batch, a page number for the batch, and an array of Transaction data. When the entire batch of Transactions is contained within the POST request, you can use the Submit parameter to submit the job for processing in the same request. The request response includes the batchId value used to submit subsequent pages of Import Transaction data for the Batch Job. ### Submit Transactions for an Import Transaction Batch - [PATCH /api/import/transactions/batch/{batchID}](https://alliant.redocly.app/alliant-api-definition-release/transaction-import/patch-import-transactions-batch-batchid.md): Once the Import Transaction Batch is created using the HTTP POST endpoint, you submit each page of Transactions using this endpoint. When you are submitting a page of Transaction data, the PATCH Request Body must include the Page Number for the Transactions and an array of Transaction data.  When you are submitting the final page of Transactions, you can also include the Submit parameter to submit the batch for processing. When you are not submitting a page of Transaction data but only submitting the batch for processing, no Request Body data is required and you must include the Submit parameter to submit the batch for processing. Note: You cannot submit pages of Transactions to an Import Transaction Batch that has been cleared. When you clear an Import Transaction Batch, the Transaction data is removed from the Database. However, you must create a new Import Transaction Batch to submit new pages of Transactions. ### Read Import Transaction Batch Data - [GET /api/import/transactions/batch/{batchID}](https://alliant.redocly.app/alliant-api-definition-release/transaction-import/get-import-transactions-batch-batchid.md): Read the data for an Import Transaction Batch. ### Clear the Transactions from an Import Transaction Batch - [POST /api/import/transactions/batch/{batchID}/clear](https://alliant.redocly.app/alliant-api-definition-release/transaction-import/post-import-transactions-batch-batchid-clear.md): Clear the Transactions from an Import Transaction Batch. This endpoint removes the Transactions in the Import Transaction Batch from the database. You should use this Tool when Transactions were mistakenly added in an Import Transaction Batch or when an error occurs while processing the Import job, as necessary. You can no longer use an Import Transaction Batch once it is cleared. When you want to resubmit any cleared Transactions, you must create a new Import Transaction Batch. Note: You cannot submit pages of Transactions to an Import Transaction Batch that has been cleared. When you clear an Import Transaction Batch, the Transaction data is removed from the Database. However, you must create a new Import Transaction Batch to submit new pages of Transactions. ### Get multiple Import Transaction Batches - [GET /api/data/stagingAPIBatch](https://alliant.redocly.app/alliant-api-definition-release/transaction-import/get-data-stagingapibatch.md): Read the data for multiple Import Transaction Batches. You can use the parameters available for multiple-Item endpoints to filter the results based on the Batch ID (returned as the sid parameter) or the Job Queue Globally Unique Identifier (returned as the jobQueueGUID parameter).  For example, when you want to Read the information for an API Transaction Import Batch with the batchId value of 1, the endpoint can be as follows: {Base Address}/api/data/stagingAPIBatch?$Filter=sid eq 1 ### Get a single Import Transaction Batch - [GET /api/data/stagingAPIBatch/{guid}](https://alliant.redocly.app/alliant-api-definition-release/transaction-import/get-data-stagingapibatch-guid.md): Read the data for a single Import Transaction Batch. ### Get multiple Job Queue Summaries - [GET /api/data/jobQueueSummaries](https://alliant.redocly.app/alliant-api-definition-release/transaction-import/get-data-jobqueuesummaries.md): Read the Job Queue Information for an API Transaction Import Batch Job. You can use the parameters available for multiple-Item endpoints to filter the results based on the Job Queue Globally Unique Identifier (returned as the jobQueueGUID parameter when you read the data for an API Transaction Import Batch).  For example, when you want to Read the information for an API Transaction Import Batch with the jobQueueGUID value of 51fe9515-0eb7-4ab9-90ed-847b867e3ba7, the endpoint can be as follows: {Base Address}/api/data/JobQueueSummaries?$filter=jobQueueGUID eq '51fe9515-0eb7-4ab9-90ed-847b867e3ba7' ### Get multiple Transmission History Entries - [GET /api/data/TransmissionHistories](https://alliant.redocly.app/alliant-api-definition-release/transaction-import/get-data-transmissionhistories.md): Read the Transmission History information for an API Transaction Import Batch Job. You can use the parameters available for multiple-Item endpoints to filter the results based on the System ID (SID) value for the apiBatchReference property, which corresponds to the batchID value for the API Transaction Import Batch.  For example, when you want to Read the Transmission History information for an API Transaction Import Batch Job with the System ID (SID) value of 1 for the apiBatchReference property, the endpoint can be as follows: {Base Address}/api/data/TransmissionHistories?$Filter=apiBatchReference.SID eq 1 Note: When you use Alliant API to submit an Import Transaction Batch and there are configuration issues that prevent the batch from being added to Import Transmission History, the batchID value for the Import Transaction Batch and the System ID (SID) value for the apiBatchReference property in Transmission History can get out of sync. When this occurs, use the Import Transaction Batch Clear endpoint to clear any batches that were submitted with the incorrect configuration.  The batchID value for subsequent Import Transaction Batches will correspond to the System ID (SID) value for the apiBatchReference property in Transmission History. ### Get multiple Transmission History Error Records - [GET /api/data/TransmissionHistoryErrors](https://alliant.redocly.app/alliant-api-definition-release/transaction-import/get-data-transmissionhistoryerrors.md): You can use the parameters available for multiple-Item endpoints to filter the results based on the System ID (SID) value for the apiBatchReference property, which corresponds to the batchID value for the API Transaction Import Batch.  For example, when you want to Read the Transmission History error information for an API Transaction Import Batch Job with the System ID (SID) value of 1 for the apiBatchReference property, the endpoint can be as follows: {Base Address}/api/data/TransmissionHistoryErrors?$Filter=apiBatchReference.SID eq 1 Note: When you use Alliant API to submit an Import Transaction Batch and there are configuration issues that prevent the batch from being added to Import Transmission History, the batchID value for the Import Transaction Batch and the System ID (SID) value for the apiBatchReference property in Transmission History can get out of sync. When this occurs, use the Import Transaction Batch Clear endpoint to clear any batches that were submitted with the incorrect configuration.  The batchID value for subsequent Import Transaction Batches will correspond to the System ID (SID) value for the apiBatchReference property in Transmission History Errors. ## Contract Import "You can use Alliant API to Import Contract data to the Alliant system by sending requests with pages of Contract data to the Import Contract endpoints. When all of the Contracts in an Import Contract Batch have been sent, you use the `Submit` parameter to submit the Import Batch Job for processing by the Import Batch Service. When you want to Import Contract data into the Alliant system, you must first create the Import Contract Batch using the HTTP POST **api/Import/Contracts/Batch** endpoint. You can send the first page of Contract data with the POST endpoint. When the Import Contract Batch includes only a single page of Contract data that is included in the POST request, you can create the Import Contract Batch and submit it for processing in the same request using the `Submit` parameter. When the Import Contract Batch includes multiple pages of Contract data, you send each page of Contracts and submit the batch for processing using the HTTP PATCH **api/Import/Contracts/Batch/{batchId}** endpoint after the Import Contract Batch is created using the HTTP POST endpoint. You can read the data for an Import Contract Batch using the HTTP GET **api/Import/Contracts/Batch/{batchId}** endpoint. When you want to clear the Contracts from an Import Contract Batch, you can use the HTTP POST **api/Import/Contracts/Batch/{batchId}/clear**." ### Create an Import Contract Batch - [POST /api/import/contracts/batch](https://alliant.redocly.app/alliant-api-definition-release/contract-import/post-import-contracts-batch.md): When you want to Import Contract data into the Alliant system, you must first issue this endpoint to create the Import Contract Batch. The POST Request Body must include the Import File Name, the page size (the number of Contracts to be submitted per batch), and the total number of Contracts. When a batch of Contract data is included in the initial POST Request, the POST Request Body also includes a Description for the batch, a page number for the batch, and an array of Contract data. When the entire batch of Contracts is contained within the POST request, you can use the Submit parameter to submit the job for processing in the same request. The request response includes the batchId value used to submit subsequent pages of Import Contract data for the Batch Job. ### Submit Contracts for an Import Contract Batch - [PATCH /api/import/contracts/batch/{batchID}](https://alliant.redocly.app/alliant-api-definition-release/contract-import/patch-import-contracts-batch-batchid.md): Once the Import Contract Batch is created using the HTTP POST endpoint, you submit each page of Contracts using this endpoint. When you are submitting a page of Contract data, the PATCH Request Body must include the Page Number for the Contracts and an array of Contract data.  When you are submitting the final page of Contracts, you can also include the Submit parameter to submit the batch for processing. When you are not submitting a page of Contract data but only submitting the batch for processing, no Request Body data is required and you must include the Submit parameter to submit the batch for processing. Note: You cannot submit pages of Contracts to an Import Contract Batch that has been cleared. When you clear an Import Contract Batch, the Contract data is removed from the Database. However, you must create a new Import Contract Batch to submit new pages of Contracts. ### Read Import Contract Batch Data - [GET /api/import/contracts/batch/{batchID}](https://alliant.redocly.app/alliant-api-definition-release/contract-import/get-import-contracts-batch-batchid.md): Read the data for an Import Contract Batch. ## Contact Import You can use Alliant API to Import Contact data to the Alliant system by sending requests with pages of Contact data to the Import Contact endpoints. When all of the Contacts in an Import Contact Batch have been sent, you use the `Submit` parameter to submit the Import Batch Job for processing by the Import Batch Service. When you want to Import Contact data into the Alliant system, you must first create the Import Contact Batch using the HTTP POST **api/Import/Contacts/Batch** endpoint. You can send the first page of Contact data with the POST endpoint. When the Import Contact Batch includes only a single page of Contact data that is included in the POST request, you can create the Import Contact Batch and submit it for processing in the same request using the `Submit` parameter. When the Import Contact Batch includes multiple pages of Contact data, you send each page of Contacts and submit the batch for processing using the HTTP PATCH **api/Import/Contacts/Batch/{batchId}** endpoint after the Import Contact Batch is created using the HTTP POST endpoint. You can read the data for an Import Contact Batch using the HTTP GET **api/Import/Contacts/Batch/{batchId}** endpoint. When you want to clear the Contacts from an Import Contact Batch, you can use the HTTP POST **api/Import/Contacts/Batch/{batchId}/clear**. ### Create an Import Contact Batch - [POST /api/import/contacts/batch](https://alliant.redocly.app/alliant-api-definition-release/contact-import/post-import-contacts-batch.md): When you want to Import Contact data into the Alliant system, you must first issue this endpoint to create the Import Contact Batch. The POST Request Body must include the Import File Name, the page size (the number of Contacts to be submitted per batch), and the total number of Contacts. When a batch of Contact data is included in the initial POST Request, the POST Request Body also includes a Description for the batch, a page number for the batch, and an array of Contact data. When the entire batch of Contacts is contained within the POST request, you can use the Submit parameter to submit the job for processing in the same request. The request response includes the batchId value used to submit subsequent pages of Import Contact data for the Batch Job. ### Submit Contacts for an Import Contact Batch - [PATCH /api/import/contacts/batch/{batchID}](https://alliant.redocly.app/alliant-api-definition-release/contact-import/patch-import-contacts-batch-batchid.md): Once the Import Contact Batch is created using the HTTP POST endpoint, you submit each page of Contacts using this endpoint. When you are submitting a page of Contact data, the PATCH Request Body must include the Page Number for the Contacts and an array of Contact data.  When you are submitting the final page of Contacts, you can also include the Submit parameter to submit the batch for processing. When you are not submitting a page of Contact data but only submitting the batch for processing, no Request Body data is required and you must include the Submit parameter to submit the batch for processing. Note: You cannot submit pages of Contacts to an Import Contact Batch that has been cleared. When you clear an Import Contact Batch, the Contact data is removed from the Database. However, you must create a new Import Contact Batch to submit new pages of Contacts. ### Read Import Contact Batch Data - [GET /api/import/contacts/batch/{batchID}](https://alliant.redocly.app/alliant-api-definition-release/contact-import/get-import-contacts-batch-batchid.md): Read the data for an Import Contact Batch. ## Transaction Characteristic Import You can use Alliant API to Import Transaction Characteristics to the Alliant system by sending requests with pages of Transaction Characteristics to the Import UserX endpoints. When all of the Transaction Characteristics in an Import UserX Batch have been sent, you use the `Submit` parameter to submit the Import Batch Job for processing by the Import Batch Service. When you want to Import Transaction Characteristics into the Alliant system, you must first create the Import UserX Batch using the HTTP POST **api/Import/UserXs/Batch** endpoint. You can send the first page of Transaction Characteristics with the POST endpoint. When the Import UserX Batch includes only a single page of Transaction Characteristics that is included in the POST request, you can create the Import UserX Batch and submit it for processing in the same request using the `Submit` parameter. When the Import UserX Batch includes multiple pages of Transaction Characteristics, you send each page of Transaction Characteristics and submit the batch for processing using the HTTP PATCH **api/Import/UserXs/Batch/{batchId}** endpoint after the Import UserX Batch is created using the HTTP POST endpoint. You can read the data for an Import UserX Batch using the HTTP GET **api/Import/UserXs/Batch/{batchId}** endpoint. When you want to clear the Transaction Characteristics from an Import UserX Batch, you can use the HTTP POST **api/Import/UserXs/Batch/{batchId}/clear**. ### Create an Import UserX Batch - [POST /api/import/userXs/batch](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-import/post-import-userxs-batch.md): When you want to Import UserX data into the Alliant system, you must first issue this endpoint to create the Import UserX Batch. The POST Request Body must include the Import File Name, the page size (the number of UserXs to be submitted per batch), and the total number of UserXs. When a batch of UserX data is included in the initial POST Request, the POST Request Body also includes a Description for the batch, a page number for the batch, and an array of UserX data. When the entire batch of UserXs is contained within the POST request, you can use the Submit parameter to submit the job for processing in the same request. The request response includes the batchId value used to submit subsequent pages of Import UserX data for the Batch Job. ### Submit UserXs for an Import UserX Batch - [PATCH /api/import/userXs/batch/{batchID}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-import/patch-import-userxs-batch-batchid.md): Once the Import UserX Batch is created using the HTTP POST endpoint, you submit each page of UserXs using this endpoint. When you are submitting a page of UserX data, the PATCH Request Body must include the Page Number for the UserXs and an array of UserX data.  When you are submitting the final page of UserXs, you can also include the Submit parameter to submit the batch for processing. When you are not submitting a page of UserX data but only submitting the batch for processing, no Request Body data is required and you must include the Submit parameter to submit the batch for processing. Note: You cannot submit pages of UserXs to an Import UserX Batch that has been cleared. When you clear an Import UserX Batch, the UserX data is removed from the Database. However, you must create a new Import UserX Batch to submit new pages of UserXs. ### Read Import UserX Batch Data - [GET /api/import/userXs/batch/{batchID}](https://alliant.redocly.app/alliant-api-definition-release/transaction-characteristic-import/get-import-userxs-batch-batchid.md): Read the data for an Import UserX Batch. ## Reset ### Reset cached Alliant metadata - [POST /api/metadata/reset](https://alliant.redocly.app/alliant-api-definition-release/reset/post-metadata-reset.md): Resets the cached Alliant metadata. This allows the Alliant metadata, such as User-Defined Fields, validation Rules, and so forth, to be refreshed and to be used in the next Alliant API request you make. Reset does not reset the Alliant metadata instantly. It allows all of the currently active requests to complete first.