Productboard

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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)

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.

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.