Projects
A project is a named container for content inside a workspace — typically one personal-brand profile or one company page. Notes, posts, sources, and queue slots all attach to a project. The v1 API exposes a paginated list of the workspace’s projects and a single-project read. Both are read-only in v1; mutating projects (creation, archive, pause) is dashboard-only.GET /v1/projects
List the projects the authenticated workspace owns, ordered by creation
time descending.
Query parameters
Response
Field reference
Internal fields like the workspace’s owner user id, billing customer id,
and onboarding flags are intentionally not in this response. If you
need them, use the dashboard.
GET /v1/projects/{projectId}
Single project read. Returns the same shape as above, wrapped in a data
field for symmetry with future write endpoints.
Response
Errors
Cross-workspace isolation
Every project read is scoped by the API key’s workspace. A request forproj_<other-workspace> returns 404 not_found — never a 403, so
attackers cannot enumerate which project ids exist outside their
workspace.
The same isolation applies to the list endpoint: you only see your own
workspace’s projects, and the pagination cursor is bound to that filter.
You cannot inflate the result set by replaying another workspace’s
cursor — the embedded (createdAt, id) keyset is workspace-agnostic, so
it just no-ops against your own data.
What’s NOT here (yet)
- Filtering by status / type. v1 returns all projects, regardless of
status. Filter client-side. A
?status=parameter will land in v1.1 if there’s demand. - Project metrics. Engagement and analytics live behind the dashboard for now. Aggregated metrics endpoints are queued for Phase 4.
- Write endpoints. Creating, pausing, or archiving a project is dashboard-only in v1.