Changes to the APIs
Review the changes to the publicly available REST APIs for the Designer Cloud Powered by Trifacta platform for the current release and past releases.
Release 8.11
writesettings objects are no longer validated for API-based jobs
Beginning in this release, the settings in a writesettings object are no longer validated as part of job execution for scheduled and API-based jobs. A writesettings object defines the file-based output for a job.
Note
When this feature is enabled, you should first test jobs by running them through the Trifacta Application. These validations are still performed during manual job execution. If the validation fails, the job can fail during transformation or publishing stages. if the job succeeds, scheduled and API-based jobs should work.
This feature is enabled by default. A workspace administrator can disable the feature if needed.
For more information, see Workspace Settings Page.
Release 8.8
API rate limiting
For some API endpoints that are heavily used or critical to the success use of the platform, rate limiting has been applied. API rate limiting sets the maximum number of requests that are accepted by an endpoint within a specified period of time. For example, you may be prevented from sending more than 50 requests to start a job or plan run within a minute.
Note
All rate-limited endpoints receive the default quota limit, which is determined based on the product tier. If a rate limit quota is reached, a small set of subsequent requests is enqueued. If the queue is filled before the end of the minute, subsequent requests return a 429 status code error.
Tip
Where applicable, the quotas for individual APIs are listed with the relevant API endpoint documentation.
See: https://api.trifacta.com/ee/9.7/index.html#section/Overview/Rate-limiting
Release 8.7
Removal of old asset transfer endpoint
The following endpoint for transferring assets between users has been removed from the product:
/v4/people/{to-userid:}/assetTransfer/{from-userid:}
The above endpoint no longer works.
In a previous release, this endpoint was replaced by an improved method of asset transfer. For more information, see "Asset transfer API using email addresses" below.
Deprecation of not useful connection endpoints
The following endpoints have been deprecated:
/v4/connections/vendors /v4/connections/credentialTypes /v4/connections/:id/publish/info /v4/connections/:id/import/info
These endpoints were scheduled for deprecation in Release 8.2 and are not widely used.
Tip
To acquire the definition of a specific connection, you can try the following:
/v4/connectormetadata/:connectorname
See https://api.trifacta.com/ee/9.7/index.html#operation/getConnectorConfig
Changes for Release 8.2
None.
Release 8.1
Customize relational connectors via API
Beginning in Release 8.1, you can customize aspects of each relational connection type available in your product edition through a set of APIs. Some terms:
connection: In the Trifacta Application and via API, you can create and manage connections between the platform a specific datastore. A connection is the user-defined object that enables the connection to the datastore.
connector: A connection interfaces with a connector, which is an underlying driver and its related configuration, that perform the actual connection. This configuration information includes runtime, publishing, and connection definitions.
Tip
All connections of the same type use the same underlying connector, including its configuration. Overrides that you apply to a connector apply to all current and new connections of that type in the workspace.
Note
In prior releases, Designer Cloud Powered by Trifacta Enterprise Edition maintained relational connection type definitions on the Trifacta node. Beginning in this release, the default definitions are maintained in the new Connector Configuration Service database, and the existing node files contain the customized values for those definitions. You can continue to modify those files directly on the Trifacta node or make changes using the APIs listed below.
Get connector identifier
To use these API endpoints, you must acquire the connector identifier. This value is the vendor
value for a connection of the type. You can acquire this value in one of two ways:
Create a connection of the type in the Trifacta Application. Use the
/v4/connections/:id
endpoint with the GET method to acquire the connection information for your connection. Acquire thevendor
value. https://api.trifacta.com/ee/9.7/index.html#operation/listConnectionsYou may find the
vendor
values listed in the documentation. See Connection Types.
Get connector metadata information - defaults
The following endpoint returns the default metadata information for a specified connector type. This information is stored in the Connector Configuration Service database.
For the :connectorId
value below, use the vendor
value that you acquired above. For example, to acquire connector type definitions for MySQL connection type, use the value mysql
.
Endpoint | /v4/connectorMetadata/:connectorId/defaults |
---|---|
Method | GET |
Description | Get the default metadata for a connector without applying custom overrides. This metadata is used to defined connectivity, ingestion, and publishing for the connector. |
Documentation | https://api.trifacta.com/ee/9.7/index.html#operation/getConnectorDefaults |
Get connector metadata information - current values
The following endpoint acquires the current metadata for a specified connector type, which include the default values with any applicable overrides applied to them.
Endpoint | /v4/connectorMetadata/:connectorId/ |
---|---|
Method | GET |
Description | Get the consolidated metadata for a connector in a given workspace. This metadata is used to defined connectivity, ingestion, and publishing for the connector. |
Documentation | https://api.trifacta.com/ee/9.7/index.html#operation/getConnectorConfig |
Get connector metadata information - get overrides values
The following endpoint retrieves the overrides that have been applied to a specific connector.
Endpoint | /v4/connectorMetadata/:connectorId/overrides |
---|---|
Method | GET |
Description | Get the metadata overrides for a connector in a given workspace. These overrides are applied to the base configuration for connectivity operations. |
Documentation | https://api.trifacta.com/ee/9.7/index.html#operation/getConnectorOverrides |
Create overrides for a connector
The following endpoint applies the specified value or values as overrides to the connector.
Endpoint | /v4/connectorMetadata/:connectorId/overrides |
---|---|
Method | POST |
Description | The specified overrides are merged into the current set of overrides for the connector. A new entry is created if no overrides currently exist. |
Documentation | Tip Overrides are specified in the request body. See the link below for more. https://api.trifacta.com/ee/9.7/index.html#operation/updateConnectorOverrides |
Delete overrides for a connector
The following endpoint deletes all override values for a specified connector.
Endpoint | /v4/connectorMetadata/:connectorId/overrides |
---|---|
Method | DELETE |
Description | All overrides are deleted. The connector reverts to the base configuration. |
Documentation | https://api.trifacta.com/ee/9.7/index.html#operation/deleteConnectorOverrides |
Release 8.0
Deprecation of prior asset transfer endpoint
The following endpoint has been available for transferring assets between users:
/v4/people/{to-userid:}/assetTransfer/{from-userid:}
This endpoint is not compatible with the forward direction of the platform.
Note
The above endpoint will be deprecated in a future release. Please switch to using the new endpoint for transferring assets between users.
For more information, see https://api.trifacta.com/ee/9.7/index.html#operation/transferAssets
Release 7.7
credentialProvider no longer required for /v4/awsConfig
In prior releases, API requests to the /v4/awsConfig
endpoint using the PUT method could receive the following error:
{ "exception": { "name": "ApiValidationFailed", "message": "Message does not adhere to API specification", "details": "'credentialProvider' field in request body must not be null" }}
The credentialProvider
field is not required, and this requirement has been removed from the endpoint. https://api.trifacta.com/ee/9.7/index.html#operation/updateAwsConfig
/v4/awsConfigs PUT method has been deprecated
In prior releases, the /v4/awsConfigs
endpoint supported the use of a PUT method to modify AWS configuration objects.
This endpoint-method combination has been deprecated. The new PATCH method is the following:
Note
The PUT method for this endpoint is still accessible. In a future release, it will be removed from the platform. Please switch to using the PATCH method.
Endpoint | /v4/awsConfigs |
---|---|
Method | PATCH |
Request Body | { "role":"<my_iam_role_object_3>" } |
https://api.trifacta.com/ee/9.7/index.html#operation/updateAwsConfig
For more information on configuring AWS access objects, see API Task - Manage AWS Configurations.
Release 7.5
Flow sharing API now accepts user email addresses
Beginning in Release 7.5, the API has been enhanced to allow insertion of a user's email address as part of the request body. Below is an example request:
Endpoint | /v4/flows/402/permissions/ |
---|---|
Method | POST |
Request Body | "data": [ { "email": "user@example.com", "role": "collaborator", "policy": "flow_editor" } ] } |
If the above returns a 201 - Success
status message, then user@example.com
has been given the role of collaborator
, which uses the flow_editor
policy, for flowId 402.
Tip
You can still use the internal identifier for the user, too.
https://api.trifacta.com/ee/9.7/index.html#operation/shareFlow
Release 7.1
Introducing in-app API reference documentation
Beginning in Release 7.1, API reference documentation is available directly from the Trifacta Application. From the menu bar, select Resources menu > API documentation.
Key features:
More endpoints and attributes are now available!
Reference content comes directly from the codebase.
Searchable and browsable
More content and features will be added to this new capability of the next few releases.
Note
The API reference doc that was published with the product documentation is no longer available. Please use the in-app API reference documentation.
Note
The API reference documentation may require enablement in your environment. For more information, see API Reference.
Task documentation is still available in the product documentation. For more information on these tasks, see API Reference.
API changes for authorization
Release 7.1 introduces authorization, which provides finer-grained access controls to user-defined objects in the platform. For more information, see Changes to User Management.
As a result of authorization, the following changes have been applied to the listed API endpoints.
Connection permissions - POST
Endpoint | /v4/connections/:id/permissions/ |
---|---|
Method | POST |
Change:
When setting permissions, the request body now must include the policyTag
parameter:
Note
This is required.
"policyTag": "connection_viewer",
Parameter | Description |
---|---|
policyTag | Defines the policy level to assign to the change in connection permissions. Accepted values:
|
For more information, see the API reference documentation: https://api.trifacta.com/ee/9.7/index.html#operation/createConnectionPermission
Connection permissions - GET
Endpoint | /v4/connections/:id/permissions/ |
---|---|
Method | GET |
Change:
Response no longer includes connectionPermissions
parameter.
Note
Above is removed.
Response does include the following new parameters:
"policyTag": "connection_viewer", "workspaceAdmin": false, "isCreatedBy": true,
Parameter | Description |
---|---|
policyTag | See previous. |
workspaceAdmin | If |
isCreatedBy | If |
For details on these parameters, please see the API Reference documentation:
https://api.trifacta.com/ee/9.7/index.html#operation/getConnectionPermissions
Connections - GET LIST
Endpoint | /v4/connections |
---|---|
Method | GET |
Change:
Response now includes an authorizationPermission
field in the associatedPeople
block for each connection:
{ "data": [ { "id": 14, .... "associatedPeople": { "data": [ { "id": 1, ... "authorizationPermission": { "policyName": null, "policyTag": "workspace_admin", "resourceOperationList": [ { "operations": [ "execute", "delete", "update", "read", "create", "share" ], "policyTag": "plan_author", "resourceType": "plan" }, { "operations": [ "execute", "delete", "update", "read", "create", "share" ], "policyTag": "flow_author", "resourceType": "flow" },
For details on these parameters, please see the API Reference documentation:
https://api.trifacta.com/ee/9.7/index.html#operation/listConnections
Connections - GET
Endpoint | /v4/connections/:id |
---|---|
Method | GET |
Change:
Same change as previous.
For details on these parameters, please see the API Reference documentation:
https://api.trifacta.com/ee/9.7/index.html#operation/getConnection
People - GET LIST
Endpoint | /v4/people |
---|---|
Method | GET |
Change:
Response now includes the following attributes:
maximalPrivileges
authorizationRoles
Note
Above attributes appear only if the authenticating user is an administrator or the specific user.
{ "data": [ { "id": 29, .... "maximalPrivileges": [ { "operations": [ "delete", "update", "read", "create", "share" ], "policyTag": "connection_author", "resourceType": "connection" }, { "operations": [ "execute", "delete", "update", "read", "create", "share" ], "policyTag": "plan_author", "resourceType": "plan" }, { "operations": [ "execute", "delete", "update", "read", "create", "share" ], "policyTag": "flow_author", "resourceType": "flow" } ], "authorizationRoles": [ { "policyId": 13, "name": "default", "tag": null, "workspaceId": 1, "createdAt": "2020-04-22T07:50:04.502+0000", "updatedAt": "2020-04-22T07:50:04.502+0000", "resourceOperations": [ { "operations": [ "execute", "delete", "update", "read", "create", "share" ], "policyTag": "plan_author", "resourceType": "plan" }, { "operations": [ "execute", "delete", "update", "read", "create", "share" ], "policyTag": "flow_author", "resourceType": "flow" }, { "operations": [ "delete", "update", "read", "create", "share" ], "policyTag": "connection_author", "resourceType": "connection" } ] } ],
For details on these parameters, please see the API Reference documentation:
https://api.trifacta.com/ee/9.7/index.html#operation/listPeople
People - GET
Endpoint | /v4/people/:id |
---|---|
Method | GET |
Change:
Same change as previous.
For details on these parameters, please see the API Reference documentation:
https://api.trifacta.com/ee/9.7/index.html#operation/getPerson
Create Salesforce connection changes
Beginning in Release 7.1, the structure of a Salesforce connection object has been changed. In prior releases, a Salesforce connection could not be shared without also sharing credentials. These changes allow a Salesforce connection to be shared without requiring the sharing of credentials.
Prior to Release 7.1, when creating a Salesforce connection using the APIs, the /v4/connections
POST method required the insertion of a Salesforce security token as part of the params
section of the request:
{ "vendor": "salesforce", "vendorName": "salesforce", "type": "jdbc", "credentialType": "basic", "ssl": true, "name": "Salesforce", "description": "example_salesforce_connection", "disableTypeInference": true, "isGlobal": true, "credentialsShared": true, "host": "salesforce.example.com", "params": { "servername": "myServer", "securityToken": "string" }, "credentials": [ { "username": "string", "password": "string" } ] }
Beginning in Release 7.1, the following changes have been applied to this request structure:
Change
credentialType
tosecurityToken
Move
securityToken
key fromparams
tocredentials
area of the API requestA host and port number value are not required.
{ "vendor": "salesforce", "vendorName": "salesforce", "type": "jdbc", "credentialType": "securityToken", "ssl": true, "name": "Salesforce", "description": "example_salesforce_connection", "disableTypeInference": true, "isGlobal": true, "credentialsShared": true, "host": "salesforce.example.com", "params": { "servername": "myServer" }, "credentials": [ { "username": "string", "password": "string", "securityToken": "string" } ] }
For more information:
Apply overrides to file-based data sources when you run a job
You can now apply overrides to your file-based data sources when you run a job using the APIs. See API Task - Run Job.
Release 7.0
v3 endpoints are no longer available
The v3 version of the API endpoints are no longer available in the platform.
You must use the v4 versions. See API Reference.
Path to file-based imported datasets can be specified by URI
In Release 6.8 and earlier, you could create an imported dataset from a file-based source using a request like the following:
{ "path": "/tri-hdfs/uploads/1/4aee9852-cf92-47a8-8c6a-9ff2adeb3b4a/POS-r02.txt", "type": "hdfs", "bucket": null, "name": "POS-r02b.txt", "description": "POS-r02 - copy" }
Beginning in this release, you can specify the source using a single uri
value:
{ "uri": "hdfs:///tri-hdfs/uploads/1/4aee9852-cf92-47a8-8c6a-9ff2adeb3b4a/POS-r02.txt", "name": "POS-r02b.txt", "description": "POS-r02 - copy" }
Note
The prior format using path
and type
is still supported.
For more information, see
https://api.trifacta.com/ee/9.7/index.html#operation/createImportedDataset
awsRoles GET method removed
Prior to Release 7.0, the platform supported the ability to retrieve awsRole objects based on awsRoleId value.
In Release 7.0 and later, this endpoint has been disabled in the product.
Tip
You can still acquire awsRole identifiers and objects via API. For more information, see
https://api.trifacta.com/ee/9.7/index.html#operation/listAwsRoles
Connections endpoints simplified
Prior to Release 7.0, the request to create a connection looked liked the following:
{ "connectParams": { "vendor": "sqlserver", "vendorName": "sqlserver", "host": "sqlserver.example.com", "port": "1433" }, "host": "sqlserver.example.com", "port": 1433, "vendor": "sqlserver", "params": { "connectStrOpts": "" }, "ssl": false, "vendorName": "sqlserver", "name": "sqlserver_test2", "description": "", "type": "jdbc", "isGlobal": false, "credentialType": "basic", "credentialsShared": true, "disableTypeInference": false, "credentials": [ { "username": "<username>", "password": "<password>" } ] }
In the above, the connectParams
information is duplicated elsewhere in the request.
Beginning in Release 7.0, the connectParams
elements of the Connections endpoint have been removed.
The above request now looks like the following:
{ "host": "sqlserver.example.com", "port": 1433, "vendor": "sqlserver", "params": { "connectStrOpts": "" }, "ssl": false, "vendorName": "sqlserver", "name": "sqlserver_test2", "description": "", "type": "jdbc", "isGlobal": false, "credentialType": "basic", "credentialsShared": true, "disableTypeInference": false, "credentials": [ { "username": "<username>", "password": "<password>" } ] }
Required changes:
The
params
andname
attributes are now required when creating a new connection.If you have downstream scripts that utilize the
connectParams
objects, these must be updated to reference the corresponding attributes after upgrade to Release 7.0 or later.
For more information, see
https://api.trifacta.com/ee/9.7/index.html#operation/getConnection
Publishing for a jobGroup has been simplified
After you have run a job, you can publish the results from the job using the following endpoint:
/v4/jobGroups/<id>/publish
Prior to Release 7.0, the request to submit to the endpoint looked like the following:
{ "connection": { "id": 1 }, "path": ["default"], "table": "test_table", "action": "create", "inputFormat": "pqt", "flowNodeId": 27 }
However, the flowNodeId
value is not necessary, as it can be inferred from the id
value that is part of the endpoint URI.
Beginning in Release 7.0, the request no longer requires the flowNodeId
value:
{ "connection": { "id": 1 }, "path": ["default"], "table": "test_table", "action": "create", "inputFormat": "pqt" }
Note
No changes are required to existing scripts. Values submitted for the flowNodeId
or the outputObjectId
are ignored.
For more information, see
https://api.trifacta.com/ee/9.7/index.html#operation/publishJobGroup
WASB URI format has changed
In Release 6.8 and earlier, the supported format for WASB URIs was the following:
wasbs://blobhost.blob.core.windows.net/container/path/to/file.csv
This format was not an Azure standard. Beginning in Release 7.0, the following standards-based format is supported:
wasbs://container@blobhost.blob.core.windows.net/path/to/file.csv
Note
Any references in your API tooling to the previous WASB UI format must be updated to the new format.
Saving Databricks Personal Access Token has different response
In Release 6.8 and earlier, when saving a Databricks Personal Access Token, the response looked like the following:
Response Code | 204 - No Content |
---|---|
Response Body | Empty. |
Beginning in Release 7.0, the response looks like the following:
Response Code | 200 - Ok |
---|---|
Response Body | { "message": "Databricks Personal Access Token has been stored for user <user_email>" } |
For more information, see
https://api.trifacta.com/ee/9.7/index.html#operation/saveDatabricksAccessToken
Documentation for awsRoles object corrected
In Release 6.8 and earlier, the following issues appeared in the documentation for the awsRoles object. These issues have been corrected in this release:
Inadequate permissions:
The POST and PUT methods for the awsRoles endpoint require either of the following user permissions:
Workspace admin
Alteryx admin
Optional workspaceid/personid attributes:
For the POST and PUT methods for the awsRoles endpoint, you can optionally assign the role to a workspace or person.
See
https://api.trifacta.com/ee/9.7/index.html#operation/createAwsRole
See
https://api.trifacta.com/ee/9.7/index.html#operation/updateAwsRole
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 https://api.trifacta.com/ee/9.7/index.html#operation/transferAssets
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 Task - 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 API Task - Define Deployment Import Mappings.
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.
Note
The endpoints to use to manage flow packages remain unchanged. Similarly, the methods used to define import mapping rules remains unchanged. The API responses that contain flow definitions has changed. See below.
Export and import macros
Beginning in Release 6.8, you can export and import macro definitions via API.
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" } ] }
Note
The old request format is no longer supported.
For more information, see https://api.trifacta.com/ee/9.7/index.html#operation/createConnectionPermission
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
Note
No action is required.
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 byactiveRoleId
, 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 Task - Manage AWS Configurations.
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.
Note
For security reasons, AWSConfig objects must be assigned to users at the time of creation. Admin users can assign to other users. Non-admin users are automatically assigned the AWSConfig objects that they create.
Prior to Release 6.3, AWSConfig objects were assigned through the following endpoint. Example:
/v4/people/2/awsConfigs/6
Note
This endpoint has been removed from the platform. Please update any scripts that reference the above endpoint to manage AWS configuration assignments through the new method described in the following link.
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:
Method | GET |
---|---|
Endpoint | /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 https://api.trifacta.com/ee/9.7/index.html#operation/getJobGroup
Planned End of Life of v3 API endpoints
In Release 6.0, the v3 API endpoints are supported.
Warning
In the next release of Designer Cloud Powered by Trifacta Enterprise Edition after Release 6.0, the v3 API endpoints will be removed from the product (End of Life).
You must migrate to using the v4 API endpoints before upgrading to the next release after Release 6.0.
Release 5.9
Introducing Access Tokens
Each request to the API endpoints of the Designer Cloud Powered by Trifacta platform requires submission of authentication information. In Release 5.1 and earlier:
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.
Note
All previous methods of API authentication are supported in this release. Access tokens is the preferred method of authentication.
The basic process works in the following manner:
API user requests generation of a new token.
This initial request must contain a valid username and password.
Request includes expiration.
Token value is returned in the response.
The token value inserted into the Authorization header of each request to the platform.
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 Trifacta Application.
Note
This feature must be enabled in your instance of the platform. See Enable API Access Tokens.
API: For more information, see https://api.trifacta.com/ee/9.7/index.html#operation/createApiAccessToken
Trifacta Application: For more information, see Access Tokens Page.
For more information on API authentication methods, see https://api.trifacta.com/ee/9.7/index.html#section/Authentication
Release 5.1
None.
Release 5.0
Introducing v4 APIs
Note
NOTE: This feature is in Beta release.
Release 5.0 signals the introduction of version 4 of the REST APIs.
Note
At this time, a very limited number of v4 REST APIs are publicly available. Where possible, you should continue to use the v3 endpoints. For more information, see API Reference.
v4 conventions
The following conventions apply to v4 and later versions of the APIs:
Parameter lists are consistently enveloped in the following manner:
{ "data": [ { ... } ] }
Field names are in
camelCase
and are consistent with the resource name in the URL or with theembed
URL parameter.From early API versions, foreign keys have been replaced with identifiers like the following:
v3 and earlier
v4 and later
"createdBy": 1,
"creator": { "id": 1 },
"updatedBy": 2,
"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
"database": "dbName",
"path": ["dbName"],
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:
Note
In a future release, these endpoints may be migrated to recipe-based endpoints. API users should review this page for each release.
For more information, see Changes to the Object Model.