A REST API over the entire lifecycle

Base URL and authentication

Every endpoint lives under https://oprex.id/api/v1 and is authenticated with an API key you create in your workspace.

# create a key at https://member.oprex.id/panel/settings/api-keys
curl https://oprex.id/api/v1/bugs \
  -H "Authorization: Bearer oprex_pk_…"

Keys carry scopes and, optionally, a resource scope. A key with only read cannot perform any write method — this is enforced centrally on the HTTP method, so it covers every current and future endpoint. A key scoped to one group or project can only address that group or project; without a scope it is tenant-wide.

Shape of a response

Lists return { "data": [...] }; single objects return { "data": {...} }. Errors return { "error": { "code", "message" } } with a meaningful HTTP status. Messages are written to be shown to a human — if one is not, that is a bug worth reporting.

{ "data": [ { "id": "bug_9tK…", "seq": 42, "title": "Checkout retries create duplicate orders",
             "severity": "critical", "status": "confirmed", "projectId": "prj_2mA…" } ] }

Resources

Each family supports the usual list, read, create, and update operations unless the object is inherently immutable. Query parameters filter by project, status, severity, assignee, and free text where it makes sense.

Lifecycle

Defects & work

Knowledge

Platform

Access control applies to the API too

An API key acts on behalf of the person who created it. If per-project access control is enabled for your tenant, the key sees exactly what that person sees — including in aggregate counts. A project you cannot read cannot leak its existence through a statistic.

OAuth 2.1

For tools that connect on a user's behalf rather than holding a static key, Oprex is its own OAuth 2.1 authorization server with PKCE and dynamic client registration. Tokens issued this way behave exactly like API keys — same scoping, same enforcement — so every endpoint on this page works with them unchanged.