How do AI agents use Productboard through Open Connector?

Your user connects Productboard once with one of its cataloged authentication methods. Open Connector stores the credential in an encrypted vault and exposes Productboard tools to your agent over MCP or a typed API, with credentials injected server-side on each call.

Is this a Productboard MCP server?

Yes. Open Connector can serve Productboard as a named MCP server with a scoped allowlist and a per-user connection URL, so any MCP client can call Productboard actions with credentials injected server-side.

Where do Productboard credentials live?

In your own infrastructure. Open Connector keeps credentials in its own vault and injects them at call time, so they never leave your environment.

Productboard integration

Productboard integration for AI agents.

Productboard integration for AI agents with secure authentication and server-side credential injection. Open Connector runs the OAuth, seals the token in an encrypted vault, and serves Productboard tools to your agent over MCP or a typed API — credentials injected server-side, every call audited, nothing leaving your infrastructure. Open source (AGPL-3.0) and self-hostable.

View source on GitHub All integrations →

What your agents can do

Real Productboard actions, managed and audited.

Your user connects Productboard once; your agent can then secure AI-agent actions — scoped to the OAuth permissions you grant and the tool allowlist you configure. Every action is least-privilege and written to a tamper-evident audit trail.

1
Your user grants Productboard access once (OAuth) — the token lands in the vault.
2
Your agent calls a tool over MCP or the typed API; Open Connector injects the credential server-side.
3
Every routed call appends a hash-chained audit record — nothing leaves your infra.

Tools & triggers

Supported Productboard tools.

13 tools are generated from the published Productboard catalog. Descriptions are plain text; each action remains subject to its configured authentication and tool allowlist.

Showing 13 tools. All published catalog entries are included in this page's server-rendered HTML.

Create note: 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.; notes
Create comment: 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.; notes
Create relationship: 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.; notes
Delete note: 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.; notes
Delete relationship: 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.; notes
Get note: 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.; notes
Get configuration: 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.; notes
List configurations: 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.; notes
List relationships: 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.; notes
List notes: 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.; notes
Search notes: 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); notes
Set customer relationship: 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.; notes
Update note: 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.; notes

FAQ

Productboard integration, answered

How do AI agents use Productboard through Open Connector?: Your user connects Productboard once with one of its cataloged authentication methods. Open Connector stores the credential in an encrypted vault and exposes Productboard tools to your agent over MCP or a typed API, with credentials injected server-side on each call.
Is this a Productboard MCP server?: Yes. Open Connector can serve Productboard as a named MCP server with a scoped allowlist and a per-user connection URL, so any MCP client can call Productboard actions with credentials injected server-side.
Where do Productboard credentials live?: In your own infrastructure. Open Connector keeps credentials in its own vault and injects them at call time, so they never leave your environment.

Give your agents Productboard — keep the keys.

Open source, self-hostable, with Productboard credentials that never leave your infrastructure. Run it from source today.

View source on GitHub How the MCP gateway works →