Skip to main content

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 for proj_<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.