Projects, templates & exports

Reference for the resource surfaces. All require a bearer token; most are org-scoped via ?org_id=.

Projects

GET    /api/projects?org_id=…
POST   /api/projects
GET    /api/projects/{id}
PATCH  /api/projects/{id}
DELETE /api/projects/{id}
GET    /api/projects/{id}/my-role

Creating:

{
  "organization_id": "…",
  "name": "Staging seed",
  "engine": "postgresql",
  "schema_name": "public"
}

GET /api/projects/{id}/my-role returns your effective role, which is the cheapest way for a client to decide what to enable.

Project members

GET    /api/projects/{id}/members
POST   /api/projects/{id}/members
PATCH  /api/projects/{id}/members/{user_id}
DELETE /api/projects/{id}/members/{user_id}

Roles: owner, admin, editor, data_fabricator, approver, viewer.

Worth understanding: a project with no explicit roster is visible to the whole org. Adding one member restricts it to the roster from that point on. This applies to the org-wide list endpoints too, a project you are not on will not appear in /api/generations.

Templates

GET    /api/templates?org_id=…
POST   /api/templates
PATCH  /api/templates/{id}
DELETE /api/templates/{id}
GET    /api/templates/{id}/schema

Three template packs ship: e-commerce, SaaS and blog. Each is a complete relational schema, tables, columns, foreign keys, usable without pointing at a real database, which makes them the fastest way to try generation.

Snapshots

GET  /api/snapshots?org_id=…                # across the org
GET  /api/projects/{id}/snapshots           # one project
POST /api/projects/{id}/snapshots

A snapshot is a point-in-time capture of a project's schema. Scheduled captures land here too, labelled Scheduled · <name>.

Generations

GET  /api/generations?org_id=…              # across the org
GET  /api/projects/{id}/generations         # one project
POST /api/projects/{id}/generations

One row per run: rows_generated, tables_count, seed, status, timings. Filter with status and project_id.

The row records what ran, not the data itself. Generated rows are streamed to your target and never retained by SeedQL, which is why there is no endpoint to fetch them back.

Exports

GET    /api/exports?org_id=…
GET    /api/exports/{id}/download
DELETE /api/exports/{id}

Usage

GET /api/usage?org_id=…             # current period summary
GET /api/usage/by-project?org_id=…  # per-project breakdown
GET /api/usage/history?org_id=…     # previous periods
GET /api/usage/series?org_id=…      # time series for charting

GET /api/usage returns your tier, rows consumed, the per-request cap and any bonus-row balance. Worth checking before a large push if you are near a limit.

Approvals

GET  /api/run-approvals?org_id=…
POST /api/run-approvals
POST /api/run-approvals/{id}/approve
POST /api/run-approvals/{id}/reject
POST /api/run-approvals/{id}/cancel
POST /api/run-approvals/{id}/consume

Where a workspace requires sign-off before a push, the run is gated on an approval that an approver grants and the push then consumes.

Audit

GET /api/activity?org_id=…              # the org's stream
GET /api/projects/{id}/audit-log        # scoped to one project

The audit log is insert-only. There is no delete endpoint, and that is deliberate: a log the subject can erase is not an audit log.