PDQ Connector

SourceAPI DocsAPI ChangelogConnector Changelog

Description

PDQ provides a suite of management tools to automate software deployment, manage patches, and track inventory across a company’s networks.

Use the PDQ component to manage deployments, devices, groups, and packages.

API Documentation:

The component was built using the PDQ V1 API

Connections

API Key

key: pdq-api-key

Follow these steps to generate a new API key in PDQ:

1. Log in to the PDQ Connect account and select the settings icon represented by a cog located in the lower left corner.
2. Navigate to the API keys section and select Create API Key.
3. Provide a unique name for the API key and select Create.
4. Copy and save the generated API key as it will not be shown again.
5. Enter the generated API key into the connection configuration of the integration.

Input	Notes	Example
API Key	The API key generated from the PDQ Connect settings page. See PDQ Connect API.	pdq_a1b2c3d4e5f67890a1b2c3d4e5f67890

Triggers

New Records

Retrieves existing and ongoing records for a specified PDQ resource type. Load history once, check for changes on a schedule, or both. | key: pollChangesTrigger

Input	Notes	Example
Connection	The PDQ 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.	2026-01-01
Resource Type	Select the PDQ resource to poll for newly added records. Choose Devices or Groups. Required.	Devices

This trigger polls PDQ on a configured schedule and emits Devices or Groups that were added since the previous run. It is a convenient alternative for reacting to newly inventoried resources without manual checks.

How It Works

PDQ's list endpoints expose an insertedAt (creation) timestamp on each record but no modification timestamp, and no confirmed server-side date filter. On each scheduled run the trigger pages through records of the selected resource newest first (sorted by insertedAtDesc), stops at the first page that reaches the previous poll time, and keeps only those whose insertedAt is after it. The current run time is stored as the cursor for the next run.

• First run (without a Look-back Date): the very first execution records the cursor and emits nothing, so an instance does not receive a backlog of historical records on deploy.
• Subsequent runs: only records added since the last run are returned.

Initial Sync

An initial sync seeds a starting state from history. The trigger has no input that narrows which records are reported, so an initial sync ignores none. It begins on the first recurrence, when the trigger has no stored position and a Look-back Date (YYYY-MM-DD) is set, and delivers every record whose insertedAt is after that date.

The window has no fixed upper bound and no per-recurrence cap: the trigger pages newest first until it reaches a record inserted at or before the look-back date, whether batching is on or off, so the sync completes in one recurrence. The position is then set to the wall-clock time at which that recurrence started, not to the newest record received, and the first incremental recurrence resumes from there. Nothing in the payload marks the handoff. Records are not de-duplicated, so a record inserted while the pages are read can shift a page boundary and cause another record to be delivered twice.

Resource Type still applies. The trigger has no page-size or field-selection input.

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 PDQ.

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.

With batching off a downstream step reads body.data.created. With batching on that field does not exist: each execution receives one { "changeType": "created", "record": ... } item, or an array of them when the batch size is greater than 1. Any step reading the older shape must be updated before batching is enabled. Because batching is enabled per flow, that change is scoped to the flow rather than to the component or to other flows using the same trigger.

Returned Data

The trigger returns the newly added records under data.created. Fields shown are representative. The full response object includes additional properties.

Example Payload

{
  "data": {
    "created": [
      {
        "id": "dvc_1bced782734040a581d",
        "name": "LAB01",
        "hostname": "LAB01",
        "insertedAt": "2024-01-01T00:00:00.000000Z"
      }
    ]
  }
}

Notes

• This trigger detects new records only. PDQ exposes a creation timestamp (insertedAt) but no modification timestamp, so edits to existing devices or groups are not detected.
• Because there is no confirmed server-side date filter, each run reads pages newest first until it reaches the previous poll time and filters them in memory.

Example Payload for New Records⤓

Loading…

---

Data Sources

Select Device

Select a Device from a dropdown menu. | key: selectDevice | type: picklist

Input	Notes	Example
Connection	The PDQ connection to use.

Example Payload for Select Device⤓

Loading…

---

Select Group

Select a Group from a dropdown menu. | key: selectGroup | type: picklist

Input	Notes	Example
Connection	The PDQ connection to use.

Example Payload for Select Group⤓

Loading…

---

Select Package

Select a Package from a dropdown menu. | key: selectPackage | type: picklist

Input	Notes	Example
Connection	The PDQ connection to use.

Example Payload for Select Package⤓

Loading…

---

Actions

Create Deployment

Deploy a package version to target devices or groups. | key: createDeployment

Input	Notes	Example
Connection	The PDQ connection to use.
Package ID	The package id to deploy.	pkg_123abc
Targets	Comma-delimited Device IDs or Group IDs.	grp_123abc,dvc_123abc

Example Payload for Create Deployment⤓

Loading…

---

Get Device

Retrieve a device by ID. | key: getDevice

Input	Notes	Example
Connection	The PDQ connection to use.
Device ID	The ID of the device to retrieve.	123456

Example Payload for Get Device⤓

Loading…

---

Get Package

Retrieve a package by ID. | key: getPackage

Input	Notes	Example
Connection	The PDQ connection to use.
Package ID	The unique identifier for the package to retrieve.	123456

Example Payload for Get Package⤓

Loading…

---

List Devices

Retrieve a list of devices. | key: listDevices

Input	Notes	Example
Connection	The PDQ connection to use.
Custom Query Params	Additional query parameters to include in the request.	key1=value1
Fetch All	When true, automatically fetches all pages of results using pagination.	false
Filters	Optional query controls to sort and refine the results.
Group ID	The id of the group to filter by.	123456
Includes	Include related resources.	networking,processors
Pagination	Page number and page size to control result paging.

Example Payload for List Devices⤓

Loading…

---

List Groups

Retrieve a list of groups. | key: listGroups

Input	Notes	Example
Connection	The PDQ connection to use.
Custom Query Params	Additional query parameters to include in the request.	key1=value1
Fetch All	When true, automatically fetches all pages of results using pagination.	false
Filters	Optional query controls to sort and refine the results.
Pagination	Page number and page size to control result paging.

Example Payload for List Groups⤓

Loading…

---

List Packages

Retrieve a list of packages. | key: listPackages

Input	Notes	Example
Connection	The PDQ connection to use.
Custom Query Params	Additional query parameters to include in the request.	key1=value1
Fetch All	When true, automatically fetches all pages of results using pagination.	false
Filters	Optional query controls to sort and refine the results.
Pagination	Page number and page size to control result paging.

Example Payload for List Packages⤓

Loading…

---

Raw Request

Send raw HTTP request to the PDQ API. | key: rawRequest

Input	Notes	Example
Connection	The PDQ connection to use.
Data	The HTTP body payload to send to the URL.	{"exampleKey": "Example Data"}
File Data	File Data to be sent as a multipart form upload.	[{key: "example.txt", value: "My File Contents"}]
File Data File Names	File names to apply to the file data inputs. Keys must match the file data keys above.
Form Data	The Form Data to be sent as a multipart form upload.	[{"key": "Example Key", "value": new Buffer("Hello World")}]
Header	A list of headers to send with the request.	User-Agent: curl/7.64.1
Max Retry Count	The maximum number of retries to attempt. Specify 0 for no retries.	0
Method	The HTTP method to use.
Query Parameter	A list of query parameters to send with the request. This is the portion at the end of the URL similar to ?key1=value1&key2=value2.
Response Type	The type of data you expect in the response. You can request json, text, or binary data.	json
Retry On All Errors	If true, retries on all erroneous responses regardless of type. This is helpful when retrying after HTTP 429 or other 3xx or 4xx errors. Otherwise, only retries on HTTP 5xx and network errors.	false
Retry Delay (ms)	The delay in milliseconds between retries. This is used when 'Use Exponential Backoff' is disabled.	0
Timeout	The maximum time that a client will await a response to its request	2000
URL	Input the path only (/deployments), The base URL is already included (https://app.pdq.com/v1/api). For example, to connect to https://app.pdq.com/v1/api/deployments, only /deployments is entered in this field. e.g. /deployments	/deployments
Use Exponential Backoff	Specifies whether to use a pre-defined exponential backoff strategy for retries. When enabled, 'Retry Delay (ms)' is ignored.	false

---

Changelog

2026-10-13

• Added opt-in batching to the New 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 for performing an initial sync of records. The initial sync backfills every record inserted after the specified date, seeding each once; later recurrences are unaffected. Leave it empty to start from the first recurrence with no backfill

2026-08-14

Enhanced action configuration and connection security:

• Grouped the paging and query-control inputs on List Devices, List Groups, and List Packages into the Pagination and Filters structured objects; Fetch All remains a top-level toggle
• Fixed List Devices to send configured custom query parameters, which were previously discarded
• Changed the API Key connection field to a masked password field
• Added output schemas to the Create Deployment, Get Device, List Devices, List Groups, Get Package, and List Packages actions for improved field mapping during configuration
• Added inline action calling support across all actions for improved example output during configuration

2026-06-09

Added the New Records polling trigger for Devices and Groups, which checks for records added since the last run

2026-04-30

Updated spectral version

2025-08-29

Added data sources and inline data sources for Devices, Groups, and Packages:

• Updated all string input placeholders to follow Guru standards (using "Enter..." pattern)
• Fixed connection label to follow standards (removed component name from label)
• Added marketing categories configuration