Skip to main content

RESTful Web Services API

Universal Controller supports a RESTful-based web services API that allows you to perform multiple operations, which are listed alphabetically on the following pages.

Formatting specifications for each web service, including details about field requirements, are provided.

Agents

Agent Clusters

Audits

Bundles and Promotion

Bundles

Promotion

Business Services

Calendars

Cluster Nodes

Connections

Credentials

Custom Days

Groups

LDAP

Monitoring

OAuth Single Sign-On

OAuth Clients

OMS Servers

Passwords

Properties

Reports

Scripts

Server Operations

Simulation

System

Task Instances

Tasks

Triggers

Universal Event

Universal Event Templates

Universal Templates

Users

Variables

Virtual Resources

Webhooks

Workflow Task Instances

Workflow Tasks

Swagger UI and OpenAPI

Universal Controller offers an OpenAPI specification along with a Swagger UI page that provides an interactive interface for easily visualizing and interacting with Universal Controller RESTful API endpoints.

The Swagger UI page can be accessed from the Universal Controller user interface by clicking on the icon in the toolbar.

The OpenAPI document can be accessed in either JSON or YAML formats by going to <Controller URL>/resources/openapi.json or <Controller URL>/resources/openapi.yaml.

Methods of API Operations

Every API operation is performed using one of the following methods.

Method

Description

GET

Retrieves records from the Controller database.

POST

Creates, or performs an action on, a record in the Controller database.

PUT

Modifies a record in the Controller database.

info

PUT, by itself, actually replaces an existing record with whatever information you include in the PUT operation. If you include only partial record information in a PUT, the record in the database will then contain only that information.

In order to modify information in a record and retain all of its unmodified information, you must first GET the record from the database, modify (add/delete/change) information in the record, and then PUT the record back in the database.

DELETE

Deletes a record in the Controller database.

Authentication

Universal Controller requires Web Service requests to be authenticated using one of Basic Authentication or Personal Access Token Authentication.

For Basic Authentication, use the following Authorization header, where the username:password is base64 encoded.

Authorization: Basic <username:password>

For Personal Access Token Authentication, use the following Authorization header.

Authorization: Bearer <access-token>

While it is recommended you use the Authorization header, if required, you can alternatively pass the Personal Access Token using the access_token query parameter.

http://<hostname>:<port>/uc/resources/task?access_token=<access-token>&taskname=MyTask If you cannot use any of the above, you can configure an alternative authorization header. To configure an alternative authorization header, refer to the Web Service Personal Access Token Auth Headers system property.

X-Gitlab-Token: <access-token>

See User Impersonation for information on how to impersonate a user when invoking Universal Controller Web Service APIs.

Change Description

Change History is supported for the following record types (and any related data for these record types):

  • Agent Cluster
  • Application
  • Calendar
  • Credentials
  • Custom Day (Global)
  • Database Connection
  • Email Connection
  • Email Template
  • Business Services
  • OAuth Client
  • Peoplesoft Connection
  • Sap Connection
  • Script
  • SNMP Manager
  • Task
  • Task Instance
  • Trigger
  • Variable (Global)
  • Virtual Resource

If the Change History Enabled system property is true, you can specify a Change Description when updating a supported record type via the API by using the X-Change-Description header. A time-stamped entry with the value given in this header will be added to the Change History of the record on a successful Update operation.

If the Change History Description Web Service Required system property is true, the X-Change-Description header is required for supported record types; otherwise, it is optional. X-Change-Description will be ignored when updating an unsupported record type, or when creating any record type.

info

When using the Set Variable Web Service API, the X-Change-Description header is applicable when updating a Global Variable. It is also applicable when creating/updating a Local Variable, in which case the specified Change Description will be propagated to the Change History of the parent task or trigger.

Request Limits

You can implement application- and user-level concurrent request limits to control how many web service API requests can be in progress at the same time via the following Universal Controller system properties:

Web Service Application Concurrent Request Limit

Controls the number of concurrent requests for the application (that is, the Universal Controller server).

This application-level concurrent request limit cannot be less than 1 or less than the user-level concurrent request limit (if specified).

Web Service User Concurrent Request Limit

Controls the number of concurrent requests per unique user ID.

This user-level concurrent request limit cannot be less than 1 or more than the application-level concurrent request limit (if specified).

If the application-level concurrent request limit is exceeded, an HTTP Status of 429 /Too Many Requests will be returned.

These properties are applied in the following order:

  1. User-level Concurrent Request Limit
  2. Application-level Concurrent Request Limit

Memory Utilization Threshold

You can specify a threshold for prohibiting access to the RESTful Web Service API based on a percentage of allocated memory in use.

Web Service Memory Utilization Threshold

Percentage of allocated memory in use that defines a threshold for prohibiting access to the RESTful Web Service API.

The threshold must be a whole number (integer) and cannot be less than 1 or more than 99.

If the threshold is exceeded, an HTTP Status of 503 /Service Unavailable will be returned.

Returned Messages

The following table identifies the status codes (part of the HTTP/1.1 standard) that can be returned.

Status Code

Description

200

Success

400

Bad request data.

401

User does not have authorization (username and/or password invalid).

403

User does not have permission to access Web Services.

Access options are set via:

404

Resource not found.

429

Too Many Requests.

500

All other errors.

For List Variables, 500 is returned if the Web Service fails due to invalid parameters. (A status description also is returned.)

503

Service Unavailable.

Any other failure status codes may be returned by the underlying RESTful services. Most resources (Controller records) are returned as XML.

You can check status codes in the Audits and the uc.log file to determine the cause if their Web Service client is not displaying the error message that comes back with the response.

User Restriction

You can be restricted from logging in to the RESTful Web Services API either of two ways:

  1. The system level default for RESTful Web Services API access, specified by the System Default Web Service Access Universal Controller system property, has been set to No, and the Web Service Access field in the User Details for your user account is set to -- System Default --."
  2. The Web Service Access field is set to No, which overrides the System Default Web Service Access value.

If either restriction is in place, the following error message will be written to the Audits table and the uc.log file when you attempt to access the RESTful Web Services API:

User <your user name> not permitted to use Web Services. Please check with your administrator.

To remove the restriction, the system administrator must either:

  • Set the System Default Web Service Access property to Yes and set the Web Service access field on the User Definition screen for your user account to -- System Default --.
  • Set the Web Service access field on the User Definition screen for your user account to Yes.

Password Expiration

While a password is expired, RESTful Web Services API access will be prohibited until the password has been changed.

info

Password expiration is not applicable to LDAP authenticated users.