Duro PLM Connector
Description
Duro PLM is a cloud based Product Lifecycle Management (PLM) platform for managing part data, change orders, and product development workflows. This component allows managing products, components, change orders, and other resources in a Duro workspace.
API Documentation
This component was built using the Duro GraphQL API Reference.
Connections
API Key
key: duroApiKeyTo authenticate with Duro PLM, an API key is required.
Prerequisites
- A Duro account
- Access to account settings with permissions to generate API keys
Setup Steps
To generate an API key:
- Navigate to the Duro application and log in to the account
- Click the user avatar in the top right corner and select Account settings
- In the Settings menu, select the Integrations tab
- Click the Get API Key button below the Integrations table
- Copy the displayed API key value
Refer to the Duro GraphQL API documentation for additional information about API authentication.
Configure the Connection
Enter the following values in the connection configuration:
- API Key: The API key generated from the Duro account settings
- Duro Environment: Select the appropriate environment based on data residency requirements:
- Main (MFG): Standard production environment for most accounts
- ITAR: US Government ITAR-compliant environment
- EU: European data residency environment
- Custom Duro Environment (Optional): Provide a custom GraphQL endpoint URL to override the selected environment. Use this for private Duro instances or custom deployments.
| Input | Notes | Example |
|---|---|---|
| Custom Duro Environment | If provided, this will override the selected Duro Environment. Use for private Duro instances or custom deployments. | https://custom-instance.duro.app/graphql |
| Duro Environment | The Duro GraphQL endpoint. Select based on data residency requirements: Main (MFG) for standard accounts, ITAR for US government compliance, or EU for European data residency. | https://mfg.duro.app/graphql |
| API Key | The API key for the Duro account. Generate an API key in Duro account settings under the Integrations tab. | eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0 |
Triggers
New and Updated Records
Checks for new and updated components or change orders in Duro on a configured schedule. | key: pollChangesTrigger
| Input | Notes | Example |
|---|---|---|
| Connection | The Duro PLM connection to use. | |
| Resource Type | The type of resource to poll for changes. | components |
| Show New Records | When true, newly created records are included in the trigger output. | true |
| Show Updated Records | When true, records updated after the last poll are included in the trigger output. | true |
This trigger polls Duro for new and updated components or change orders on a configured schedule. Use it to drive a flow whenever records are created or modified in a Duro workspace, without relying on an external webhook subscription.
The trigger detects two kinds of changes, each of which can be toggled independently:
- New records: records created after the last successful poll. Included when Show New Records is enabled.
- Updated records: records modified after the last successful poll. Included when Show Updated Records is enabled.
A record that is both newly created and modified within the same window is reported as a new record, since creation takes precedence over update.
How It Works
- The trigger runs on the configured schedule and reads the timestamp of the last successful poll from its stored state. On the first run, the current time is used as the baseline.
- It fetches the selected resource type (components or change orders) from Duro, paging through results until the available records are retrieved or a safety page cap is reached.
- Each record is classified as new or updated by comparing its
createdandlastModifiedtimestamps against the last poll time. New records take precedence over updated records. - Records are filtered according to the Show New Records and Show Updated Records settings before being returned.
- The stored state is advanced to the current poll time so the next run only reports changes that occur afterward.
State management uses an at-least-once delivery model. When a poll retrieves every available record, the cursor advances to the current time. When the page cap is reached and older records have not yet been retrieved, the cursor is held at the previous poll time so the remaining records are delivered on the next run rather than being skipped. As a result, a record may occasionally be delivered more than once, so downstream steps must tolerate repeats.
Returned Data
The trigger returns an object whose body.data contains two arrays: created for new records and updated for modified records. Each record includes its identifier, name, and creation and modification timestamps.
Fields shown are representative. The full response object includes additional properties.
Example Response (Polling)
{
"data": {
"created": [
{
"id": "666c5a8828e82100081595b0",
"name": "High-Performance IC",
"created": "2024-06-14T14:58:16.638Z",
"lastModified": "2024-06-14T14:58:16.638Z"
}
],
"updated": [
{
"id": "666c5a9528e821000815990e",
"name": "Precision Resistor 10k",
"created": "2024-06-10T09:12:04.118Z",
"lastModified": "2024-06-14T14:58:18.069Z"
}
]
}
}
Notes
- The resource type, Show New Records, and Show Updated Records settings are presented in the integration configuration UI and do not require manual setup here.
- Duro serves results newest-first without a server-side time filter, so the trigger filters by timestamp after fetching. Very frequent schedules on high-volume workspaces may approach the per-poll page cap, in which case remaining records are delivered on subsequent runs.
- When both record types are disabled, the trigger fetches records but returns empty arrays.
Example Payload for New and Updated Records⤓
Data Sources
Select Component
A picklist of components in your library. | key: selectComponent | type: picklist
| Input | Notes | Example |
|---|---|---|
| Connection | The Duro PLM connection to use. | |
| First N Items | The number of items to return. | 10 |
| Library Type | The type of library to query. Company (GENERAL) contains shared production components, while Sandbox (PERSONAL) contains personal or test components. | GENERAL |
Actions
Create Change Order
Creates a draft change order. | key: createChangeOrder
| Input | Notes | Example |
|---|---|---|
| Connection | The Duro PLM connection to use. | |
| Description | A detailed description of the change order, including the reason for the change and expected impact. | Replace aluminum housing with stainless steel to improve corrosion resistance in marine environments. |
| Name | The name of the change order to create. | ECO-2024-001: Update Component Materials |
| Type | The type of change order to create. ECO (Engineering Change Order), MCO (Manufacturing Change Order), or DCO (Document Change Order). | ECO |
Example Payload for Create Change Order⤓
Get Component by ID
Get a specific component by a unique identifier | key: getComponentById
| Input | Notes | Example |
|---|---|---|
| Component ID | The unique identifier for the component to retrieve. | 666c5a9528e821000815990e |
| Connection | The Duro PLM connection to use. |
Example Payload for Get Component by ID⤓
Get Current User
Get information about the currently authenticated user | key: getCurrentUser
| Input | Notes | Example |
|---|---|---|
| Connection | The Duro PLM connection to use. |
Example Payload for Get Current User⤓
List Change Orders
Retrieves a list of change orders. | key: listChangeOrders
| Input | Notes | Example |
|---|---|---|
| Connection | The Duro PLM connection to use. | |
| First N Items | The number of items to return. | 10 |
| Order By | The field and direction to sort the change orders by. Results will be returned in the specified order. | [{"con": "asc"}] |
Example Payload for List Change Orders⤓
List Company Users
Retrieves account information for each user in the company library. | key: listCompanyUsers
| Input | Notes | Example |
|---|---|---|
| Connection | The Duro PLM connection to use. |
Example Payload for List Company Users⤓
List Components
Retrieves a list of components. | key: listComponents
| Input | Notes | Example |
|---|---|---|
| Connection | The Duro PLM connection to use. | |
| First N Items | The number of items to return. | 10 |
| Library Type | The type of library to query. Company (GENERAL) contains shared production components, while Sandbox (PERSONAL) contains personal or test components. | GENERAL |
Example Payload for List Components⤓
Raw Request
Make a generic request to the Duro API | key: rawRequest
| Input | Notes | Example |
|---|---|---|
| Connection | The Duro PLM connection to use. | |
| Query or Mutation | GraphQL query or mutation to execute against the Duro API. See the Duro GraphQL API documentation for available queries and mutations. | |
| Variables | GraphQL variables to pass to the query or mutation. Each variable should be a key-value pair. | {"userId": "12345", "status": "active"} |
| Variables Object | Alternative way to provide GraphQL variables as a JSON object. Use this instead of the Variables field for complex nested variables. |
Example Payload for Raw Request⤓
Changelog
2026-05-27
Added New and Updated Records polling trigger that checks for newly created and recently modified components or change orders on a configured schedule
2026-04-30
Updated spectral version
2026-03-24
Added Component ID input to the Select Component inline data source for selecting components from a dropdown
2026-03-02
Added global debug logging across all actions for improved troubleshooting of API requests and responses
2025-12-08
Enhanced Duro API connection with expanded environment support:
- Added EU environment option for European data residency
- Added custom Duro environment field for private or testing environments
2024-06-27
Initial release of Duro PLM component with product lifecycle management capabilities