Submission of Applications from third-party systems
xCAS API Documentation Ver 1.6, 28 June 2018
About API 2
Description 2
Interaction Overview 2
Authentication and authorization 3
Request Headers 5
Content-Type 5
JSON 5
URL Encoded Form 5
Authorization 5
Data structures 6
Draft Application 6
Draft Application response 10
Login form 10
Owner and Beneficiary 11
Attachments list 12
Application 13
Endpoints 16
Login 16
Ping 17
Create draft application 17
Get draft application 18
Get license 18
Attach documents 20
Get draft application attachments 20
Delete Document 21
Submit draft 21
Cancel draft 22
List changed application 23
Request license extension 24
List minerals 25
List Statuses 26
List document types 26
List license types 26
List contract term types 27
About the API for Application Submission
This document describes xCAS (previously called MCAS) system API for registering applications from other systems. The API intends to integrate government systems, allowing for example government to include license application forms on centralized e-governance or tax administration portals, for submission of applications eletronically to xCAS.
Description
Application registration API represents web services with token security system used to initiate application registration in xCAS from different systems. All communications with this API happens through HTTP/HTTPS protocol using JSON data structures. Application data submitted to xCAS is validated and either rejected with specific error message or accepted and new application code returned. Submitted data should contain external (to xCAS) identificator which will be used as reference for status update notifications.
Applications registered in this way goes through normal configured process of application life cycle in xCAS. Beside registration functions API also contains some helper functions which may be used by different client systems to provide their users with easy to use UI.
Interaction Overview
Below is overview of the process of interactions between two systems expressed as sequence diagram. Client App represents client application which uses xCAS web services. In the following diagram names of the operations are not REST endpoint names, but instead more readable names are used.
1: Client application calls xCAS with application payload and registers draft application. Beside application data client also should provide its own unique ID for the application which will be stored by xCAS.
2: xCAS validates data and replies with its own ID so that client can associate its own ID and xCAS generated ID.
3: Client can attach documents to the draft applications. This can be done many times while application is in draft state.
4: Once finished collecting documents, client application issues finalization message which sends application to next stage – registration stage in this case. Since this moment application goes through preconfigured stages in xCAS – xCAS users check applications and move to next stages as defined by their workflow.
5: On every change of status of application, xCAS can notify client application if it configures callback URL. Message delivered to client application contains ID of application. status change date, new status name and description or comment.
Authentication and authorization
To access the API for each client application special user should be registered in xCAS with password and permissions to call API. This can be done by xCAS administrator using corresponding UI. Once user is registered and permissions are given to call API corresponding username and password can be used by client application to obtain authorization token.
Each call to API endpoints should contain valid authorization token otherwise API call will result in HTTP response with status code 401. Token should be set in the ‘Authorization’ header with ‘Bearer’ prefix. Format is Authorization : Bearer . Below is example of the HTTP header:
| Authorization : Bearer cn389ncoiwuencr79fweclknfrn3n5l2nms |
Tokens are issued by xCAS server and they are valid for predefined time period. After that time they expire and are not accepted. In such case 401 status code is returned by the system and client is required to reauthenticate with the system – obtain new token.
Note: In this version we do not enable ‘nonce’ feature. In next versions this feature will be enabled. Nonce is random number (formatted as text: ) which is used only once. It is generated by xCAS and sent to client with 401 error only once. Client uses it to hash username/password. Since nonce is used only once, hijacked password cannot be used for replay attack.
Below is sequence diagram showing interactions between client and server during authentication:
1: Client application authenticates to xCAS using username and password hash sent in request.
2: xCAS checks username, password, user state and permissions and issues authorization token. Token is returned as response to client application which stores it in secure location.
3: Client applications includes token in all API calls. xCAS checks token digital signature integrity, validity and allows requested operation execution.
4: xCAS returns requested operation response to client application.
Request Headers
Each call to API requires different set of headers to be present. Below we list all possible request headers by names. They will be referenced from Endpoints section by these names:
Content-Type
This specifies what type of content is being submitted to xCAS. Below is list of possible values for Content-Type header:
JSON
Specifies that payload is JSON data:
| Content-Type : application/json |
This is used in almost all requests when data is submitted to server.
URL Encoded Form
Specifies form encoding style:
| Content-Type : application/x-www-form-urlencoded |
Authorization
Contains token data prefixed with Bearer. Example:
| Authorization : Bearer cn389ncoiwuencr79fweclknfrn3n5l2nms |
Data structures
Below is list of submitted or returned data structures, referenced from Endpoints section:
Draft Application
Represents data required for draft application registration. This structure is submitted when client needs to create draft application:
| {
“client_id”: [string], “type_id”: [number], “minerals”: [array], “area”: [number], “mineral_value”:[number], “mineral_value_currency”:[string] “owner”:{ “tax_id”: [string], “name”: [string], “individual”: [boolean], “first_name”: [string], “last_name”: [string], “country”: [string], “city”: [string], “email”: [string], “phone”: [string], “address”: [string], “post_code”: [string], }, “beneficiary”:{ “tax_id”: [string], “name”: [string], “individual”: [boolean], “first_name”: [string], “last_name”: [string], “country”: [string], “city”: [string], “email”: [string], “phone”: [string], “address”: [string], “post_code”: [string], }, “compliance_docs”:{ “mineral_analysys_certificates”:[ { “barcode”:[string], “company_name”: [string], “sample_collected”: [string], “company_address”: [string], “lab_ref”:[string], “company_code”:[string], “nature_sample”:[string], “source_sample”:[string], “examination_required”:[string], “method”:[string], “signature”:[string], “analyzed_by”:[string] } ], “mineral_valuation_certificate”:[ { “text”:[string], “product_desc”:[string], “total_weight_kgm”:[string], “consignee_name”:[string], “consignee_address”:[string], “consignee_country”:[string], “prepared_by_label”:[string], “prepared_by_value”:[string] } ], “contract_terms”:[ { “type_id”:[number], “value”:[number], “text”:[string] } ] } } |
client_id – unique ID inside client’s context.
type_id – unique ID of license type.
minerals – list of mineral names – string values.
area – optional sq. meters of area.
mineral_value – initial value of minerals.
mineral_value_currency – ISO code of the currency of minerals value.
owner – represents owner object and contains different fields for single permit owner. Not all fields are mandatory here. For individuals (individual = true) First name, last name and tax_id fields are mandatory. For non-individual owners (individual=false) name and tax_id fields are mandatory.
beneficiary – same as owner but different company should be specified. This field is optional.
compliance_docs – this contains fields for different compliance docs. For each there is an array of structure which represents the document fields. In this example we have two types of these docs as shown above. Currently fields here are not checked by strict rules but are justs stored in the system.
contract_terms – array of contract terms. Each contract term should contain type_id value obtained via /contractTermTypes endpoint. Also Value of contract term and optional text. Because contract_terms field is array of structures, you can submit several contract terms with application.
Example:
| {
“client_id”: 1234567, “type_id”: 128, “minerals”: [“silver”, “gold”, “copper”], “area”:15.88, “mineral_value”:167.89, “mineral_value_currency”:”USD”, “owner”:{ “tax_id”: 1199695765, “name”: “Some company name, “individual”: false, “first_name”: null, “last_name”: null, “country”: “Georgia”, “city”: “Tbilisi”, “email”: “company@gmail.com”, “phone”: “+995 593 591 500”, “address”: “Qindzmarauli str 43, “post_code”: “0121”, }, “beneficiary”:{ “tax_id”: 1199695766, “name”: “Some other company name, “individual”: false, “first_name”: null, “last_name”: null, “country”: “Georgia”, “city”: “Tbilisi”, “email”: “company2@gmail.com”, “phone”: “+995 593 591 501”, “address”: “Qindzmarauli str 47, “post_code”: “0122”, }, “compliance_docs”:{ “mineral_analysys_certificates”:[ { “barcode”:”123”, “company_name”: “abc”, “sample_collected”: “abc”, “company_address”: “abc”, “lab_ref”: ”123”, “company_code”: ”12345”, “nature_sample”: “abc”, “source_sample”: ”abc”, “examination_required”: “No”, “method”: “online”:, “signature”: “sig”, “analyzed_by”: “David” } ], “mineral_valuation_certificate”:[ { “text”:”abc”, “product_desc”:”abc”, “total_weight_kgm”:1234.23, “consignee_name”:”abc, “consignee_address”:”abc”, “consignee_country”:”Zambia”, “prepared_by_label”:”abc”, “prepared_by_value”:”123” } ], “contract_terms”:[ { “type_id”:45, “value”:112, “text”:”Not citizen” } ] } } |
Draft Application response
This structure is returned after application draft is successfully registered. It contains ID generated by xCAS, client_id value which was passed in in request and client application name for current user.
| {
“status”:”OK”, “mcas_id”:[integer], “client_id”:[string], “client_name”:[string] } |
Example:
| {
“status”:”OK”, “mcas_id”:123, “client_id”:”321”, “client_name”:”MOSES-test” } |
License response
Response of the getLicense endpoint contains everything
Login form
Login endpoint requires username and password to be submitted as JSON structure. Request should be POST and headers should contain Content-Type: application/json. Body of the request should be JSON with two fields.
username – string representing user name
password – string representing password (no hashing for test version)
This is example JSON body:
| {
“username”:”moses”, “password”:”secret” } |
Owner and Beneficiary
Owner object structure represent owner of the application. It might be individual (person) or company.
{
“tax_id”: [string],
“name”: [string],
“individual”: [boolean],
“first_name”: [string],
“last_name”: [string],
“country”: [string],
“city”: [string],
“email”: [string],
“phone”: [string],
“address”: [string],
“post_code”: [string]
}
tax_id – unique identification number or string assigned to taxpayer within country. Mandatory
name – company name. has value only when owner is company. Optional.
individual – boolean value defines whether owner is individual person. Mandatory.
first_name – string representing first name of individual. Optional.
last_name – string representing last name of individual. Optional.
country – country of owner. Optional.
city – city name of the owner. Optional
email – email of the owner. Optional.
phone – of the owner. Optional.
address – address of the owner. Optional
post_code – postal code of owner. Optional.
Same structure is used for beneficiary company, but it is usually optional field in application and permit.
Example:
| {
“tax_id”: “34553-d3”, “name”: “Some Company”, “individual”: false, “country”: “Zambia”, “city”: “Lusaka”, “email”: “sim@company.com”, “phone”: “8769887087”, “address”: “street 75”, “post_code”: “7821” } |
Attachments list
This is JSON structure containing metadata of the document. It does not contain actual bytes of the document.
| {
“status”:[string], “client_id”: [string], “attachments”:[ { “id”: [number], “client_id”:[string], “doc_date”:[string], “record_date”:[string], “original_name:[string], “type_name”:[string], “type_code”:[string] } ] } |
status – status of the operation: ‘OK’ or ‘ERROR’. In case of error, code and message will be specified instead of data fields.
client_id – unique ID of draft application inside client system. This value comes from request.
attachments – list of attachment objects. See fields description below:
id – xCAS database id of the record.
client_id – unique id of this attachment in the client system.
doc_date – date value that came with attachment in metadata. Optional
record_date – date when attachment was received and recorded
original_name – string representing original file name specified in when attachment was submitted
type_name – name of document type in xCAS.
type_code – code of document type
This example shows response with 2 attachments.
| {
“status”:”OK”, “client_id”: “123”, “attachments”:[ { “id”: 123, “client_id”:”345”, “doc_date”:”2017/07/14 11:11:11”, “record_date”:”2017/07/14 11:12:13”, “original_name:”some_file.pdf”, “type_name”:”Registration Form”, “type_code”:registration_form }, { “id”: 124, “client_id”:”567”, “doc_date”:null, “record_date”:”2017/07/15 18:17:16”, “original_name:”passport.jpeg”, “type_name”:”Passport scan”, “type_code”:”passport” } ] } |
Application
Full JSON structure of applications. It does not contains all of the fields that xCAS holds for application in its database, but instead only part required for remote registration applications. Also not all fields are mandatory here, so they will add in some cases when application goes to different stages. Here we list all possible fields this API might return when Get Application endpoint is requested:
| {
“mcas_id”: [number], “client_id”: [string], “draft_date”: [string], “application_date”: [string], “update_date”: [string], “license_date”: [string], “expiration_date”: [string], “status” : [string], “type” : [string], “minerals” : [array]. “owner” : { “tax_id”: [string], “name”: [string], “individual”: [boolean], “first_name”: [string], “last_name”: [string], “country”: [string], “city”: [string], “email”: [string], “phone”: [string], “address”: [string], “post_code”: [string] }, “beneficiary” : { “tax_id”: [string], “name”: [string], “individual”: [boolean], “first_name”: [string], “last_name”: [string], “country”: [string], “city”: [string], “email”: [string], “phone”: [string], “address”: [string], “post_code”: [string] }, “documents” : [objects] } |
mcas_id – Unique ID of record in xCAS.- long integer
client_id – Unique ID which was provided by client application when draft was created
draft_date – date when application draft was created. String in yyyy-MM-ddTHH:mm:ssZ format. Z at the end means Zulu time which is UTC time.
application_date – date when draft became real application – when finalized draft. Optional
update_date – date when application was last updated. Optional.
license_date – date when license was issued. Optional.
expiration_date – date when license expires. Only when application becomes license. Optional.
status – string representing name of status of the application.
type – string representing application type.
minerals – list of strings representing mineral names
owner – object representing owner. See Owner section for details.
documents – list of objects. See Document metadata section. Optional.
Example:
| {
“mcas_id”: 123, “client_id”: “2355”, “draft_date”: “2017-05-19T20:45:55Z”, “application_date”: “2017-05-29T20:45:55Z”, “update_date”: “2017-05-29T20:45:55Z”, “status” : “Registration”, “type” : “Export Permit”, “minerals” : [“Copper”, “Silver”],. “owner” : { “tax_id”: “34553-d3”, “name”: “Some Company”, “individual”: false, “country”: “Zambia”, “city”: “Lusaka”, “email”: “sim@company.com”, “phone”: “8769887087”, “address”: “street 75”, “post_code”: “7821” }, “beneficiary” : { “tax_id”: “34553-d3”, “name”: “Some Company”, “individual”: false, “country”: “Zambia”, “city”: “Lusaka”, “email”: “sim@company.com”, “phone”: “8769887087”, “address”: “street 75”, “post_code”: “7821” }, “documents” : [ { “id”:456, “name”:”Some document”, “type”:”contract”, }, { “id”:457, “name”:”filename.doc”, “type”:”letter”, } ] } |
This example shows application which has 123 ID in xCAS database and 2355 ID in client application. It has two minerals selected, and two documents attached. It is in Registration stage.
Small Application
Small structure of application used in lists to not overload results. It contaisn only most important fields:
Endpoints
Below is list of all endpoints of this API.
Login
Description: Authenticates client and returns token.
URL: /login
Method: POST
Headers: Content-Type: application/json
URL params: None
Data params:
| {
“username”: “moses”, “password”: “secret” } |
Success response:
code: 200
body: JSON structure containing authorization token
example:
| {
“username”: “moses”, “roles”: [ “ROLE_NTR” ], “access_token”: “eyJhbG…tzM”, “token_type”: “Bearer” } |
Failure response:
400 – if any required parameter is missing
401 – if password or username is incorrect
Each response contains also JSON containing details of failure.
Notes: See Login form and Authorization section for details
Ping
Description: Ping server to test connection. Returns time on the server.
URL: /ping
Method: GET
Headers; nothing
URL params: nothing
Data params: nothing
Success response:
Status code: 200
Body: JSON structure containing server date-time in yyyy/MM/dd HH:mm:ss format.
Example:
| {
“time”:”2017/05/01 23:59:59” } |
Failure response: No failures should happen
Notes: No authentication is required for this endpoint.
Create draft application
Description: Receives submitted data, validates it and creates draft application record. Data submitted should be JSON structure and should contain fields described in Draft Application section.
URL: /createDraft
Method: POST
Headers:
Authorization: Bearer
Content Type: application/json
URL Params: None
Data params:
Application JSON structure. See Data Structures: Draft Application.
Success Response:
201 – Draft created
Response contains JSON with new xCAS id. See Draft application Response
Failure Responses:
Code: 400 – If submitted data is missing any field or contains incorrect value.
Body: JSON describing issue.
Notes:
In this version there is no restriction of how long application can stay in draft state.
Get draft application
Description: Returns application data
URL: /getDraft
Method: POST
Headers:
Authorization: Bearer
Content Type: application/json
URL params: None
Data params:
JSON with client_id value. This value is ID unique in client system.
| {
“client_id”:”2″ } |
Success response:
Code: 200 – application JSON is returned
Failure response:
Code: 404 – application with specified ID not found.
Notes: won’t return application if it is not registered through this API
Get license
Description: Returns license data
URL: /getLicense
Method: POST
Headers:
Authorization: Bearer
Content Type: application/json
URL params: None
Data params:
JSON with mcas_id, client_id, or license_code value. Any of these 3 identification values should be specified:.
| {
“client_id”:”2123asd31”, “mcas_id”:231, “license_code”:”AE 123/18” } |
Success response:
Code: 200 – application JSON is returned. Example response:
| {
“mcas_id”: 14603, “client_id”: “123123, “draf_date”: “2009-01-30T00:00:00+04”, “application_date”: “2009-01-30T00:00:00+04”, “update_date”: “2018-06-25T20:43:20+04”, “status”: “Active License”, “type”: “Test Export Permit”, “minerals”: [ “Copper” ], “owner”: { “tax_id”: “087801709Y”, “name”: “Some company”, “individual”: false, “first_name”: null, “last_name”: null, “country”: “Georgia”, “city”: “Tbilisi”, “email”: “someone@somewhere.com”, “phone”: “20 29 41 41 / 21 21 51 14 “, “address”: “Rustaveli ave 21”, “post_code”: 0121 }, “renewal_no”: 2, “renewal_requested”: false, “last_renewal_accepted”: false, “last_renewal_comment”: “Rejecting because this is test”, “last_renewal_date”: “2018-06-25T16:43:20Z” } |
Failure response:
Code: 404 – application with specified ID not found.
Notes: mcas_id is a number, all other values submitted should be strings.
Attach documents
Description: Attaches new document to draft application. This request submits file and JSON at same time. Request should be POST regular form data. Just like HTML file is submitting form with different fields. In our case we have two fields. Both fields in the form contains different data. Document field contains file bytes and mime type. Data field contains json string with draft ID in client system to assign attachment to, attachment unique ID in the client system and document type id obtained through /documentTypes endpoint. As in case of applications, client IDs are used by client system to lookup records. xCAS assigns its own unique IDs to these records, but clients also might have their own ID to reference them. Document type id is one of the registered document types in xCAS. It can be letter, Declaration, contract or some kind of certificate.
URL: /attachDoc
Method: POST (submit form with fields)
Headers:
Authorization: Bearer
URL params: None
Form fields: Submitted form should have following 2 fields:
data=’{“client_id”:”123″,”doc_id”:”456″}’
where 123 is example client ID value and 456 is example client document ID. These IDs are unique in API client system. And second field value:
document=./some_file.pdf;type=application/pdf
Here some_file.pdf is example file name and type field is set to corresponding mime type.
Success response:
200 – document saved and attached to application
Response body contains JSON with ID of new document created.
Failure response:
404 – draft application with specified ID not found
Notes:
Get draft application attachments
Description: Returns list of attached document metadata for specific application.
URL: /listAttachments
Method: POST
Headers:
Authorization: Bearer
Content Type: application/json
URL params: None
Data params:
JSON with client_id value. This value is ID unique in client system.
| {
“client_id”:”2″ } |
Success response:
200 – documents list found and returned.
Response body contains JSON described in Attachments list section.
Failure response:
404 – document or application not found
Notes:
Won’t return documents that are not registered through this API.
Delete Document
Description: Removes attached document from application
URL: /deleteAttachment
Method: POST
Headers:
Authorization: Bearer
URL params: None
Data params: JSON with application client ID and attachment document id
| {
“client”:”123”, “doc_id”:”321” } |
Success response:
200 – document removed.
Failure response:
404 – document or application with specified ID not found.
Notes:
Submit draft
Description: Moves application from draft to registration/validation stage.
URL: /submitDraft
Method: POST
Headers:
Authorization: Bearer
Content Type: application/json
URL params: None
Data params: JSON with client_id of draft to submit:
| {
“client_id”:”123” } |
Success response:
code: 200 – application sent to next stage.
body: JSON structure:
{
“status”:”OK”,
“client_id”:”123”,
“application_code”:”APL-I-789”
}
Here status field indicates that request was successful. application_code is generated by xCAS and assigned to application.
Failure response:
400 – in case application is found but cannot be sent to next stage.
404 – application with ID not found
Notes:
Actually next stage is called Registration and this is where validation process starts.
Cancel draft
Description: Removes application from the system.
URL: /cancelDraft
Method: POST
Headers:
Authorization: Bearer
Content Type: application/json
URL params: None
Data params: JSON with client_id of draft to cancel:
| {
“client_id”:”123” } |
Success response:
code: 200 – application sent to next stage.
body: JSON structure:
{
“status”:”OK”,
}
Failure response:
400 – bad request – mainly missing client_id.
404 – application with ID not found
Notes:
Actually next stage is called Registration and this is where validation process starts.
List changed application
Description: Returns list of updated application/licenses since specific date.
URL: /getChanges
Method: POST
Headers:
Authorization: Bearer
Content Type: application/json
URL params: None
Data params: { “since_date”:”yyyy-MM-ddTHH:mm:ssX”}
Example JSON { “since_date”:”2017-12-31T23:59:59+04”}.
Success response:
200 – list of structures each containing reduced number of fields, only most important fields. These are: client_id, mcas_id, status, status_update_date. Also based on status of application, if present, these fields are added: application_code, license_code, start_date and based on renewal state there might be renewal_requested, renewal_request_date or last_renewal_accepted, last_renewal_comment, last_renewal_date.
Here is the example list (just 2 items) of changes returned by this endpoint:
| [
{ “client_id”: null, “mcas_id”: 13677, “status”: “Active License”, “status_update_date”: “2018-06-25T16:46:29Z”, “application_code”: “APL-I-334”, “license_code”: “AE 321/13”, “start_date”: “2012-06-21T20:00:00Z”, “renewal_requested”: true, “renewal_request_date”: “2018-06-25T16:46:33Z” }, { “client_id”: null, “mcas_id”: 14603, “status”: “Active License”, “status_update_date”: “2018-06-25T16:43:20Z”, “application_code”: “APL-I-357”, “license_code”: “AE 352/10”, “start_date”: “2009-12-01T20:00:00Z”, “renewal_requested”: false, “last_renewal_accepted”: true, “last_renewal_comment”: “All good”, “last_renewal_date”: “2018-06-25T16:43:20Z” } ] |
Failure response:
400 – if date is not specified
Notes:
Note that because list might have many elements, fields representing each application or license are reduced to minimum to reduce amount of transferred data. If full data is required for a license, use getLicense with client_id value to retrieve all data for single one.
Request license extension
Description:Requests license extension if possible. This puts license in extension requested state (renewal_requested=true) if it is not already in that state.
URL: /extend
Method: POST
Headers:
Authorization: Bearer
Content Type: application/json
URL params: None
Data params: JSON structure which contains either mcas_id or client_id or license ocde. You need to specify one of them, not 2 or 3 at same time.
| {
“mcas_id”:123, “client_id:”1234567”, “license_code”:”AE 18/2331″ } |
Any of these 3 fields can be specified.
Success response:
200 – json containing IDs of the license, status and message of the operation, if payment is required and amount of the required payment and currency. Here is the example response of successful extension request:
| {
“status”: “OK”, “id”: 11296, “client_id”: null, “license_code”: “AE 287/13”, “message”: “License extension was requested”, “payment_required”: true, “extension_request_date”: “2018-06-21T14:15:44+04”, “amount”: 10, “currency”: “USD”, “fee”: “10.0 USD for Renewal” } |
Failure response:
400 – missing fields
404 – license not found
422 – license is in a state when it cannot be extended
500 – Other errors
Notes:
In the submitted data note that mcas_id is a number, but two other fields are string type.
List minerals
Description: Returns list of all minerals in xCAS.
URL: /minerals
Method: GET
Headers:
Authorization: Bearer
URL params: None
Data params: None
Success response:
200 – list of strings returned
Failure response:
Notes:
Might be used for UI to let users select set of minerals when creating applications.
List Statuses
Description: Returns list of all statuses in xCAS.
URL: /statuses
Method: GET
Headers:
Authorization: Bearer
URL params: None
Data params: None
Success response:
200 – list of strings returned
Failure response:
Notes:
Might be used for UI to let users select set of statuses when creating applications.
List document types
Description: Returns list of all document types in xCAS.
URL: /documentTypes
Method: GET
Headers:
Authorization: Bearer
URL params: None
Data params: None
Success response:
200 – list of strings returned
Failure response:
Notes:
Might be used for UI to let users select set of document types of attachment when creating applications.
List license types
Description: Returns list of all license types in xCAS.
URL: /types
Method: GET
Headers:
Authorization: Bearer
URL params: None
Data params: None
Success response:
200 – list of structures returned. each structure contains “id”, “code” and “name” of each license type configured in xCAS
Failure response:
Notes:
Might be used for UI to let users select set of license types of attachment when creating applications.
List contract term types
Description: Returns list of all contract terms types configured in xCAS.
URL: /contractTermTypes
Method: GET
Headers:
Authorization: Bearer
URL params: None
Data params: None
Success response:
200 – list of structures returned. each structure contains “id” and “name” of each term type configured in xCAS
Failure response: 401 in case of bad token
Notes:
Might be used for UI to let users select contract term types when creating applications.
