...
Every time a token is used, the activity is logged in your Authentication Log. This log can be used to troubleshoot calls to the API and also ensure you are the only one using a token. You can view this for an individual token or for all of your tokens as shown below OR via the Opsera Audit Logging Token API (which itself would require a valid token).
...
Customer Platform APIs
The following API’s are available for integration with customer scripts or automation tools. The above token rules apply for all. Please note, get requests for tools or pipelines are limited to max of 1000 records. There is almost NO data validation on the create/update behavior, so if bad data (or malicious data) is posted to this API, there is no stopping it from breaking things.
API Servers:
Testing: https://api.opsera-test.opsera.io
Production: https://app.opsera.io
...
URL
...
METHOD
...
DESCRIPTION
...
DATA
...
RESPONSE
...
/api/v1/pipeline/demo
...
POST
...
Used for testing as a pipeline scope. It requires valid data for a given pipeline/owner but doesn’t actually trigger anything in the pipeline. It’s used to mirror the concept of the run pipeline below for testing and development.
...
| Code Block |
|---|
{
"pipelineId":"5fd56d90979ee048ee660624"
} |
...
| Code Block |
|---|
{
"status": "success",
"message": "it seems to be working",
"reqBody": {
"pipelineId": "5fd56d90979ee048ee660624",
"customerId": "5e46fb7ec3fa752bd2f3b990"
},
"reqToken": {
"owner": "opsera",
"userName": "OpsERA",
"email": "support@opsera.io",
"userId": "5e1cbf251c26d68f7ce6361e",
"scope": "pipeline",
"tokenId": "6025748a0809e88dd5337722",
"iat": 1613067402,
"exp": 1615659402
}
} |
...
/api/v1/pipeline/run
...
POST
...
Triggers a run operation on the pipeline which returns the status, a message and the run count for the new run.
...
| Code Block |
|---|
{
"pipelineId":"5fd56d90979ee048ee660624"
} |
| Code Block |
|---|
{
"status": "executed",
"message": "Run pipeline request submitted successfully for (5fd56d90979ee048ee660624)",
"runCount": 2
} |
OR
| Code Block |
|---|
{
"status": "failed",
"message": "Pipeline 5fd56d90979ee048ee660624 is currently in a paused state. Will not start another job until this pending status is resolved."
} |
...
/api/v1/pipeline/status
...
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.
| Code Block |
|---|
{
"pipelineId":"5fd56d90979ee048ee660624",
"runCount": 3
} |
| Code Block |
|---|
{
"status": "success",
"message": "Pipeline: Blank Template's Run 3 was successful."
} |
...
/api/v1/pipeline/reset
...
POST
...
Resets the pipeline to the beginning, clearing out any current run data.
| Code Block |
|---|
{
"pipelineId":"5fd56d90979ee048ee660624"
} |
| Code Block |
|---|
"status": "success",
"message": "The pipeline run status has been reset."
} |
...
/api/v1/pipeline/stop
...
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.
| Code Block |
|---|
{
"pipelineId":"5fd56d90979ee048ee660624"
} |
| Code Block |
|---|
{
"status": "success",
"message": "The pipeline has been stopped."
} |
...
/api/v1/pipeline/summary
...
POST
...
Gets the pipeline data by ID
...
| Code Block |
|---|
{
"pipelineId":"5fd56d90979ee048ee660624"
} |
...
Returns full JSON data object of pipeline.
...
/api/v1/pipeline/logs
...
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.
...
| Code Block |
|---|
{
"pipelineId":"5fd56d90979ee048ee660624",
"runCount": 2,
"type":"console output" //optional value
} |
...
Array of pipeline activity logs.
...
/api/v1/pipeline/update
...
POST
...
Passes a pipeline ID and then the data object properties of pipeline you wish to update. This can be as much or as little of the root pipeline 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.
...
| Code Block |
|---|
{
"pipelineId":"5fd56d90979ee048ee660624",
"pipeline": {
"name":"Updated Pipeline Via CLI",
"description": "Updating the description here through customer API. Fingers crossed"
}
} |
...
Returns the updated pipeline data object in its entirety.
...
/api/v1/pipeline/create
...
POST
...
This will accept a full pipeline JSON data object and create it. This requires a name, account, organizationName but if other data points are excluded, it could break the UI or have other unforeseen consequences, so be VERY CAREFUL to ensure the data is right.
| Code Block |
|---|
{
"workflow": {
"source": {
"default_tools_configurations": [],
"name": "",
"service": "",
"repository": "",
"branch": "",
"key": "",
"trigger_active": false
},
"schedule": {
"start_date": null,
"end_date": null,
"frequency": ""
},
"last_step": {},
"last_run": {},
"plan": [],
"run_count": 0
},
"tags": [
{
"type": "pipeline",
"value": "python"
}
],
"type": [],
"roles": [],
"owner": "5e46fb7ec3fa752bd2f3b990",
"organizationName": "opsera",
"account": "org-opsera-dnd-acc0",
"name": "Updated Pipeline Via CLI",
"template": "5efc6fabaf75e201aa8c4a7e",
"description": "Updating the description here through customer API. Fingers crossed",
"active": true,
} |
...
Returns the new pipeline object in JSON format
...
/api/v1/registry/tools
...
GET
...
Gets the list of all tools (with all JSON data) that they have access to.
...
n/a
...
Returns an array of tool objects in JSON format
...
/api/v1/registry/summary
...
POST
...
Gets a tool registry JSON object with ALL data about that tool by ID.
...
| Code Block |
|---|
{
"toolId":"5fc7a12ebed9dd3a622f5d22"
} |
...
Returns the full tool object in JSON format.
...
/api/v1/registry/update
...
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.
| Code Block |
|---|
{
"toolId":"5fd56d90979ee048ee660624",
"tool": {
"name":"Updated Tool Name Via CLI",
"description": "Updating the description here through customer API. Fingers crossed"
}
} |
...
Returns the updated tool object in JSON format
...
/api/v1/pipeline/pipelines
...
GET
...
Gets the list of all pipelines (with all JSON data) the user token has access to
...
n/a
...
Returns an array of pipeline objects in JSON format
...
/api/v1/registry/create
...
POST
...
This will accept a full tool registry JSON data object and create it. This requires a name, account, tool_identifier and tool_type_identifier but if other data points are excluded, it could break the UI or have other unforeseen consequences, so be VERY CAREFUL to ensure the data is right.
Also, this does NOT trigger any saving to vault activity or job creation. All this does is save the summary tool registry record in the database.
| Code Block |
|---|
{
"projects": [],
"tags": [],
"accounts": [],
"tool_tagging": [],
"name": "Bit Bucket Server Raj",
"description": "",
"tool_identifier": "bitbucket",
"costCenter": "",
"compliance": [],
"licensing": [],
"location": [],
"classification": "",
"contacts": [],
"applications": [],
"organization": [],
"external_reference": [],
"active": true,
"roles": [],
"status": "",
"tool_type_identifier": "source",
"owner": "5e1cbf251c26d68f7ce6361e",
"account": "org-opsera-dnd-acc0",
"jobs": [],
"actions": [],
"configuration": {}
} |
...
/api/v1/logs/user/actions
...
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)
...
Optional Query Parameters:
?date=YYYY-MM-DD
?type=<value from type field>
| Code Block |
|---|
{
"count": 6,
"data": [
{
"_id": "61042540e1d666c9ded178c4",
"user_id": "5e1cbf251c26d68f7ce6361e",
"user_email": "support@opsera.io",
"type": "pipeline",
"action": "update",
"target_id": "5fbe589a0fae8b021e137534",
"account": "org-opsera-dnd-acc0",
"createdAt": "2021-07-30T16:13:52.109Z",
"updatedAt": "2021-07-30T16:13:52.109Z",
"__v": 0
},
]
} |
...
/api/v1/logs/user/tokens
...
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)
...
Optional Query Parameters:
?date=YYYY-MM-DD
?scope=<value from scope field>
| Code Block |
|---|
{
"count": 6,
"data": [
{
"_id": "61057f3a1429a35336563240",
"token_id": "61043b2bbcb6d95b55adc5fd",
"scope": "api",
"target": "/v1/logs/user/tokens",
"user_id": "5e1cbf251c26d68f7ce6361e",
"account": "org-opsera-dnd-acc0",
"createdAt": "2021-07-31T16:50:02.242Z",
"updatedAt": "2021-07-31T16:50:02.242Z",
"__v": 0
},
]
} |