# Productboard Public API Documentation ## Guides - [Documentation](https://developer.productboard.com/docs.md): Productboard Public API documentation ## API Reference - [Explore with Postman](https://developer.productboard.com/reference/explore-with-postman.md): Get up and running with the Productboard API v2 in Postman in under 5 minutes. - [Feedback & Help](https://developer.productboard.com/reference/feedback-help.md): Need support? Want to report an issue or suggest improvements? Here’s how to contact us and what to include in your message. - [Getting started](https://developer.productboard.com/reference/getting-started.md): This Quickstart walks you through your first API call using Productboard's REST API v2. In just a few steps, you’ll authenticate, send a request, and see real data come back. - [Company](https://developer.productboard.com/reference/glossary-company.md): A customer or prospect of your product. Companies group users together and help you track feedback and prioritize by customer account. - [Component](https://developer.productboard.com/reference/glossary-component.md): A structural element that organizes features within a product. Components group related features together to create a logical product structure. - [Feature](https://developer.productboard.com/reference/glossary-feature.md): A product capability or functionality that delivers value to users. Features are the primary unit of product planning in Productboard. - [Initiative](https://developer.productboard.com/reference/glossary-initiative.md): A strategic effort that groups related work to achieve a business objective. Initiatives bridge high-level strategy with day-to-day feature work. - [Key Result](https://developer.productboard.com/reference/glossary-key-result.md): A measurable outcome that tracks progress toward an objective. Key results define what success looks like in concrete, quantifiable terms. - [Member](https://developer.productboard.com/reference/glossary-member.md): A person on your team with access to the Productboard workspace. Members are the people who use Productboard to manage products. - [Note](https://developer.productboard.com/reference/glossary-note.md): Customer feedback, ideas, conversations, and insights collected across your product discovery process. Notes are the primary way feedback enters Productboard. - [Objective](https://developer.productboard.com/reference/glossary-objective.md): A high-level goal your organization wants to achieve. Objectives are part of the OKR framework and are supported by measurable key results. - [Product](https://developer.productboard.com/reference/glossary-product.md): The top-level entity in the Productboard hierarchy. Products represent your entire product or service offering and contain components and features. - [Release Group](https://developer.productboard.com/reference/glossary-release-group.md): A collection of related releases that are managed together. Release groups help organize releases across products or time periods. - [Release](https://developer.productboard.com/reference/glossary-release.md): A specific version or deployment of product features to customers. Releases help teams plan what to deliver and when. - [Subfeature](https://developer.productboard.com/reference/glossary-subfeature.md): A smaller, more specific piece of functionality that belongs to a parent feature. Use subfeatures to break down large features into manageable pieces. - [Team](https://developer.productboard.com/reference/glossary-team.md): A group of Productboard members. Teams help organize your workspace by grouping people who work together. - [User](https://developer.productboard.com/reference/glossary-user.md): An individual customer or prospect of your product. Users represent the people who provide feedback and can be grouped into companies. - [Overview](https://developer.productboard.com/reference/introduction.md): Productboard REST API v2 is the next-generation API designed to be more consistent, flexible, and developer-friendly than API v1. - [MCP Server (Beta)](https://developer.productboard.com/reference/mcp-server.md) - [Workflow and prompts](https://developer.productboard.com/reference/mcp-examples.md) - [Connecting your agent](https://developer.productboard.com/reference/mcp-install.md) - [Troubleshooting](https://developer.productboard.com/reference/mcp-troubleshooting.md) - [Migrating from v1 to v2](https://developer.productboard.com/reference/migration-guide.md): A guide for teams moving from API v1 to API v2. Includes key differences, breaking changes, and refactoring recommendations. - [List member activities](https://developer.productboard.com/reference/listmemberactivities.md): Lists member activity data with optional date filtering and pagination. Returns a list of member activity records. - [Create entity](https://developer.productboard.com/reference/createentity.md): 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. - [Create field value](https://developer.productboard.com/reference/createentityfieldvalue.md): 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. - [Create relationship](https://developer.productboard.com/reference/createentityrelationship.md): 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. - [Delete entity](https://developer.productboard.com/reference/deleteentity.md): 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.** - [Delete field value](https://developer.productboard.com/reference/deleteentityfieldvalue.md): 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. - [Delete relationship](https://developer.productboard.com/reference/deleteentityrelationship.md): Removes a relationship between two Entities. Use the `type` query parameter to indicate which kind of relationship you want to remove. - [Get entity](https://developer.productboard.com/reference/getentity.md): 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. - [Get configuration](https://developer.productboard.com/reference/getentityconfiguration.md): 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. - [List entities](https://developer.productboard.com/reference/listentities.md): 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. - [List configurations](https://developer.productboard.com/reference/listentityconfigurations.md): 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. - [List field values](https://developer.productboard.com/reference/listentityfieldvalues.md): 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. - [List relationships](https://developer.productboard.com/reference/listentityrelationships.md): 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). - [Search entities](https://developer.productboard.com/reference/performentitiessearch.md): 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. - [Set parent relationship](https://developer.productboard.com/reference/replaceentityrelationship.md): 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. - [Update entity](https://developer.productboard.com/reference/updateentity.md): 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. - [Update field value](https://developer.productboard.com/reference/updateentityfieldvalue.md): 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. - [Get Jira integration](https://developer.productboard.com/reference/getjiraintegration.md): 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. - [Get Jira integration connection](https://developer.productboard.com/reference/getjiraintegrationconnection.md): 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. - [List Jira integration connections](https://developer.productboard.com/reference/listjiraintegrationconnections.md): 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. - [List Jira integrations](https://developer.productboard.com/reference/listjiraintegrations.md): 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. - [Get member](https://developer.productboard.com/reference/getmember.md): 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]`. - [List members](https://developer.productboard.com/reference/listmembers.md): 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]`. - [Search members](https://developer.productboard.com/reference/performmemberssearch.md): ## 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 - [Create note](https://developer.productboard.com/reference/createnote.md): 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. - [Create relationship](https://developer.productboard.com/reference/createnoterelationship.md): 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. - [Delete relationship](https://developer.productboard.com/reference/delete-note-relationship.md): 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. - [Delete note](https://developer.productboard.com/reference/deletenote.md): 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. - [Get note](https://developer.productboard.com/reference/getnote.md): 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. - [Get configuration](https://developer.productboard.com/reference/getnoteconfiguration.md): 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. - [List configurations](https://developer.productboard.com/reference/listnoteconfigurations.md): 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. - [List relationships](https://developer.productboard.com/reference/listnoterelationships.md): 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. - [List notes](https://developer.productboard.com/reference/listnotes.md): 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. - [Search notes](https://developer.productboard.com/reference/performnotessearch.md): 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) - [Set customer relationship](https://developer.productboard.com/reference/replacenotecustomerrelationship.md): 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. - [Update note](https://developer.productboard.com/reference/updatenote.md): 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. - [Create plugin integration](https://developer.productboard.com/reference/createpluginintegration.md): 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. - [Delete plugin integration](https://developer.productboard.com/reference/deletepluginintegration.md): 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. - [Delete plugin integration connection](https://developer.productboard.com/reference/deletepluginintegrationconnection.md): 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`. - [Get plugin integration](https://developer.productboard.com/reference/getpluginintegration.md): 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). - [Get plugin integration connection](https://developer.productboard.com/reference/getpluginintegrationconnection.md): 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. - [List plugin integration connections](https://developer.productboard.com/reference/listpluginintegrationconnections.md): 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. - [List plugin integrations](https://developer.productboard.com/reference/listpluginintegrations.md): 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. - [Search plugin integration connections](https://developer.productboard.com/reference/searchpluginintegrationconnections.md): 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. - [Update plugin integration](https://developer.productboard.com/reference/updatepluginintegration.md): 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. - [Update plugin integration connection state](https://developer.productboard.com/reference/updatepluginintegrationconnectionstate.md): 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`) - [Create team](https://developer.productboard.com/reference/createteam.md): 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. - [Delete team](https://developer.productboard.com/reference/deleteteam.md): 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.** - [Get team](https://developer.productboard.com/reference/getteam.md): 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. - [List team members](https://developer.productboard.com/reference/listteammembers.md): 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. - [List teams](https://developer.productboard.com/reference/listteams.md): 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. - [Search teams](https://developer.productboard.com/reference/performteamssearch.md): ## 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 - [Update team](https://developer.productboard.com/reference/updateteam.md): 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. - [API Token Authentication](https://developer.productboard.com/reference/api-token.md): Use a personal access token to authenticate API requests. Best for internal tools, scripts, and getting started quickly. - [Authentication](https://developer.productboard.com/reference/authentication.md): All requests to the Productboard REST API v2 must be authenticated. We support four authentication methods to suit different use cases: - [OAuth 2.0 (Authorization Code)](https://developer.productboard.com/reference/oauth-authorization-code.md): Authenticate users via the OAuth 2.0 authorization code flow with consent screens and refreshable tokens. Ideal for public integrations and apps that act on behalf of multiple users. - [OAuth Server-to-Server (JWT)](https://developer.productboard.com/reference/oauth-server-to-server.md): Authenticate backend systems without user interaction. This flow enables server-to-server integrations with short-lived, signed tokens and optional user impersonation. - [Using Configuration Endpoints](https://developer.productboard.com/reference/configuration-endpoint.md) - [Entity IDs in-app](https://developer.productboard.com/reference/entity-ids-in-app.md) - [Field Value Types](https://developer.productboard.com/reference/field-value-types.md): Some endpoints in the Productboard REST API v2 return complex types. These types may include nested objects, arrays, and other structures that allow for more detailed and organized data representation. - [Pagination](https://developer.productboard.com/reference/pagination.md): Some endpoints in the Productboard REST API v2 return paginated results. Instead of returning all records at once, the response includes a limited set of results along with a link to the next page (if more results are available). - [Rate limits](https://developer.productboard.com/reference/rate-limits.md): To ensure fair usage and platform stability, the Productboard API enforces rate limits on incoming requests. - [Response Field Control](https://developer.productboard.com/reference/response-field-control.md): Control which fields are returned in API responses to optimize bandwidth and tailor data to your integration's needs. - [Richtext](https://developer.productboard.com/reference/richtext.md) - [Create webhook subscription](https://developer.productboard.com/reference/createwebhook.md): 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. - [Delete webhook subscription](https://developer.productboard.com/reference/deletewebhook.md): 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. - [Get webhook subscription](https://developer.productboard.com/reference/getwebhook.md): 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). - [List webhook subscriptions](https://developer.productboard.com/reference/listwebhooks.md): 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. ## Recipes - [Features export](https://developer.productboard.com/recipes/features-export.md) ## Changelog - [v2 - 2026-06-18 - Custom field presence filter](https://developer.productboard.com/changelog/2026-06-18.md) - [v2 - 2026-06-15 - Filter entities by team](https://developer.productboard.com/changelog/2026-06-15.md) - [v2 - 2026-06-09 - Filter notes by type](https://developer.productboard.com/changelog/2026-06-09.md) - [v2 - 2026-05-06 - Individual object descriptions](https://developer.productboard.com/changelog/2026-05-06.md) - [v2 - 2026-06-03 - Filter entities by metadata source](https://developer.productboard.com/changelog/2026-06-03.md)