Review the changes to the publicly available REST APIs for Trifacta® for the current release and past releases.
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 scheduled and API-based 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.
This feature is enabled by default. A workspace administrator can disable the feature if needed.
For more information, see Workspace Settings Page.
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.
Removal of old asset transfer endpoint
The following endpoint for transferring assets between users has been removed from the product:
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:
These endpoints were scheduled for deprecation in Release 8.2 and are not widely used.
Changes for Release 8.2
Asset transfer API using email addresses
- Trifacta Enterprise Edition
- Trifacta Professional Edition
- Trifacta Premium
You can now transfer all assets owned by one user to another user.
NOTE: This feature is available to workspace administrators only.
NOTE: Do not transfer assets from an admin user to a non-admin user. Some options on the shared objects may be lost due to the loss of permissions.
- When a user transfer assets, the level of privilege (viewer, editor, or owner) is transferred with each asset. It is technically possible for a user to own an asset and to have sub-maximal privileges on the asset.
- For shareable assets such as flows and connections, the original owner is downgraded to editor of those assets and any assets scoped within them, such as datasets.
- Schedules are transferred. Time and time zone information in the schedules are not modified during the transfer.
- For non-shareable assets, such as folders and macros, the original owner no longer has access to them at all.
- Participants in the transfer can be identified by email address or internal identifier of the platform.
- Transferring of assets does not check for access to the objects. It's possible that the receiving user may not be able to access connections or datasets that were created by the original user. Examples:
- Original user accessed data through a connection that was shared to the user. Receiving user does not have access to or credentials for the connection.
- Original user had permissions to directories on the backend datastore that the receiving user does not have.
- This endpoint does not delete the user who transferred the assets.
Here is the mapping of example user identifiers:
|role||email address||internal identifier|
Transfer of assets using email:
|Response Status Code|
Transfer of assets using internal identifier:
The following endpoint call transfers assets from userId
4 to userId
|Response Status Code|
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 applicationand 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.
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/:idendpoint with the GET method to acquire the connection information for your connection. Acquire the
vendorvalue. Trifacta API Reference docs: Enterprise | Professional | Premium
- You may find the
vendorvalues 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.
: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
|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.|
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.
|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.|
Get connector metadata information - get overrides values
The following endpoint retrieves the overrides that have been applied to a specific connector.
|Description||Get the metadata overrides for a connector in a given workspace. These overrides are applied to the base configuration for connectivity operations.|
Create overrides for a connector
The following endpoint applies the specified value or values as overrides to the connector.
The specified overrides are merged into the current set of overrides for the connector. A new entry is created if no overrides currently exist.
Delete overrides for a connector
The following endpoint deletes all override values for a specified connector.
All overrides are deleted. The connector reverts to the base configuration.
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:
/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.
For more information on configuring AWS access objects, see API Workflow - Manage AWS Configurations.
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:
If the above returns a
201 - Success status message, then
firstname.lastname@example.org has been given the role of
collaborator, which uses the
flow_editor policy, for flowId
Tip: You can still use the internal identifier for the user, too.
This page has no comments.