Results — qarunbook API docs

A result is what somebody saw when they tried a check on one platform. Record one from anywhere a test runs, and it sits in the grid beside the ones your testers tapped in.

Record a result

POST/api/v1/resultsKey role tester or above

Records a result for one check on one platform, replacing whatever was recorded there before. The response says what the grid now shows — which is not always what you sent.

Body

checkstringrequired: The check's ref (AUTH-01) with app, or its id alone.
appstring: App id or name. Required when check is a ref or title.
sectionstring: Section id, ref or title, to settle a title more than one section uses.
platformstringrequired: A platform code the app has, e.g. WL. A check marked N/A there answers 400.
resultstringrequired: pass, fail, or retest — which clears the recorded result and puts the check back in the queue.

curl -X POST "https://qarunbook.com/api/v1/results" \
  -H "Authorization: Bearer $QARUNBOOK_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "app": "Checkout",
    "check": "AUTH-01",
    "platform": "IOS",
    "result": "pass"
  }'

Response · 200

{
  "data": {
    "check": {
      "id": "mfq3k2qa7bc",
      "ref": "AUTH-01",
      "title": "Sign in with email and password"
    },
    "app": {
      "id": "mfq3k2p9x1a",
      "name": "Checkout"
    },
    "platform": "IOS",
    "result": "pass",
    "status": "passed",
    "recorded_by": "CI · nightly via API",
    "recorded_at": "2026-09-28T02:14:51.260Z"
  }
}

List results

GET/api/v1/resultsKey role viewer or above

The results recorded now, most recently recorded first. Paged — see Pagination. For a dashboard, a report, or a poller such as Zapier that acts on each new result.

The runbook keeps one result per check per platform, so this is the current state, not an audit log: recording again replaces the row, and retest removes it. Each row's id includes the time it was recorded, so a result recorded again comes back with a new id.

Query parameters

appstring: App id or name. Leave out for every app this key can reach.
checkstring: Only results on this check — its id, or its ref together with app.
platformstring: Only results on this platform code, e.g. IOS.
resultstring: pass, fail or all (default).
limitinteger: 1–200, default 50.
cursorstring: From the previous page's next_cursor.

curl "https://qarunbook.com/api/v1/results?app=Checkout&result=fail" \
  -H "Authorization: Bearer $QARUNBOOK_KEY"

Response · 200

{
  "data": [
    {
      "id": "mfq3k2p9x1a|mfq3k2qa7bc|WL|2026-09-28T02:14:51.260Z",
      "app": {
        "id": "mfq3k2p9x1a",
        "name": "Checkout"
      },
      "check": {
        "id": "mfq3k2qa7bc",
        "ref": "AUTH-01",
        "title": "Sign in with email and password"
      },
      "platform": "WL",
      "result": "fail",
      "status": "failed",
      "recorded_by": "CI · nightly via API",
      "recorded_at": "2026-09-28T02:14:51.260Z"
    }
  ],
  "next_cursor": null
}

Result fields

idstring: app|check|platform|recorded_at. Unique per recording, so safe to deduplicate on.
resultstring: What was recorded: pass or fail.
statusstring: What the grid shows for it now — failed under an open issue, retest after a later fix.
recorded_bystring: The tester's name, or <key name> via API.

What the grid shows

Status is derived, never stored, so a result is one input among several. Three cases are worth knowing before you build on this:

AUTH-01A pass under an open issue still reads failedWLIOS

AUTH-02A fix nobody has checked reads retestWLIOS

AUTH-03A result after the fix clears the retestWLIOS

An open issue wins. Record a pass on a platform with an open issue and the response answers status: "failed" with a note. The pass is kept, and shows once the issue is fixed.
A fix asks for a retest. After an issue is marked fixed, the platforms it affected read retest until a result is recorded — which is exactly what a CI run after the deploy should send.
Retest clears. result: "retest" removes the recorded result. The check reads untested, or retest if a fix is still waiting to be confirmed.

Results are attributed to the key — CI · nightly via API — so anyone reading the grid can tell a machine's pass from a person's.