Productboard

Deletes a Product Management entity by ID. This operation permanently removes the specified entity from your workspace. If the entity has any child entities (e.g. a product with components, or a feature with subfeatures), those children will be **deleted automatically** as part of a cascading delete. **Use this endpoint with caution — deletion is irreversible.** via DELETE /v2/entities/{id}

Removes a relationship between two Entities. Use the `type` query parameter to indicate which kind of relationship you want to remove. via DELETE /v2/entities/{id}/relationships/{type}/{targetId}

Deletes a value (option) from a select-type field (SINGLE_SELECT, MULTI_SELECT, TAG). **STATUS fields are not supported.** Status values are managed through the status lifecycle (not this endpoint) and cannot be deleted here. By default, deletion is rejected if the value is currently assigned to any entities. Use `force` to unset the value from all entities, or `replaceWith` to move all assignments to another value. These two parameters are mutually exclusive - providing both results in a 400 error. via DELETE /v2/entities/fields/{id}/values/{valueId}

Permanently deletes a note from your workspace. This action is irreversible and should be used with caution. Once deleted, the note and all of its content, metadata, and relationships will be removed and cannot be recovered. > To perform a soft-delete (archiving), use an update call instead to set the `archived` flag. via DELETE /v2/notes/{id}

Deletes a relationship between a note and a target entity (customer or link). This is used to unlink a note from: * **customer**: A user or company associated with the note * **link**: A specific feature, component, or other product For customer relationships, the targetId should be the UUID of the customer or organization. For link relationships, the targetId should be the UUID of the feature, component or product entity. > **Note**: For customer relationships, the targetId parameter can be any UUID as it is ignored during deletion. The endpoint will remove all customer relationships from the note regardless of the targetId value provided. via DELETE /v2/notes/{id}/relationships/{targetType}/{targetId}

Permanently deletes a plugin integration and all its associated connections. Entities that previously had connections to this integration will have their push buttons removed. This action cannot be undone. **OAuth2 isolation**: returns `404` if the integration was created by a different OAuth2 application or by a public API access token. via DELETE /v2/plugin-integrations/{integrationId}

Permanently deletes the connection between an entity and the third-party system, resetting the push button to its initial unconnected state. This is equivalent to calling the Configure Connection endpoint with `state: initial`. via DELETE /v2/plugin-integrations/{integrationId}/connections/{entityId}

Permanently deletes a team from your workspace. This operation removes the team and all its membership associations. **Use this endpoint with caution — deletion is irreversible.** via DELETE /v2/teams/{id}

Permanently deletes a webhook subscription. No further notifications will be sent after deletion. **OAuth2 isolation**: returns `404` if the subscription was created by a different OAuth2 application or by a public API access token. via DELETE /v2/webhooks/{webhookId}

Lists member activity data with optional date filtering and pagination. Returns a list of member activity records. via GET /v2/analytics/member-activities

Retrieves a paginated list of Entities. You can filter results, sort them, and control which fields are returned. > Without the `members:pii:read` scope, owner email fields are returned as `[redacted]`. Filtering by `owner[email]` requires the `members:pii:read` scope. Without the `users:pii:read` scope, user entity name and email fields are returned as `[redacted]`. Use the `type[]` query parameter to filter by one or more entity types (e.g. `type[]=feature&type[]=initiative`). Use the `fields` parameter to request only the fields you need. ## Filter availability Not all filters apply to all entity types. For example, `status` filtering is only available for types that have a status field (e.g. `feature`, `initiative`), and `parent[id]` only works for types that have a parent relationship. Use `GET /v2/entities/configurations/{type}` to check which filters are supported for a specific type. The `filters` array in the configuration response lists all available filter parameters, their exact query parameter names, and value schemas. ## Limitations - Only the `AND` operator is supported when applying multiple filters. `OR`, `NOT`, or nested conditions are not supported. via GET /v2/entities

Retrieves all configured fields and values for the specified Entities. Use this endpoint to load complete data for a single entity. > Without the `members:pii:read` scope, owner email is returned as `[redacted]`. Without the `users:pii:read` scope, user entity name and email fields are returned as `[redacted]`. You can limit the fields returned using the `fields` query parameter. via GET /v2/entities/{id}

Retrieves all relationships associated with a specific Entities. This includes parent, child, and linked entities. Use this endpoint to understand how an entity is connected within the product hierarchy or planning structure. The source entity is implicit (this entity). via GET /v2/entities/{id}/relationships

> 🚧 Beta > > This endpoint is in **beta**. Its behavior may change, or it may be removed, > in a future release without notice. We recommend against relying on it in > production integrations. Retrieves the aggregated customer score for a single product hierarchy entity, identified by its UUID. Use this endpoint to see, as a single number, how important an entity is to your customers based on the feedback attached to it and everything below it in the hierarchy. The `id` must be the UUID of a **product hierarchy entity** - a product, component, feature, or subfeature. ## Key Features - Aggregates customer importance ratings on the entity **and all of its descendants** in the product hierarchy. - Ratings are weighted by importance level, and anonymous feedback also contributes: - `critical` × 3 - `important` × 2 - `nice to have` × 1 - `unknown` × 1 - each anonymous note × 1 - `not important` ratings do not contribute to the score. ## Important Notes - Returns a score of `0` when the entity has no customer importance data. - Returns `404` when `id` does not match a product hierarchy entity in your workspace (for example, a company, note, or user ID). via GET /v2/entities/{id}/score

Returns metadata for all available Entities type, including supported fields, patch operations, and validation rules. Use this to programmatically discover what entity types are available for your workspace, which fields are required, what types are available, and how your workspace is configured. via GET /v2/entities/configurations

Returns metadata for a specific Entities type, including supported fields, patch operations, and validation rules. Use this to programmatically discover which fields are required, what types are available, and how your workspace is configured. via GET /v2/entities/configurations/{type}

Returns a paginated list of allowed values for select-type and status fields (SINGLE_SELECT, MULTI_SELECT, TAG, STATUS). Use this endpoint to retrieve all available options for fields with many values, or when you need to paginate through all values. For fields with fewer values (≤1000), the values are returned inline in the field response. For fields with more values, the field response contains a reference to this endpoint. Tag fields are returned using the same `SelectOptionValue` shape as MULTI_SELECT, since tags are multi-select internally. via GET /v2/entities/fields/{id}/values

Returns detail of all Jira integrations. This API is paginated using cursor-based pagination. The client should follow the `links.next` link in the response to fetch the next page. via GET /v2/jira-integrations

Returns detail of a specific Jira integration identified by its UUID. Use this endpoint to retrieve comprehensive information about a single integration including its name, status, creation timestamp, and related resource links. via GET /v2/jira-integrations/{integrationId}

Returns detail of all Productboard feature - Jira issue connections for given integration. It also allows to find a connection by Jira issue key or ID. This API is paginated using cursor-based pagination. The client should follow the `links.next` link in the response to fetch the next page. via GET /v2/jira-integrations/{integrationId}/connections

Returns detail of a specific Productboard feature - Jira issue connection identified by integration UUID and entity UUID. Use this endpoint to retrieve information about the link between a Productboard feature and its corresponding Jira issue. via GET /v2/jira-integrations/{integrationId}/connections/{entityId}

Retrieves a paginated list of members from your workspace. Members represent users who have access to your Productboard workspace. - Members are sorted by creation date, oldest first. - Use the `query` parameter to search by name or email (case-insensitive, partial match). - Use the `roles[]` parameter to filter by role(s). Multiple roles use OR logic (e.g., `roles[]=admin&roles[]=maker`). - Use the `includeDisabled` parameter to include disabled members in the response. - Use the `includeInvited` parameter to include invited members with pending invitations. - Use the `pageCursor` parameter to paginate through results. > Without the `members:pii:read` OAuth scope, PII fields (`name`, `username`, `email`) are returned as `[redacted]`. via GET /v2/members

Retrieves the full details of a specific member by their unique identifier (UUID). Returns the member's profile information including name, username, email address, and workspace role. > Without the `members:pii:read` OAuth scope, PII fields (`name`, `username`, `email`) are returned as `[redacted]`. via GET /v2/members/{id}

Retrieves a list of notes from your workspace. > Without the `members:pii:read` scope, owner and creator email fields are returned as `[redacted]`. Filtering by `owner[email]` or `creator[email]` requires the `members:pii:read` scope. - Notes are sorted by creation date, newest first. - You can filter results using query parameters like `archived`, `processed`, `owner[email]`, `creator[email]`, `metadata[source][system]`, `metadata[source][recordId]`, or date/time ranges. - Use the `pageCursor` parameter to paginate through results. - Use the `fields` query parameter to optimize response size (default: all non-null fields, use `fields=all` to include null values, or `fields=name,tags` for specific fields). > To discover available fields use the [`/v2/notes/configurations`](#/paths/~1v2~1notes~1configurations/get) endpoint. ### Date/Time Filtering You can filter notes by creation or update timestamps using ISO-8601 date-time format: - Use `createdFrom` and `createdTo` to filter by creation date (inclusive bounds) - Use `updatedFrom` and `updatedTo` to filter by update date (inclusive bounds) - All date/time filters can be combined with each other and with other filters - Date ranges must be valid (From <= To) or a 400 error will be returned ### Filtering combinations Some combinations of the `archived` and `processed` flags result in empty or unexpected results. Use the following table to understand which notes are returned based on the filter values: | `archived` | `processed` | Result | |------------|-------------|---------------------------| | – | – | All notes | | `true` | `true` | None | | `true` | `false` | Archived | | `false` | `true` | Processed | | `false` | `false` | Unprocessed | | `true` | – | Archived | | `false` | – | Processed + unprocessed | | – | `true` | Processed | | – | `false` | Archived + unprocessed | > **Note**: Archived notes always return `processed: false` in the API response, regardless of their actual processing state. This is a known limitation of the system. via GET /v2/notes

Retrieves the full details of a specific note by its ID. > Without the `members:pii:read` scope, owner and creator email fields are returned as `[redacted]`. By default, the response includes all non-null fields available in your workspace for that note type (e.g. `textNote`, `conversationNote`). You can optimize the response size by using the `fields` query parameter: - Use `fields=name,tags,content` to retrieve only specific fields - Use `fields=all` to include all fields, even those with null values You can use this endpoint to display the entire note content, including metadata such as owner, tags, and relationships. > Use the [`/v2/notes/configurations`](#/paths/~1v2~1notes~1configurations/get) endpoint to discover which fields are available for your workspace. via GET /v2/notes/{id}

Retrieves all relationships connected to a specific note. This includes: - Customer relationship (either a User or Company entity) - Product link relationships (e.g. linked features) ### Customer relationship rules - A note can have a relationship to **exactly one customer entity** (User or Company). - If the note has a **User** as the customer, and that User is associated with a Company, only the **User** is returned. - If the note has a **User** without a Company, the User is returned. - If the note has a **Company**, the Company is returned. - If the note has no customer relationship, an empty array is returned. ### Product link relationships - Notes can be linked to **multiple Product Management entities** (e.g. features, components). - All such relationships are returned in the same response. > To discover supported relationship types, use the [`/v2/notes/configurations`](#/paths/~1v2~1notes~1configurations/get) endpoint. via GET /v2/notes/{id}/relationships

Returns configuration metadata for note types, including supported fields, patch operations, and validation rules. Use this endpoint to programmatically discover which fields are available, what note types are supported, and how your workspace is configured. ### Filtering by Type By default, this endpoint returns configurations for all available note types (`textNote`, `conversationNote`, `opportunityNote`). You can filter results to specific types using the optional `type[]` query parameter: - `type[]=textNote` - `type[]=textNote&type[]=conversationNote` For backward compatibility, the API also accepts a single `type` query parameter with one value, for example `type=textNote`. Legacy aliases (`simple`, `conversation`, `opportunity`) are also accepted and normalized to the canonical values above. via GET /v2/notes/configurations

Returns configuration metadata for a specific note type, including supported fields, patch operations, and validation rules. Use this endpoint to programmatically discover the configuration for a specific note type. via GET /v2/notes/configurations/{type}

Returns all plugin integrations for the workspace. Paginated using cursor-based pagination. Follow `links.next` to fetch the next page. When `links.next` is `null`, you have reached the last page. **OAuth2 isolation**: OAuth2 access tokens only see integrations created by the same OAuth2 application. Public API access tokens see all workspace integrations. via GET /v2/plugin-integrations

Returns a single plugin integration by ID. **OAuth2 isolation**: returns `404` if the integration was created by a different OAuth2 application or by a public API access token (existence is masked for security). via GET /v2/plugin-integrations/{integrationId}

Returns all connections for a plugin integration, **excluding** those in the `initial` state. The `initial` state is the default — it means no connection has been established for that entity yet. Paginated using cursor-based pagination. Follow `links.next` to fetch the next page. When `links.next` is `null`, you have reached the last page. via GET /v2/plugin-integrations/{integrationId}/connections

Returns the connection for a specific entity within a plugin integration. **Important**: if no connection exists for the entity, this endpoint returns a connection with `state: initial` rather than a `404`. The `initial` state indicates the entity has not yet been pushed to the third-party system. via GET /v2/plugin-integrations/{integrationId}/connections/{entityId}

Retrieves a paginated list of teams from your workspace. Teams represent groups of members that can be used for organizing work and assigning ownership. - Teams are sorted by creation date, newest first. - Use the `name` parameter to filter by name (case-insensitive exact match). - Use the `handle` parameter to filter by handle (case-insensitive exact match). - Use the `query` parameter to search by partial name or handle (case-insensitive). For example, `query=product` will match "Product Team", "My Product", "production", etc. - Use the `pageCursor` parameter to paginate through results. via GET /v2/teams

Retrieves the full details of a specific team by its unique identifier (UUID). Returns the team's name, handle, description, avatar URL, and metadata such as creation and update timestamps. Use this endpoint to load complete data for a single team. via GET /v2/teams/{id}

Returns a paginated list of members belonging to a specific team. Members are sorted by membership creation date, newest first. Member name and email are redacted to `[redacted]` without the `members:pii:read` scope. via GET /v2/teams/{id}/members

Returns all webhook subscriptions for the workspace. Returns up to 100 items per page by default. Paginated using cursor-based pagination. Follow `links.next` in the response to fetch the next page. When `links.next` is `null`, you have reached the last page. **OAuth2 isolation**: OAuth2 access tokens only see subscriptions created by the same OAuth2 application. Public API access tokens see all workspace subscriptions. via GET /v2/webhooks

Returns a single webhook subscription by ID. **OAuth2 isolation**: returns `404` if the subscription was created by a different OAuth2 application or by a public API access token (existence is masked for security). via GET /v2/webhooks/{webhookId}

Updates one or more fields of a Entities. Use `fields` for full replacement of values, or `patch` for granular changes like adding/removing items in list-type fields. You must use either `fields` or `patch` – not both. The `patch` property supports these operations: - `set` – same as setting a value via `fields` - `addItems` – add one or more values to a list field - `removeItems` – remove values from a list field - `clear` – erase the value of the field ## Limitations - Providing both `fields` and `patch` in the same request will return an error. via PATCH /v2/entities/{id}

Updates an existing value (option) for a select-type field (SINGLE_SELECT, MULTI_SELECT, TAG). Only provided fields are updated, omitted fields remain unchanged. **STATUS fields are not supported.** Status values are managed through the status lifecycle (not this endpoint) and cannot be updated here. via PATCH /v2/entities/fields/{id}/values/{valueId}

Updates the values of one or more fields for an existing note. You can update fields using either: - **Field Updates**: Replace entire field values using the `fields` object - **Patch Operations**: Perform granular updates using the `patch` array with operations (`set`, `clear`, `addItems`, `removeItems`) Use this endpoint to update note metadata such as name, owner, tags, or content. Use the [`/v2/notes/configurations`](#/paths/~1v2~1notes~1configurations/get) endpoint to discover available fields and possible patch operations. ### Patch Operations The following patch operations are supported: | Operation | Description | Supported Fields | |-----------|-------------|------------------| | `set` | Set a field to a specific value | All fields | | `clear` | Clear/reset a field to its default value | `owner`, `tags` | | `addItems` | Add items to array fields | `tags`, `content` (conversationNote) | | `removeItems` | Remove items from array fields | `tags`, `content` (conversationNote) | **Field-specific patch operation support:** - **owner**: `set`, `clear` - **tags**: `set`, `clear`, `addItems`, `removeItems` - **archived**: `set` - **processed**: `set` - **name**: `set` - **content** (textNote): `set` - **content** (conversationNote): `set`, `addItems`, `removeItems` ### Known Limitations **Content updates for notes with linked features**: Notes that have content linked to features (via highlights/snippets) cannot have their `content` field updated. Attempting to update the content will return a `422 Unprocessable Entity` error with code `validation.forbidden`. You can still update other fields such as `name`, `owner`, `tags`, `archived`, and `processed` on these notes. **Archive and Processed Field Behavior**: When you set `archived` to `false`, the note will be set to processed automatically by the system. This is a known limitation where unarchiving a note triggers processing regardless of the previous processed state. The `processed` field will reflect the actual processing status after the unarchive operation. via PATCH /v2/notes/{id}

Partially updates a plugin integration. Fields not included in the request preserve their current value. If the integration is `enabled` and `fields.action.url` is updated, Productboard sends a new probe to verify the updated endpoint. No probe is sent when `disabled`. **`action` is write-only**: never returned in responses. via PATCH /v2/plugin-integrations/{integrationId}

Updates the fields and/or members of an existing team. Supports both field updates via `fields` and member management via `patch` operations. Both can be combined in a single request. ## Updatable Fields - `name`: The name of the team (1-255 characters) - `handle`: Unique handle for @mentions (lowercase alphanumeric only) - `description`: Optional description of the team (max 10,000 characters) ## Patch Operations on Members Use `patch` array to manage team members with these operations: - `addItems`: Add members to the team (idempotent, skips already-present members) - `removeItems`: Remove members from the team (idempotent, skips already-absent members) - `set`: Replace entire member list atomically - `clear`: Remove all members from the team Maximum 100 member references per operation. ## Response Returns a reference to the updated team. Use the GET endpoint to retrieve the full updated team details. via PATCH /v2/teams/{id}

Creates a new Entities of the specified type. You must specify the `type` (e.g. `feature`, `initiative`) and provide required fields based on your workspace configuration. Use the `/configuration` endpoint to discover what fields are available and required. ## Limitations - The field names and availability depend on your workspace setup. via POST /v2/entities

Creates a relationship between two Entities. Specify the source entity via the URL path (`{id}`), and the target entity and relationship type in the request body. The `type` field determines the direction and nature of the relationship. Supported values: - `parent` – declare the target as the parent of the source - `child` – declare the target as the child of the source - `link` – create a non-hierarchical connection between entities - `isBlockedBy` – create a dependency between entities - `isBlocking` – create a dependency between entities ## Limitations - Only valid combinations of source and target entities are allowed for each relationship type. - The target entity must exist and be accessible. via POST /v2/entities/{id}/relationships

Creates a new value (option) for a select-type field (SINGLE_SELECT, MULTI_SELECT, TAG). The field must be a select-type field, otherwise the request will be rejected. **STATUS fields are not supported.** Although status values look similar to single-select options, they are managed through the status lifecycle (not this endpoint) and cannot be created here. If `color` is omitted, the system automatically assigns the next available color. via POST /v2/entities/fields/{id}/values

Performs a filtered search over Entities using a POST request. This endpoint supports the same filtering capabilities as `GET /v2/entities`, but allows a larger and more complex payload. It's useful when filtering by a long list of foreign key IDs or when URL length limits become a problem. ## Filter availability Not all filters apply to all entity types. For example, `status` filtering is only available for types that have a status field (e.g. `feature`, `initiative`), and `parent` filtering only works for types that have a parent relationship. Use `GET /v2/entities/configurations/{type}` to check which filters are supported for a specific type. The `filters` array in the configuration response lists all available filter parameters, their exact query parameter names, and value schemas. > Filtering by `owner[email]` requires the `members:pii:read` scope. ## Limitations - Only the `AND` operator is supported when applying multiple filters. `OR`, `NOT`, or nested conditions are not supported. - You can search only within one entity type at a time. via POST /v2/entities/search

## Purpose Performs a filtered search over members using a POST request body. Supports batch lookups by IDs or emails, plus all filters from GET /v2/members. Uses `filter`, `search`, and `return` objects under `data`. ## Key Features - `filter.id`: Filter by member UUIDs (OR logic, max 100) - `filter.fields.email`: Filter by email addresses (OR logic, max 100, requires `members_pii:read` scope) - `filter.fields.role`: Filter by roles (OR logic) - `filter.fields.disabled`: Exclusive filter for disabled members (true = only disabled) - `filter.fields.invitationPending`: Exclusive filter for pending members (true = only pending) - `search.query`: Full-text search on name or email (requires `members_pii:read` scope) - `return.includeDisabled`: Include disabled members alongside active - `return.includeInvitationPending`: Include pending members alongside accepted ## Filter Logic - Multiple values within a filter use **OR** logic (e.g., `filter.id` with two UUIDs) - Different filters use **AND** logic (e.g., `filter.fields.email` AND `filter.fields.role`) - Disabled and invited members are excluded by default - Use `filter.fields.disabled: true` to get **only** disabled members - Use `return.includeDisabled: true` to include disabled **alongside** active members - If both `filter.fields.disabled` and `return.includeDisabled` are set, the filter takes precedence ## Important Notes - The `filter.id` and `filter.fields.email` filters accept at most 100 items each; exceeding this returns a 400 error - Filtering by email or query requires the `members_pii:read` scope; requests without it return a 400 error - Unknown keys in `filter.fields` return a 400 error - Pagination uses cursor-based navigation via `pageCursor` query parameter via POST /v2/members/search

Creates a new note in your workspace. Notes represent individual pieces of feedback from customers, internal teams, or external systems. You must specify the `type` of note you're creating: - `"textNote"` - for plain, unstructured notes - `"conversationNote"` - for structured messages (e.g., from chat, email, or support systems) Legacy aliases (`simple`, `conversation`, `opportunity`) are accepted on input and normalized before business rules are applied. > ⚠️ Notes of type `opportunityNote` cannot be created via the API. ## Field Requirements and Configuration The `fields.name` attribute is **required** for all note types. Other fields depend on the selected note type and your workspace configuration. Use the [`/v2/notes/configurations`](#/paths/~1v2~1notes~1configurations/get) endpoint to discover available fields for each type. Notes can also be linked to Customers entities or Product links (like features) via relationships. via POST /v2/notes

Creates a comment on a note. The comment is attributed to the authenticated user and appears in the note's discussion thread, notifying the note's followers. via POST /v2/notes/{id}/comments

Creates a new relationship between a note and another entity. You can link a note to: - A Product Management entity (e.g. feature, component, initiative) - A customer entity (company or user) This is useful for capturing customer feedback and tying it to the right product link, or for attributing a note to a specific customer. Notes can have **one customer** relationship and **multiple product link** relationships. If a Customer relationship already exists (user or company), this endpoint returns a validation error. Use `PUT /v2/notes/{id}/relationships/customer` to replace an existing Customer relationship. via POST /v2/notes/{id}/relationships

Performs a filtered search over notes using a POST request. This endpoint supports the same filtering capabilities as `GET /v2/notes`, but allows more complex filtering through relationships. > Filtering by owner or creator email requires the `members:pii:read` scope. ### Filter Logic - Multiple values within a filter use **OR** logic (e.g., customer with id1 OR id2) - Different filter types use **AND** logic (e.g., customer AND link filters) ### Relationships Filter notes by their relationships to customers (users or companies) and links (features): - `filter.relationships.customer[].id` - Filter by customer or company UUIDs (OR logic within) - `filter.relationships.link[].id` - Filter by linked feature UUIDs (OR logic within) via POST /v2/notes/search

Creates a new plugin integration. As part of creation, Productboard sends a **probe request** (GET) to your configured action URL to verify it is reachable and intends to receive action notifications. See the `callbacks` section below. The integration is created in the `enabled` state by default. Set `fields.integrationStatus` to `disabled` to skip the probe (useful for staged setup). **`action` is write-only**: the action configuration, including any `headers.authorization` secret, is never returned in responses. via POST /v2/plugin-integrations

Performs a filtered search over plugin integration connections using a POST request. This endpoint supports the same filtering capabilities as `GET /v2/plugin-integrations/{integrationId}/connections`, but accepts filters in the request body instead of query parameters. It's useful when filtering by a long list of entity IDs or when URL length limits become a problem. via POST /v2/plugin-integrations/{integrationId}/connections/search

Creates a new team in your workspace. You must provide the team `name` and a unique `handle` for @mentions. ## Required Fields - `name`: The name of the team (1-255 characters, must be unique per workspace) - `handle`: Unique handle for @mentions (lowercase alphanumeric only, 1-255 characters, must be unique per workspace) ## Response Returns a reference to the created team with its ID and self link. Use the GET endpoint to retrieve the full team details. via POST /v2/teams

## Purpose Performs a filtered search over teams using a POST request. Use this endpoint for batch lookups by IDs, names, or handles when query string filters are insufficient. ## Request Format Uses structured `filter` and `search` objects. ## Key Features - `filter.id`: Filter by team UUIDs (OR logic, max 100) - `filter.fields.name`: Filter by team name, case-insensitive (single string or array, OR logic) - `filter.fields.handle`: Filter by team handle, case-insensitive (single string or array, OR logic) - `search.query`: Full-text search on team name and handle (case-insensitive partial match) - Returns the same response format as `GET /v2/teams` ## Filter Logic - Multiple values within a single filter use **OR** logic (e.g., `filter.fields.name: ["A", "B"]` returns teams named A or B) - Different filter types and search use **AND** logic (e.g., `filter` AND `search` = intersection) - Empty request returns all teams (same as `GET /v2/teams`) ## Important Notes - Each filter array accepts at most 100 items; exceeding this returns a 400 error - Pagination uses cursor-based navigation via `pageCursor` query parameter via POST /v2/teams/search

Creates a new webhook subscription to be actively notified on each change in the specified entities. As part of subscription creation, Productboard validates the notification URL: it must use `https`, have a publicly resolvable host, and not point to localhost, loopback, site-local, or internal addresses. **Scope requirements**: the OAuth2 application must have the scopes required by all requested event types. via POST /v2/webhooks

Replaces the parent of a specific Entities. Some entity types (such as features and subfeatures) are required to have a parent. This endpoint allows you to update the parent entity when the relationship changes. The new parent is specified in the request body using the `target.id` field. ## Limitations - Only valid parent relationships are allowed (e.g. feature → component, subfeature → feature). - The target entity must exist and be a valid parent type. - This will overwrite any existing parent relationship. via PUT /v2/entities/{id}/relationships/parent

Sets or replaces the customer relationship of a note. * A note can be linked to **one customer only** — either a User or a Company. * If a customer relationship already exists, it will be **replaced** with the new one provided. This is useful for attributing feedback to the correct user or company, especially when syncing notes from support systems or CRMs. > To remove the customer relationship completely, use the `DELETE /v2/notes/{id}/relationships/customer/{targetId}` endpoint. via PUT /v2/notes/{id}/relationships/customer

Creates or replaces the connection state for a specific entity within a plugin integration. This is an **upsert** — if no connection exists it is created; if one exists it is replaced. **Connection states:** | State | Effect | |---|---| | `connected` | Entity is linked; push button shows connection details | | `error` | Connection failed; push button shows error state | | `progress` | Processing asynchronously; push button shows loading indicator | | `initial` | Equivalent to deleting the connection; push button resets | **Async processing flow:** 1. User clicks push button → your endpoint receives an action notification 2. Respond immediately with `state: progress` to show a loading indicator 3. Process the action asynchronously 4. Call this endpoint with the final state (`connected` or `error`) via PUT /v2/plugin-integrations/{integrationId}/connections/{entityId}