Workspaces - Feedspace API Documentation

Workspaces are the top-level containers for all your reviews, forms, widgets, and pages. Most tools require a workspace ID, so call list_workspaces first to get it.

Available Tools

Tool	Description	Try asking
`list_workspaces`	List all your workspaces, with your role in each. Typically the first tool called in any workflow	”List my Feedspace workspaces”
`get_workspace`	Get a workspace’s setup status: review counts and whether a form, page, widget, or custom domain exists yet	”Show me the setup status of my workspace”
`create_workspace`	Create a new workspace with a name, and optional website URL and public slug	”Create a new workspace called ‘My SaaS Product‘“
`update_workspace`	Update a workspace’s name, website URL, or public slug	”Rename my workspace to ‘Acme Reviews‘“
`get_workspace_branding`	Pull a brand’s colours, logo, and favicon from a website and apply them to the workspace	”Extract the branding from my website at example.com”

Despite its name, get_workspace_branding writes. As well as returning the colours it finds, it saves the fetched logo and favicon onto the workspace, the same as the web app’s fetch. It is not a read-only lookup.

get_workspace does not report permissions. It returns a permissions field, but the value is null. Your role in a workspace comes from list_workspaces, which returns a role field (owner, admin, editor, or viewer) for every workspace.

Which Workspace ID to Use

Every workspace has two identifiers, and only one of them works with the API:

unique_workspace_id is the string identifier used everywhere. It is sent as the fs-workspace-id header and used as the path segment for workspace-scoped routes.
id is numeric and is not accepted. Passing it where unique_workspace_id is expected returns a 404 “workspace not found”.

list_workspaces returns both, so always carry the unique_workspace_id value forward.