Server API Overview

Server tracks changes to these system entities:

• AppInfo (Workflow)
• Collection
• Credential
• Subscription
• User
• UserGroup

Get Logged Events via the Server API

Any updates to these entities triggers the creation of an AuditEvent record. You can return these records via a public Admin API endpoint.

Audit logs are triggered by the following type of operations (events): Update, Insert, and Delete.

Endpoint

The endpoint for AuditEvents is GET /admin/v1/auditlog/

Required Query Parameters

• entity: (string) the audit log entity you want to query.
• page: (int) The page you want to return.
• pageSize: (int) The number of records you want to return on each page.

The response will be an array of Audit Event records:

[
  {
    "id": "",
    "entity": "",
    "entityId": "",
    "userId": "",
    "timestamp": "Date",
    "event": "",
    "oldValues": "",
    "newValues": ""
  }
]

The returned properties are defined below:

• id: The Audit Event ID.
• entity: The name of the entity.
• entityId: The entity ID of the entity.
• userId: The ID of the user who modified the entity.
• timestamp: Date and Time of when the Audit Event record was created.
• event: The event which occurred (insert, update, delete).
• oldValues: The values of the updated properties prior to the update occurring.
• newValues: The values of the updated properties after the update has occurred.

  To run workflows that use the File Browse tool via the API, use the /user/v2/inputfiles endpoint to upload the file.

1. Start by making a multipart/form-data POST request to the /user/v2/inputfiles endpoint to publish a temporary file. The name of the required form-data section is inputFile.
    

   curl --location --request POST 'http:{yourhostname}/api/user/v2/inputfiles/' \
   --form 'inputFile=@/file/path/filename.csv' 

2. Next, make a POST to the /user/v2/workflows/{appId}/jobs/ endpoint.
   1. Then include the name of the File Browse tool in the question object. If you are unsure of the File Browse tool's name, use the /v1/workflows/{appId}/questions endpoint to get your File Browse tool's name.
   2. The value is the reference ID that your input file's call returned in the response.

   curl --location --request POST 'http:{yourhostname}/api/user/v2/workflows/{appId}/jobs' \
   --header 'Content-Type: text/plain' \
   --header 'Authorization: OAuth oauth_consumer_key="{consumer key}",
                            oauth_signature_method="HMAC-SHA1",
                            oauth_timestamp="{timestamp}",
                            oauth_nonce="{nonce}",
                            oauth_signature="{signature}"' \
   --data-raw '{
       "questions": [
           {
               "name": "File Browse",
               "value": "{reference ID}"
           }
       ]
       "priority": "Low"
   }'
   

Use the migratable endpoint to migrate workflows across Server environments. You can use this to manage workflow deployments during development and testing phases.

To begin, you have to enable workflows for migration. Once you mark workflows for migration, follow these steps to publish them from the source environment into the appropriate subscription (studio) of a target environment.

Step 1. Get a List of Workflows Ready to Migrate

Next, get a list of workflows ready to migrate using the following endpoint:

• Environment: Source
• Method: GET
• Endpoint: api/admin/v1/workflows/migratable/?subscriptionIds={subscriptionIds}/

Include a comma-separated list of subscriptionIds as a query parameter. Subscription IDs identify a specific studio.

The return is an array of workflows marked as ready to migrate under the specified subscription (studio). If you do not provide subscriptionsIds, the return includes all workflows marked as ready to migrate. The return includes 3 properties: appId, the currently published revisionId, and the subscriptionID the workflow belongs to.

Step 2. Download Workflows from the Source Environment

The following endpoint downloads the workflow as a YXZP file.

• Environment: Source
• Method: GET
• Endpoint: api/admin/v1/{appID}/package/

Include an appID as a path parameter. The return will be a download of the entire workflow as a package.

Step 3. Publish Workflows in the Target Environment

The following endpoint publishes the downloaded workflow to the target environment.

• Environment: Target
• Method: POST
• Endpoint: api/admin/v1/workflows/

(Optional) Step 4. Reset Migration Setting Workflows in the Source Environment

If you want, you can use the migratable endpoint to toggle the This workflow is ready to be migrated setting on a workflow back to No in the source environment after workflow migration in the target environment.

• Environment: Source
• Method: PUT
• Endpoint: api/admin/v1/workflows/migratable/{appID}/