CLI & Automation

There is no oprex binary yet. We would rather say that plainly than publish a reference for a tool you cannot install. Everything below works today with tools you already have, and a dedicated CLI is on the roadmap — tell us what you would want it to do.

Set up once

Create an API key, then keep it in your environment rather than in your shell history or a script.

# ~/.zshrc or your CI secret store
export OPREX_TOKEN="oprex_pk_…"
export OPREX_API="https://oprex.id/api/v1"

# a small helper makes the rest readable
oprex() { curl -sS -H "Authorization: Bearer $OPREX_TOKEN" \
  -H "Content-Type: application/json" "$OPREX_API$@"; }

Everyday commands

# what am I working in?
oprex /platform/context | jq '.data.projects[] | {id, name}'

# open critical bugs
oprex "/bugs?status=open&severity=critical" | jq '.data[] | "BUG-\(.seq) \(.title)"'

# file a bug from a failing job
oprex /bugs -X POST -d '{"appKey":"web","appName":"Storefront",
  "title":"Checkout 500 on retry","severity":"critical","projectId":"prj_…"}'

# what shipped recently
oprex /releases | jq '.data[] | {version, title, publishedAt}'

# which requirements have no test
oprex /coverage | jq '.data.rows[] | select(.testCases | length == 0) | .requirement.title'

In continuous integration

Use a key scoped to the one project the pipeline touches, with write only if it genuinely needs to write. Store it as a masked CI variable.

# .gitlab-ci.yml
report_failure:
  stage: test
  when: on_failure
  script:
    - 'curl -sS -X POST "$OPREX_API/bugs"
       -H "Authorization: Bearer $OPREX_TOKEN"
       -H "Content-Type: application/json"
       -d "{\"appKey\":\"ci\",\"appName\":\"Pipeline\",
            \"title\":\"Build failed on $CI_COMMIT_REF_NAME\",
            \"severity\":\"major\",\"projectId\":\"$OPREX_PROJECT\"}"'

Your agent's terminal

For interactive work the MCP integration is almost always better than curl — the agent discovers the objects itself instead of you writing the requests.

claude mcp add --transport http oprex https://oprex.id/mcp \
  --header "Authorization: Bearer $OPREX_TOKEN"

Your repository

Oprex does not host your code — it links to it. Connect a GitLab or GitHub repository to a project and commits, pipelines, and deployments line up with the requirements and bugs they belong to. Your source access stays with your Git provider, so giving someone read access to requirements in Oprex never hands them a key to the code.