The following API’s are available for integration with end user scripts or automation tools. All API’s listed below require valid Opsera Access Tokens. Please note, GET requests for tools or pipelines are limited to a max of 1000 records.
...
Opsera Access Tokens have predefined scopes. These scopes limit where the the token can be used for more enhanced security. So the scope selected when the token is created must match the required scopes below for the API’s in order for access to be granted. If a 403: Forbidden message is returned, it either means that the token is using the wrong scope or the user who generated the token doesn’t have the permissions necessary to perform the given action on the object. The owner/creator of the token is used in determining access permissions in concert with the scope. For more information on scopes and access tokens, please review the Opsera Access Tokens documentation.Please Note: In addition to a valid token with the proper scope being used, the user who generated/owns the token MUST have the permissions to the object in order for the API to work. A user who does not have access to a given pipeline (even if their token is valid) will not be allowed to perform actions on that pipeline. A user must still be granted that access in the Opsera UI first
The user account used to generate the token is the one associated with the token. They are the owner of that token and as such any API call they use it against will validate their Roles and Access before allowing the action to proceed. A user MUST have the Power User role in order to access Opsera APIs OR be granted explicit access to an object. At this time, getting lists of data such as pipelines and tools requires a power user (or higher) role. But individual actions on specific pipelines or tools will evaluate the individual object’s RBAC access. Users can grant access to individual objects via the Opsera UI.
API Server:
When accessing the Opsera API, this is the URL to use:
Info |
---|
Your base URL may be different based on what platform you are using. Please consult with Opsera to identify your base API URL before proceeding. |
URL | METHOD | DESCRIPTION | Scope | Access | DATA | RESPONSE | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| POST | Triggers a run operation on the pipeline which returns the status, a message and the run count for the new run. |
| Item RBAC |
|
OR
| |||||||||||||||||||
| POST | Gets the status of a pipeline based on the run count. So this can work against the current run or prior runs from a historical perspective. |
| Item RBAC |
|
| |||||||||||||||||||
| POST | Resets the pipeline to the beginning, clearing out any current run data. |
| Item RBAC |
|
| |||||||||||||||||||
| POST | Stops a running pipeline. This action will post a stop operation to kafka for supported tools, but the pipeline job will finish it’s current operaiton and then shut down. This is not a hard stop operation. |
| Item RBAC |
|
| |||||||||||||||||||
| POST | Gets the pipeline data by ID |
| Item RBAC |
| Returns full JSON data object of pipeline. | |||||||||||||||||||
| POST | Gets pipeline activity logs. Optional runCount can be passed as integer. Data is limited to a max of 1000 records and is always sorted by most recent activity first. The “type” property of the POST body is optional. If that exact string “console output” is passed, it will restrict the logs being returned to the console log activity for that given run. |
| Item RBAC |
| Array of pipeline activity logs. | |||||||||||||||||||
| GET | Gets the list of all tools (with all JSON data) that they have access to. |
| Power User Role | n/a | Returns an array of tool objects in JSON format | |||||||||||||||||||
| POST | Gets a tool registry JSON object with ALL data about that tool by ID. |
| Item RBAC |
| Returns the full tool object in JSON format. | |||||||||||||||||||
| POST | Passes a tool registry ID and then the data object properties of that tool in JSON that you wish to update. This can be as much or as little of the root JSON object as long as the data structure is preserved. It’s advised not to send the “_id” but it isn’t going to break things. Same with the createdAt or updatedAt. This allows for strategic updates of just the root properties of the pipeline data object or the whole thing. |
| Item RBAC |
| Returns the updated tool object in JSON format | |||||||||||||||||||
| GET | Gets the list of all pipelines (with all JSON data) the user token has access to |
| Power User Role | n/a | Returns an array of pipeline objects in JSON format | |||||||||||||||||||
| GET | Gets the User Activity Logs for the system. This is a route limited to Site Admins and Power users and requires a token of either API scope or Security Logs scope. If no date parameter is passed, the last 7 days of logs will be returned (up to a max of 1000 records) |
| Power User Role | Optional Query Parameters:
|
| |||||||||||||||||||
| GET | Gets the Personal Access Tokens' Activity Logs. This is a route limited to Site Admins and Power users and requires a token of either API scope or Security Logs scope. If no date parameter is passed, the last 7 days will be returned.(up to a max of 1000 records) |
| Power User Role | Optional Query Parameters:
|
| |||||||||||||||||||
| GET | Gets a list of all tasks. |
| Item RBAC |
| ||||||||||||||||||||
| POST | Gets a task by ID |
| Item RBAC |
|
| |||||||||||||||||||
| POST | Gets the status of a task’s last status and returns it as a string |
| Item RBAC |
| Returns task status as a string. | |||||||||||||||||||
| GET | Returns a task log |
| Item RBAC |
Optional Query Parameters:
|
|