Skip to content
EstiWright Docs

API

The product API is bearer-authenticated JSON over HTTPS; everything the web app does goes through it, so anything you see in the UI is automatable.

Highlights:

  • POST /projects · POST /projects/{id}/documents — create and feed bids
  • POST /projects/{id}/extract-all-requirements-async + status polling
  • GET /usage — credits, per-feature breakdown, legible units
  • GET /documents/{id}/original — your uploaded originals, back out
  • GET /export/workspace — your whole workspace as a JSON bundle, any state
  • GET /onboarding — your first-run checklist, derived from your own work
  • GET/POST /settings/seats · DELETE /settings/seats/{id} — manage your team
  • GET/PUT /settings/overage-budget — cap monthly overage spend
  • GET /settings/sla — your plan’s support commitments
  • POST /support · GET /support — file and list support tickets
  • Import endpoints for band rates and BOQ lines (xlsx, dry-run supported)

Platform operators have a privileged surface under /admin (super-admin only): per-licence billing (/admin/licences/{org}/billing), reconciliation (/admin/reconcile), overage (/admin/overage), and metrics (/admin/metrics).

Refusals are machine-readable: credit and licence refusals return HTTP 402 with a stable code (hard_cap, tier_not_allowed, subscription_inactive) alongside the human-readable reason, and successful calls that cross a spend line say so in X-Quota-* response headers.

OpenAPI reference

Section titled “OpenAPI reference”

The full spec is generated from the running service:

  • Interactive docs — /docs (Swagger UI) and /redoc on any running instance render every endpoint, schema, and the bearer scheme.
  • Machine-readable spec — /openapi.json, also frozen to a versioned openapi.json in the repo (a CI drift-check keeps it current), so you can generate a client without a running server.