Review the changes to the publicly available REST APIs for the 

Changes for Release 6.8.1

Improvements to AssetTransfer API documentation

Before disabling or deleting a user's account, an admin may wish to transfer the user's assets to the ownership of a different user. For more information on how to transfer all assets via API, see API People AssetTransfer v4.

Changes for Release 6.8

Overrides to relational sources and targets

Through the APIs, you can now apply overrides to relational sources and targets during job execution or deployment import. 

jobGroups

When you are running a job, you can override the default publication settings for the job using overrides in the request. For more information, see API Workflow - Run Job.

Deployments

When you import a flow package into a deployment, you may need to remap the source and output of the flow to use production versions of your data. This capability has been present in the product for file-based sources and targets. Now, it's available for relational sources and targets. For more information, see Define Import Mapping Rules. 

New flow object definition

Release 6.8 introduces a new version of the flow object definition. This new version will support cross-product and cross-version import and export of flows in the future. For more information see Changes to the Object Model.

Export and import macros

Beginning in Release 6.8, you can export and import macro definitions via API.

• Export: API Macros Package Get v4
• Import: API Macros Package Post v4

Changes for Release 6.4

Request format for assigning connection permissions endpoint has changed

For this endpoint:

/v4/connections/<cid>/permissions/

where:

• <cid> is in the internal connection identifier.

The request payload format has changed.

Before Release 6.4, the request format was as follows:

[
  {
    "personId": 3,
    "role": "readOnly"
  }
]

Beginning in Release 6.4, the request format is as follows:

{
  "data": [
    {
      "person": {
        "id": 3
      },
      "role": "readOnly"
    }
  ]
}

For more information, see API Connections Permissions Create User v4.

v4 version of password reset request endpoint

To assist in migration from the command-line interface to using the APIs, a v4 version of an API endpoint has been made available to allow for administrators to generate password reset codes.

Changes to awsConfig object

In Release 6.0, the awsConfig object was introduced to enable the assignment of AWS configurations to individual users (per-user auth) via API. This version of the awsConfig object supported a mapping of a single IAM role to an awsConfig object.

Beginning in Release 6.4, per-user authentication now supports mapping of multiple possible IAM roles to an individual user's configuration. To enable this one-to-many mapping, the awsRoles object was introduced.

• An awsRoles object creates a one-to-one mapping between an IAM role and an awsConfig object.
• An awsConfig object can have multiple awsRoles assigned to it.

Changes to awsConfig object:

• The role field in the object has been replaced by activeRoleId, which maps to the active role for the configuration object.
• For each role reference in the awsConfig objects, a corresponding awsRole object has been created and mapped to it.

Beginning in Release 6.4, you can create, edit, and delete awsRoles objects, which can be used to map an AWS IAM role ARN to a specified AWSConfig object. You can map multiple awsRoles to a single awsConfig.

For more information, see API Workflow - Manage AWS Configurations.

Changes for Release 6.3

Assign AWSConfigs to a user at create time

Beginning in Release 6.3, you can assign an AWSConfig object to a user when you create the object. This shortcut reduces the number of REST calls that you need to make. 

Prior to Release 6.3, AWSConfig objects were assigned through the following endpoint. Example:

/v4/people/2/awsConfigs/6

See API Workflow - Manage AWS Configurations.

Changes for Release 6.0

Error in Release 6.0.x API docs

In Release 6.0 - Release 6.0.2, the online and PDF versions of the documentation referenced the following endpoint: API JobGroups Get Status v4. According to the docs, this endpoint was triggered in this manner:

/v4/jobGroups/<id>/status

This endpoint exists in v3 of the API endpoints. It does not exist in v4.

Instead, you should monitor the status field for the base GET endpoint for jobGroups. For more information, see API JobGroups Get v4.

Planned End of Life of v3 API endpoints

In Release 6.0, the v3 API endpoints are supported.

You must migrate to using the v4 API endpoints before upgrading to the next release after Release 6.0. 

Changes for Release 5.9

Introducing Access Tokens

Each request to the API endpoints of the 

• A request could include clear-text username/password combinations. This method is not secure.
• A request could include a browser cookie. This method does not work for well for use cases outside of the browser (e.g. scripts).

Beginning in Release 5.9, API users can manage authentication using access tokens. These tokens obscure any personally identifiable information and represent a standards-based method of secure authentication.

The basic process works in the following manner:

1. API user requests generation of a new token.
   1. This initial request must contain a valid username and password.
   2. Request includes expiration.
   3. Token value is returned in the response.
2. The token value inserted into the Authorization header of each request to the platform.
3. User monitors current time and expiration time of the token. At any time, the user can request a new token to be generated using the same endpoint used in the initial request. 

Access tokens can be generated via API or the 

• API: For more information, see API AccessTokens Create v4.

• D s webapp

  : For more information, see Access Tokens Page.

For more information on API authentication methods, see API Authentication.

Changes for Release 5.1

None.

Changes for Release 5.0

Introducing v4 APIs

Release 5.0 signals the introduction of version 4 of the REST APIs. 

v4 conventions

The following conventions apply to v4 and later versions of the APIs:

• Parameter lists are consistently enveloped in the following manner:
  
  

  Code Block
  { "data": [ { ... } ] }

• Field names are in camelCase and are consistent with the resource name in the URL or with the embed URL parameter.

• From early API versions, foreign keys have been replaced with identifiers like the following:
  
  

  v3 and earlier	v4 and later
  Code Block "createdBy": 1,	Code Block "creator": { "id": 1 },
  Code Block "updatedBy": 2,	Code Block "updater": { "id": 2 },

• Publication endpoint references database differently. This change is to make the publishing endpoint for relational targets more flexible in the future. 

  v3 and earlier	v4 and later
  Code Block "database": "dbName",	Code Block "path": ["dbName"],

Changes for Release 4.2

Create Hive and Redshift connections via API

You can create connections of these types via API:

• Only one global Hive connection is still supported.
• You can create multiple Redshift connections.

WrangledDataset endpoints are still valid 

In Release 4.1.1 and earlier, the WrangledDataset endpoints enabled creation, modification, and deletion of a wrangled dataset object, which also created the associated recipe object.  

In Release 4.2, wrangled datasets have been removed from the application interface. However, the WrangledDataset API endpoints remain, although they now apply to the recipe directly.

The following endpoints and methods are still available:

For more information, see Changes to the Object Model.