Duro PLM Connector

Source API Docs Dev Center Connector Changelog

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: duroApiKey

To 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

Retrieves existing and ongoing components or change orders in Duro. Load history once, check for changes on a schedule, or both. | key: pollChangesTrigger

Input	Notes	Example
Connection	The Duro PLM connection to use.
Look-back Date	The date the initial sync starts from, in YYYY-MM-DD format. Cannot be a future date. Leave empty to start from the first recurrence with no backfill. When set, the initial sync seeds each record modified on or after this date once, ignoring the visibility filters.	2026-01-01
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 recurrence. Included when Show New Records is enabled.
Updated records: records modified after the last recurrence. 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

On each scheduled execution, the trigger:

Reads lastPolledAt from the polling state. With no stored position and no Look-back Date, it starts from the current time.
Fetches the selected Resource Type (components or change orders) from Duro, newest first by last-modified time, in pages of 100. It reads until it reaches a record modified at or before the stored position, or until the results end. A record modified exactly at the stored position is not reported.
Reads up to 50 pages per recurrence. When that limit is reached with pages remaining, the trigger stores Duro's continuation cursor, and the next recurrence continues from it, with a warning written to the execution logs.
Classifies each record as new or updated by comparing its created and lastModified timestamps against the stored position. A timestamp strictly after the position counts, and new takes precedence over updated.
Returns the records allowed by Show New Records and Show Updated Records. When none remain, the recurrence is reported as a recurrence with no changes.
Stores the new position only when the read finishes. The position is the time the first recurrence of that read began, not the last, so a record changed while a multi-recurrence read was in progress is picked up by the next read, possibly repeated as an updated record. Downstream steps must tolerate repeats.

Changing the Resource Type while a read is unfinished discards the stored continuation cursor and restarts the read from the newest record.

Initial sync

An initial sync seeds a complete starting state, so inputs that narrow the change feed would leave gaps in it and are ignored for its duration, while inputs that shape how records are fetched still apply. Set a Look-back Date (YYYY-MM-DD, not in the future) to start one: it begins on the first recurrence, seeds each record modified after that date exactly once, and ignores Show New Records and Show Updated Records. The Connection and Resource Type apply throughout.

The window has no fixed upper bound, so a record modified while the sync is still draining is swept into the sync. A sync that reaches the 50-page limit continues from the stored cursor on the next recurrence, and Show New Records and Show Updated Records keep being ignored until the read finishes. At that point the position is set to the time the first recurrence of the sync began, and every later recurrence resumes from there. Later recurrences ignore the Look-back Date, and no field in the payload marks the handoff. The 50-page limit applies per recurrence whether batching is on or off, so a large workspace can span several recurrences either way.

Batching

Batching is enabled per flow on this trigger: each changed record is dispatched as its own execution, or grouped by the configured batch size. Batch size and batch concurrency can both be overridden per instance. Raising concurrency increases the request volume sent to Duro.

To turn it on, select the flow's trigger, open the Flow control tab, and switch on Enable Batching. Under Batch Size, keep Trigger default or choose Custom batch size. Batch Concurrency is optional; leave it blank for no batch-level limit.

Batching splits the records of one recurrence into separate executions. It does not change what the trigger fetches, so the 50-page limit and the position handling described above are the same with batching on or off.

With batching off, a downstream step reads the arrays at body.data.created and body.data.updated. With batching on those fields do not exist: each execution receives one record, or an array of them at a batch size above one, as { "changeType": "created" | "updated", "record": { ... } }. Any step reading the older shape must be updated before batching is enabled. Because batching is enabled per flow, the change is scoped to that flow and leaves other flows using this trigger untouched.

Returned Data

With batching off, 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.

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"
      }
    ]
  }
}

With batching on, each execution receives one tagged item instead, or an array of them when the batch size is above one.

Example Batched Item

{
  "changeType": "updated",
  "record": {
    "id": "666c5a9528e821000815990e",
    "name": "Precision Resistor 10k",
    "created": "2024-06-10T09:12:04.118Z",
    "lastModified": "2024-06-14T14:58:18.069Z"
  }
}

Fields shown are representative. The full response object includes additional properties.

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. A workspace with more changes than fit in the 50-page limit of one recurrence is read across several recurrences.
When both record types are disabled, the trigger fetches records but returns empty arrays.

Example Payload for New and Updated Records⤓

Loading…

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⤓

Loading…

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⤓

Loading…

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⤓

Loading…

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⤓

Loading…

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⤓

Loading…

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⤓

Loading…

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.	`{ components(libraryType: GENERAL) { connection( first: 10 ) { totalCount edges { cursor node { id name created lastModified } } } } }`
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.	`{ "key1": "value1", "key2": "value2" }`

Example Payload for Raw Request⤓

Loading…

Changelog

2026-10-20

Added opt-in batching to the New and Updated Records trigger, dispatching each changed record individually or in configured batches; enabling it changes the shape a downstream step receives
Added an optional Look-back Date input to the New and Updated Records trigger for performing an initial sync of records. The initial sync begins on the first recurrence and backfills every record modified on or after the specified date, seeding each once and ignoring the visibility filters. Leave it empty to start from the first recurrence with no backfill
Fixed the New and Updated Records trigger re-delivering the same newest records on every recurrence and never delivering the older ones when more changes had accumulated than one recurrence could read; it now continues from where the previous recurrence stopped

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

Duro PLM Connector

Description​

API Documentation​

Connections​

API Key​

Prerequisites​

Setup Steps​

Configure the Connection​

Triggers​

New and Updated Records​

How It Works​

Returned Data​

Notes​

Data Sources​

Select Component​

Actions​

Create Change Order​

Get Component by ID​

Get Current User​

List Change Orders​

List Company Users​

List Components​

Raw Request​

Changelog​

2026-10-20​

2026-05-27​

2026-04-30​

2026-03-24​

2026-03-02​

2025-12-08​

2024-06-27​

Description

API Documentation

Connections

API Key

Prerequisites

Setup Steps

Configure the Connection

Triggers

New and Updated Records

How It Works

Returned Data

Notes

Data Sources

Select Component

Actions

Create Change Order

Get Component by ID

Get Current User

List Change Orders

List Company Users

List Components

Raw Request

Changelog

2026-10-20

2026-05-27

2026-04-30

2026-03-24

2026-03-02

2025-12-08

2024-06-27