Follow the steps below to learn how to authenticate Astera’s Server APIs.

1. Right-click on the server name in Server Explorer > Server Connections > DEFAULT > HTTPS://(ServerName):9260.

1. A wizard will appear with the Centerprise Server API Path. Click on the copy icon located at the bottom-left of the wizard to copy it.

A message will appear to confirm that the text has been copied successfully. Click OK.

Importing APIs in Astera

1. Click the Import API option in the API Browser and paste the Astera Server API path in the URL box. Then click OK.

1. A wizard will appear, notifying you about the created shared action file. Click Yes to set it up.

You can also click on the .sact file in Project Explorer to configure the authentication settings.

The API Browser will be populated with Astera’s Server APIs, which you can use in your dataflow.

1. Right-click on the Centerprise_Server object and select Properties.

This will open the API Connection screen. Select the Security Type as Bearer Token, as Astera Server APIs use Bearer Token authentication.

Provide the User Name, Password, and Token URL for Bearer Token. Then click Request Token to generate a token, and click OK. Press Ctrl+S to save changes in the shared action file.

1. Now, drag-and-drop the /api/ServerInfo from the API Browser to make a GET request.

1. Right-click on the object’s header and select Preview Output.

This is how your output would look like:

This concludes working with Astera’s Server API.

Facebook uses HTTP-based APIs that can be utilized to extract or load data, to and from Facebook. You can configure Facebook APIs for use in Astera using the ‘Custom API’ source in the REST API Browser (Beta).

To authorize a Facebook API in Astera, follow the steps below.

1. Go to this Url: https://developers.facebook.com/ and log in.

1. Enter your Facebook account credentials to log in.

1. Go to My Apps > Create App to create an application.

1. Provide the Display Name for your application, and click Create App ID.

Once your application is created, it will show under the My Apps tab.

1. Click Centerprise to open the dashboard.

Reference Url: https://developers.facebook.com/apps/217423066002800/dashboard/

1. Click on Settings > Basic to get the relevant credentials.

Reference Url: https://developers.facebook.com/apps/217423066002800/settings/basic/

1. Here you can see the App ID and App Secret. Save this information to use later for authentication.

1. To use Bearer Token authentication, go to Tools > Graph API Explorer.

Reference Url: https://developers.facebook.com/tools/explorer/

1. Click Generate Access Token and copy the token.

1. To access and try out different APIs, go to Tools > Graph API Explorer.

Reference Url: https://developers.facebook.com/tools/explorer/

1. Select anything from the drop-down list.

1. Click Submit, to see the results.

1. Import the API in Astera using the Import API option in the REST API Browser (Beta). Select API Import Source as Custom API by providing Name and Base Url.

Base Url: https://graph.facebook.com/

1. Now, you need to authenticate the Facebook APIs to use them in your dataflow. Without authentication, you will get an error. To authenticate an API, go to the Project Explorer panel and double click on the API’s .sact file under the Shared Connection node.

Facebook’s .sact file will open on the designer. Now, right-click on the shared action file’s header and select Properties. This will open the REST API Connection window, where you can configure the settings to authenticate Facebook’s API.

Facebook uses ‘OAuth 2’ authentication with Grant Type, ‘Authorization Code’.

Auth Url: https://www.facebook.com/dialog/oauth

Access Token Url: https://graph.facebook.com/oauth/access_token

Provide ClientID and Client Secret that you had saved earlier, then click on Request token to generate the access token for Facebook.

1. Save the shared action file after authentication and you are ready to use Facebook APIs in Astera.

This concludes authenticating the Facebook APIs in Astera.

NTLM (NT LAN Manager) authentication is a Microsoft proprietary authentication protocol used to authenticate users in a Windows-based network.

It provides secure authentication by using a challenge-response mechanism, where the server sends a challenge to the client, and the client sends a response that is encrypted using a hash of the user’s password.

NTLM authentication is used in various Microsoft products, including Windows, Internet Explorer, and Microsoft Office.

NTLM in Astera

Astera also offers the ability to use NTLM authentication when establishing an API connection.

1. To start, drag-and-drop the API Connection object from the Toolbox onto a Dataflow.

1. Right-click on the object and select Properties from the context menu.

This will open a new window,

Base URL: Here, you can specify the base URL of the API which will prepend as a common path to all API endpoints sharing this connection. A Base URL usually consists of the scheme hostname and port of the API web address.

Timeout (msec): Specify the duration, in milliseconds, to wait for the API server to respond before giving a timeout error.

Include Client SSL Certificate: Selecting this option is going to include any Client SSL certificate that is needed for authentication.

Enable Authentication Logs: Selecting this checkbox will allow the client to generate authentication logs when the API connection has been configured.

1. Fill in the Base URL and open the Security Type drop-down menu,

For our use case, we have deployed an API on IIS Manager on another machine, and we will send a request to access that API.

1. Select NTLM as the authentication type.

This will give us the following options,

Username: This field will input the same username that is used to login to Windows.

Password: The password associated with Windows login credentials.

1. Click OK and the API Connection object will be configured with NTLM Authentication.

This API Connection can then be used in API Client objects to make API calls to the server and receive appropriate responses in return.

1. Drag-and-drop an API Client object onto the dataflow and select the shared connection that was defined.

1. Click OK and preview the output of the API Client object.

As we can see in our data preview window, the request has been sent successfully and the response has returned as ‘200 OK’.

This concludes working with and configuring the NTLM Authentication in Astera.

The Avaza API follows REST protocol with ‘OAuth2’ authentication. It allows you to access contacts, projects, tasks, invoices and taxes. In Astera, you can configure an Avaza API through a swagger definition using the Import API option in API Browser.

Let’s go over how we can authenticate an Avaza API in Astera.

1. Create an integration project by going to Project > New > Integration Project.

1. To import Avaza API in your Astera client, click on the following icon.

1. An Import API window will open. Here you will need to select your relevant import source. In this case, we will import using the Json/Yml Url source.

Base URL: https://api.avaza.com/swagger/docs/v1

You will see that all the APIs present on Avaza’s URL have been populated in the API Browser.

1. Now, you need to authenticate the Avaza APIs to be able to use them in your dataflow. Without authentication, you will get an error. To authenticate an API, go to the Project Explorer and double click on the API’s .sact file under the Shared Connection node.

The Avaza .sact file will open on the designer. Now, right-click the shared action file’s header and select Properties.

1. This will open the API Connection window where you can configure settings to authenticate Avaza API.

Avaza uses ‘OAuth 2’ authentication. In the ‘OAuth 2’ Security Type, select one from the following Grant Type options:

1. Authorization Code

2. Implicit

In this case, we will be using the ‘Authorization Code’.

Auth Url: https://any.avaza.com/oauth2/authorize

Access Token Url: https://any.avaza.com/oauth2/token

1. Now, click Request token to generate an access token and refresh token for Avaza.

1. After authentication, save the shared action file, and you are ready to use Avaza APIs in Astera.

This concludes authenticating the Avaza APIs in Astera.

Adafruit IO

Authentication Type: API Key

• Import API: https://raw.githubusercontent.com/adafruit/io-api/gh-pages/v2.json

• Authentication: API-KEY

• Key: X-AIO-Key

• Value: aio_UTqF73klycqdLWpbp0wLl7RHKV25

• UserName: [Enter you user name]

• FeedKey: [Enter your feed key]

• Adafruit Login Page: https://accounts.adafruit.com/users/sign_in

• Email: [Enter your login email]

• Password: [Enter your password]

Avaza API

Authentication Type: OAuth 2, Authorization Code

• Import API: https://api.avaza.com/swagger/docs/v1

• Authentication: oauth2 (Access token will be valid for 1 day)

• Token URL: https://any.avaza.com/oauth2/token

• Auth URL: https://any.avaza.com/oauth2/authorize

• ClientId: [Enter client ID]

• Client Secret: c1d4b723790f0e24d0b2df68ebde613e9533

• Avaza Login Page: https://any.avaza.com/account/login

• Email: [Enter your email]

• Password: [Enter your password]

BOX API

Authentication Type: Bearer Token

• Base URL: https://api.box.com/2.0

• Authentication: Bearer Token (Access token will be valid for 1 hr)

• Token: 1IVYyDgfDPyWpoXe9c4RMOt7tmtiB75q

• Steps to generate access token:

• Page: https://app.box.com/developers/console/app/984015/configuration

• Email: [Enter your login email]

• Password: [Enter password]

• Click Generate Developer Token to generate access token

• API Reference: https://developer.box.com/en/reference

Facebook API

Authentication Type: OAuth 2, Authorization Code

• Base URL: https://graph.facebook.com/

• Auth URL: https://www.facebook.com/dialog/oauth

• Access Token URL: https://graph.facebook.com/oauth/access_token

• Client ID: 217423066002

• Client Secret: d7d8969c6ea31bf117f04768b63bb

• Credentials to use when using ‘Request Token’

• Email address: [Enter your email]

• Password: [Enter your password]

Google Drive

Authentication Type: Bearer Token

• Base URL: https://www.googleapis.com/drive/v3

• Authentication: Bearer Token (Token will be valid for an hour)

• Token: ya29.Il_AB6CICAcAQD6lKoQCW3K2DO_enBd3be5G2Vvd0hZ3Q8US4eHL-PEOS1qRD7zzSEN3t_qb_eNqWzZS3zsXP_FcAHA9TSoy-tDpsWv0RnWRledPhZqRt79f9X

• API Reference: https://developers.google.com/drive/api/v3/reference

Steps to generate access token:

1. Go to https://developers.google.com/oauthplayground/

2. Select the APIs you want to authorize and click Authorize APIs.

3. On the next screen, provide your credentials.

4. Email: [Enter your login email]

5. Password: [Enter your password]

6. Now click Exchange authorization code for tokens to generate access token.

netAuth API

Authentication Type: API Key

• Import API: https://api.doc.nextauth.com/api/swagger.json

• Authentication: API-KEY

• KEY: [Enter API Key]

• VALUE: J5znqilK_qUt65iQyy9W2Q

• Help link: https://api.doc.nextauth.com/

OMDb API

Authentication Type: API Key

• API key to be passed as a query parameter

• JSON File: http://www.omdbapi.com/swagger.json

Steps to generate API Key:

Open

1. Select Account Type, ‘FREE.’

2. Enter your email address.

3. Enter your first name and last name.

4. Describe in a few words your purpose of using this service.

5. Click Submit.

6. You will get the API Key in your email with a link to activate it. Click on this link and the key will be activated.

Square Connect API

Authentication Type: Bearer Token

• Import API: https://raw.githubusercontent.com/square/connect-api-specification/master/api.json

• Authentication: Bearer Token

• Token: EAAAEPXVtza2Utrx-GJ90Az4sCQ_NLbLYOKANVFmJiPGJ1Z6B-eJgZ-2V1

• Use this API to import: https://raw.githubusercontent.com/

Note: This looks like an issue with Square Connect’s documentation because the ‘Import API’ option does not work.

Zendesk API

Authentication Type: Basic Authentication

• Username: [Enter username or login email]

• Password: [Enter password]

AWS Signature authentication is the process of verifying the authenticity of requests made to Amazon Web Services (AWS) using the AWS Signature method.

This authentication process involves calculating a digital signature for each request using the requester’s access key and secret access key, along with details about the request being made. AWS verifies the signature against the user’s access credentials and grants access to the requested resources if the signature is valid.

The AWS Signature authentication method ensures that requests are securely transmitted and that only authorized users can access AWS resources.

AWS Signature Authentication in Astera

Astera lets the user configure an API Connection with AWS Signature as an authentication type.

1. Drag-and-drop an API Connection object from the Toolbox onto a Dataflow.

1. Right-Click on the object and select Properties from the context menu.

This will open a new window:

Base URL: Here, you can specify the base URL of the API which will prepend as a common path to all API endpoints sharing this connection. A Base URL usually consists of the scheme hostname and port of the API web address.

Timeout (msec): Specify the duration, in milliseconds, to wait for the API server to respond before giving a timeout error.

Include Client SSL Certificate: Selecting this option is going to include any Client SSL certificate that is needed for authentication.

Enable Authentication Logs: Selecting this checkbox will allow the client to generate authentication logs when the API connection has been configured.

1. Define the Base URL and select AWS Signature from the security type.

1. Selecting it will make the following options available.

Access Key: The unique access key provided to the AWS user for authentication.

Secret Key: The corresponding unique key provided to the AWS user for authentication

AWS Region: The region from where the API connection is being made, set by the admin.

Service Name: The name of the AWS service being used in the API Connection.

5. Once the fields have been filled, click OK and the API Connection will be configured.

This API Connection can then be used in an API Client object to make API Calls to the resource.

1. Drag-and-drop an API Client object and configure it with the API Connection.

1. Preview the output of the API Client object.

As you can see, the response has returned a ‘200 OK’ status.

This concludes the configuration and testing of the AWS Signature Authentication in Astera.

Square API is an HTTP-based API that follows REST standards. It allows you to manage the resources of your Square account by making requests to URLs representing those resources. You can configure Square API for use in Astera by providing its swagger definition using the Import API option in the API Browser.

1. After you have created the application in Square, go to Manage Properties.

1. Now go to OAuth properties in Production tab. Here, you have to provide the Redirect URL for the authorization callback.

Reference Link: https://developer.squareup.com/docs/oauth-api/overview

1. Now create an integration project in Astera. Also, import the following swagger definition in the API Browser:

Base Url: https://raw.githubusercontent.com/square/connect-api-specification/master/api.json

1. Go to the Square’s shared action file’s (.sact) properties to authenticate it in Astera.

You can authorize Square API by using Security Type OAuth 2 or Bearer Token. In this example, we will be authorizing using OAuth 2.

1. Set its Security Type as ‘OAuth 2’ and Grant Type as ‘Authentication Code’. Provide the application ID and secret that you saved in step 2.

Click on Request Token to get the access token to Square API.

Auth Url: https://connect//squareup.com/oauth2/authorize

Access Token Url: https://connect.squareup.com/oauth2/token

Additional Info: You can modify your authorization by mentioning the names of only those permissions that you want to access from your Square account in Astera. In case you want to access all of them, leave the settings at default.

1. Once you get the access token, save the Shared Action file and you are ready to use Square API in Astera.

This concludes authenticating the Square API in Astera.

The ActiveCampaign API is structured around REST, HTTP, and JSON. You can make requests by using URL endpoints particular to a specific resource. The resources in ActiveCampaign are represented in JSON following a conventional schema. In Astera, you can configure an ActiveCampaign API using the Import API option present in the REST API Browser.

ActiveCampaign does not provide an Open API definition so we will add a request manually by using a Custom API in Astera.

To authorize an ActiveCampaign API in Astera, follow these steps:

1. Create an integration project in Astera.

2. Create a Custom API and provide Base Url.

Reference link for Base Url: https://developers.activecampaign.com/reference#url

1. Now, you need to authenticate the ActiveCampaign APIs to use them in your dataflow. Without authentication, you will get an error. To authenticate an API, go to the Project Explorer and double-click on the API’s .sact file under the Shared Connection node.

The ActiveCampaign .sact file will open in the designer. Now, right-click the shared action file’s header and select Properties.

1. ActiveCampaign uses an API Key as Security Type. Specify your Key and Value.

Key: API-Token

Value: {Token}

1. Click OK, and save the shared action file (.sact).

2. Add methods in REST API Browser panel which you want to use in Astera by adding requests, and you are ready to use the ActiveCampaign API in Astera.

This concludes authorizing the ActiveCampaign API.

The QuickBooks API is a RESTful API which allows you to read or write data to and from QuickBooks. It uses ‘OAuth 2’ authentication type. You can configure a QuickBooks API in Astera by using the Import API option present in the API Browser.

QuickBooks does not provide Open API definition, so we will add the request manually by using a Custom API in Astera.

We only need to follow steps from Development > Create and Configure an App from the following link:

Authentication steps: https://developer.intuit.com/app/developer/qbo/docs/build-your-first-app

Where the Redirect Url used in step 7 in the above link for Astera would be:

Redirect Url for Astera Server: http://{Server_Name}:8050/)

Follow these steps to authorize QuickBooks’ API in Astera

1. Create an integration project in Astera.

2. Create a Custom API and provide a Name and Base Url.

Base Url (Sandbox): https://sandbox-quickbooks.api.intuit.com

Base Url (Production): URL:https://quickbooks.api.intuit.com

1. Now, you need to authenticate QuickBooks APIs to be able to use them in your dataflow. Without authentication, you will get an error. To authenticate an API, go to the Project Explorer and double click on the API’s .sact file under the Shared Connection node.

The QuickBooks .sact file will open in the designer. Now, right click on the Shared Action file’s header and select Properties.

1. QuickBooks uses ‘OAuth 2’ Security Type with Grant Type, ‘Authentication Code’.

Auth Url: https://appcenter.intuit.com/connect/oauth2

Token Url: https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer

ClientID: {ClientID}

Client Secret: {Client_Secret}

Scope: {Scope}

State: {State}

Additional Info - You can modify the authorization by mentioning the names of only those permissions that you want to access from QuickBooks in Astera.

1. Click OK, and save the Shared Action file (.sact).

2. Add methods in the REST API Browser which you want to access in Astera by adding requests and you are ready to use QuickBooks APIs in Astera.

This concludes authorizing the QuickBooks API.

Authentication

Astera’s Server APIs use Bearer Token authentication.

Resource: Account

Login

Method: POST

Endpoint: https://{servername}:{portno}/api/account/login

In this case: https://LOCALHOST:9261/api/account/login

Resource: /api/account/login

Request Body

Note: The format of our request body is JSON type.

Resource: Job

Status

Method: GET

Endpoint: https://LOCALHOST:9261/api/Job/{jobID}/Status

Resource: /api/Job/{jobID}/Status

Required Parameter

Description: This method fetches the status of a job for the given job ID. A few of the response statuses are given below:

1. Unknown

2. Invalid

3. NotStarted

4. Queued

5. Initializing

6. Running

7. Completed

The Astera Data Stack provides you with the flexibility to execute your jobs through a third-party tool, without using the Astera client. Let’s learn how to achieve this in the article below.

Use Case

In this use case, we have our Astera client on a local machine and a server installed on a virtual machine. Instead of using the Astera client, we will use Postman as a third-party tool to send REST requests to the server in order to execute the job.

Workflow in Astera

The workflow document in Astera consists of a Variables object, a FileTransferTask object and a RunDataflow object.

We will pass the name of the file that we want to download and process to the FileTransferTask from the Variables object. The Variables object takes an input from the REST call sent through Postman, and passes it to FTP to download the file with that name. We then pass the file path of the downloaded file to the RunDataflow object.

In the following section, we will cover a step-by-step overview of how you can achieve this.

How to Execute a Job Using Postman

1. We will make the first API call for logging into the Astera server to generate an access token. Provide the following credentials in the request body and click on Send.

• User: admin

• Password: Admin123

• RememberMe: 1

The Astera server will provide you with an access token in response.

1. In the second step, we will send the path of the file that we want to download from FTP, in the form of a string, to the Variables object.

In the parameters:

• ActionName: Variables

  Name of the object present inside the workflow to which the name of the file will be passed

• Parameters: sourceFilePath

  The value of the input variable field inside the workflow

• Value: [file path of the file that you want to download]

  The value of the input variable field inside the workflow

  As soon as you send this API request, Astera will provide you with a jobID that you can use to get the job status.

1. In the third step, we will make a GET call to fetch the job’s status by providing the job ID.

This is what Astera’s response would look like.

This concludes accessing Astera’s server APIs through a third-party tool.

1. Introduction

This article is intended to provide a brief user guide to Astera users on how they can use Astera Server APIs to perform some commonly used actions without using the Astera Client.

The document covers the following operations:

1. Configure Astera Server properties

2. Configure Astera Server license

3. Deploy user projects on Astera Server

4. Schedule/execute the jobs

2. Environment setup and tools used

For the use cases below, Astera Integration Server is installed on a Virtual Machine and no Astera Client is going to be used to perform operations. However, some images of the Astera Client have been used for description purposes. We will use the Postman client as a third-party tool to send API requests to the Astera Server to perform several tasks.

3. Use Cases

3.1. Login or Get authorization token API

3.1.1. Login API example (/api/account/login)

‘POST /api/account/login’

This API returns the bearer token that can be used to make calls to the Astera Server. It also returns some more information about the user.

3.1.2. Login API parameters description

3.2. Configure Server Properties

3.2.1. Configure Server properties API example (/api/Server/Config)

In this section, we are going to use the API ‘POST /api/Server/Config’ to change Server Profile of the Astera Server.

Here, we can see that a Server Profile named DEFAULT has been selected in our Server Properties.

To change this profile shown in the image above, we must provide the JSON body containing information related to the Repository Database with the name of the desired Server Profile in the POST request.

Once we have provided the relevant information, we can send the request.

We can see that a 200 OK success response is received in the image above.

We can verify using the Astera Client that we have successfully configured our server with the desired profile ServerProfile2.

A sample server config JSON body is provided here for reference.

3.2.2. Server properties configuration API Parameters description

3.3. Manage Server License

3.3.1. Change license key API example (/api/License/Key)

In this section, we are using the POST /api/License/Key API that allows the user to change the server license. We will also use the POST /api/License/Activate API to activate the license.

Go to Server > Configure > Enter License Key. Here, we can see a user ‘Nisha’ of the organization ‘G’ is registered with an active license.

To change the license key and register the user, we must provide the User, Organization, and License Key in the JSON request body. Refer to image below.

Once we have provided the relevant information, we can send the request.

In response, we can see that a 200 OK success status is received indicating that the license key has been changed.

Now, go to Server > Configure > Enter License Key, and notice the license properties. We can see a user Nisha of the organization Astera with a different/new license key has been registered.

3.3.2. Change license API Parameter description

3.3.3. Activate license API Example (/api/License/Activate)

However, the license is not activated yet. To activate the license, we can simply send a request to the /api/License/Activate endpoint. After sending the request, we can see that a 200 OK response is received.

Go to Server > Configure > Enter License Key again. Here, we can see the status of the license is activated now.

3.3.4. Activate license Parameter description

No parameters required, send an empty body here.

3.4. Configuring Cluster settings

Configuration of cluster settings is important before proceeding with the project deployment.

3.4.1. Cluster settings API parameters description ‘/api/Cluster’

The JSON payload sample for the cluster configuration is attached here.

3.5. Archive File Deployment (User project deployment)

To successfully deploy an archive file (User project .car file) using the APIs, a user must perform the following prerequisites:

• Upload the archive file (User project .car file) to the deployment directory.

• Upload the config file to the deployment directory. (optional)

3.5.1. Uploading the Archive File/Config File to the Deployment Directory

There are two methods to do this, let's see each in action.

a. Example of using ‘POST /api/UploadFile’

The user can upload the config and .car files to the deployment directory using APIs. There is a possibility that a user might delete or move the config or .car file from their local machine. To avoid any issues, it is recommended to first upload these files to the deployment directory.

To upload the file, use the ‘POST /api/UploadFile’ API. In this API, we must provide two query parameters:

• FileTypes: Extension of the target file e.g., cfg for the config file, car for Archive files.

• TargetFileName: Here, we define the target file’s name e.g., Testing.

Next, we need to configure Request Body for this API. For the request body, select the form-data content type, select the Key type as File and provide the desired archive file (.car file) in the Value. Click Send.

Here, we can see that a 200 OK response, with a file path of the deployment directory’s archive file, has been received. Please copy down this path on your notepad as we need to use this path while creating the deployment.

Similarly, we can upload the config file to the deployment directory using this api/UploadFile endpoint.

Parameter description of /api/UploadFile

b. Using the ‘POST api/UploadCarFile’

An archive file (.car file) can also be uploaded to the deployment directory via another API i.e., ‘POST api/UploadCarFile’.

In this API, we do not need to specify the query parameters. Simply select the archive file (.car file) in the body and click Send. Here, we receive the archive file path in the response.

The uploaded files can also be seen in the deployment directory.

Parameter description of api/UploadCarFile

3.5.2. Creating the Project Deployment

3.5.2.1. Using POST /api/Deployment example

Now, let’s proceed to the deployment creation. To create a deployment, we must use the ‘POST /api/Deployment’ API.

In this API’s Request’s Body, we must provide info such as:

1. Relevant archive (.car) and config (optional) file paths (both local and deployment directory file paths)

2. The deployment’s name, its ID, and its activation state, etc.

After defining the body, we can click Send.

Here, we can see a 200 OK response has been received indicating that a deployment has been created.

Open the client and go to Server > Deployment Settings > Deployment. In the deployment window, we can see the archive file has successfully been deployed.

A sample deployment JSON body is attached here for reference.

Please note the following:

• To create a new deployment, we must provide the field “Id” as 0. We should also provide a unique deployment “Name” i.e., not the same name as an already existing deployment. Otherwise, the request will result in a 400 Bad Request error.

• If we provide a non-zero “Id” field e.g., Id = 7, the server will consider this request as an update request, and if a deployment with ID 7 already exists on the server it will be modified/updated.

3.5.2.2. Parameter description of /api/Deployment

3.5.3. Post Deployment Modification

The ‘POST /api/Deployment’ API can also be used to modify an existing deployment. In this API’s Request Body, details of an existing deployment are required.

In this scenario, we want to update the name of the above-created DeploymentTesting. However, we do not have its details available.

So, to gather the details, we firstly use the ‘GET api/Deployments’ API to fetch the info of the existing deployment. Then, we copy the deployment Id, UpdateDtTm, and CreatedDtTm fields from the response.

Now, in the POST Request’s Body, let’s change the deployment Name to DeploymentTesting_Modified and replace the values of Id, UpdateDtTm, and CreatedDtTm fields with the values copied from the GET response.

Let’s send the request.

A 200 OK response is received. Now, go to Server > Deployment Settings > Deployment, in the deployment window, we can see the modified deployment name.

Let’s proceed to learn how we can schedule jobs on the server using APIs.

3.6. Scheduling Jobs

3.6.1. Scheduling Jobs using ‘POST api/Schedule’ API example

In this section, we are scheduling the previously created deployment using the ‘POST api/Schedule’ API.

This API’s Request Body requires the schedule configuration information, i.e., Schedule Name, Schedule Type, Frequency, Activate State, Server Info, etc.

A sample JSON is attached here for reference.

Let’s create the schedule called Schedule_Testing, which runs daily, with schedule type deployment, an active state as True, etc.

Sending the request shows a 200 OK status response.

If we go to Server > Job Schedules, in the scheduler window, we can see a schedule called Schedule_Testing with the following properties: Schedule Job Id is 4, with Schedule Type as Deployment, running at Frequency daily has been created.

Each time we update an existing schedule the UpdateDtTm field is modified as well. Therefore, we always have to send a GET api/Schedules or a GET /api/Schedule/:scheduleId request first to fetch the details and then use the received details as the body for the POST request to successfully modify a schedule.

3.6.2. Schedule job API Parameters description

A postman collection containing all the server APIs discussed in this article is attached here.