Feeding Launch Readiness (Deploys & Tests)

Launch Readiness rolls up a single 0–100% score from five checks. Three of them populate themselves from data already in iKanban; two are fed by your own pipeline. This page explains how to feed them — the same way iKanban tracks its own delivery (DORA) metrics.

Use Releases to create releases and assign issues. For progress charts and scope change, see Release Analysis; that view is separate from this readiness score.

What feeds each axis

Scope, Quality and Ops need nothing — keep your issues and checklist up to date. Verification and Stability are the two you wire up.

Step 1 — Create an API key

Go to Settings → API Keys and create a key. Store it in your CI secret manager and send it as a bearer token. The deployment and test-run routes shown here are agent-facing routes that accept API-key authentication; this does not make every /api route available to API keys. See Setup and Access for browser-session-only operations.

Authorization: Bearer vk_your_key_here

Step 2 — Stability: report each deploy

Every time you deploy, POST a record. Start it when the deploy begins, then mark success/failure when it finishes.

Start a deploy

curl -s -X POST "https://api.i-kanban.com/api/deployments" \
  -H "Authorization: Bearer $IKANBAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "app_name": "frontend",
        "environment": "prod",
        "commit_sha": "'"$GIT_SHA"'",
        "deployed_by": "ci",
        "status": "started"
      }'
# → returns { "data": { "id": "<deployment-id>", ... } }

Finish it (set the outcome + duration):

curl -s -X PUT "https://api.i-kanban.com/api/deployments/<deployment-id>" \
  -H "Authorization: Bearer $IKANBAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "status": "success", "duration_seconds": 92 }'

Fields: app_name (must match your project name so the release can attribute it), environment (dev / prod / …), commit_sha, optional version / deployed_by, and status (started → success | failure). Stability = the change-failure rate over these records in the release window.

app_name must be the name of a project the key's owner can reach. Any other name answers 404, so the record cannot land on another team's project. If the key's owner reaches two projects with that name, the call answers 400: add project_id to say which one, so a record never lands on a guess. A project_id must be a project of that name that the key's owner can reach, or the call answers 404. Each record belongs to that project: only its members read or update it with GET /api/deployments?app_name=<name> and PUT, and Stability counts only that project's records. A record saved before records carried a project counts in neither the score nor the drill-down. GET /api/deployments without app_name and GET /api/deployments/stats cover every team, so they answer 403 unless you are an iKanban superadmin. deployed_by_email, if you send it, must be the key owner's own address, and otherwise the record drops it.

GitHub Actions example

- name: Report deploy to iKanban
  if: always()
  run: |
    STATUS=${{ job.status == 'success' && 'success' || 'failure' }}
    curl -s -X POST "https://api.i-kanban.com/api/deployments" \
      -H "Authorization: Bearer ${{ secrets.IKANBAN_API_KEY }}" \
      -H "Content-Type: application/json" \
      -d "{\"app_name\":\"frontend\",\"environment\":\"prod\",\"deployed_by\":\"github-actions\",\"commit_sha\":\"${{ github.sha }}\",\"status\":\"$STATUS\"}"

That is exactly how iKanban records its own deploys — each row you see under the Stability drill-down is one of these calls (commit · environment · status · time).

Step 3 — Verification: report test runs

Easiest — no setup: on the Verification row, click Record test run and enter passed / total. No IDs or API key needed — use this if you don't have CI wired up.

From CI (after your suite runs):

curl -s -X POST \
  "https://api.i-kanban.com/api/teams/{TEAM_ID}/projects/{PROJECT_ID}/test-runs" \
  -H "Authorization: Bearer $IKANBAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "total": 22, "passed": 18, "failed": 4, "suite": "e2e" }'

Fields: total, passed, failed, optional suite, and optional release_id (omit it and the run auto-attributes to the project's active release). Verification = the latest run's pass rate.

Getting {TEAM_ID} / {PROJECT_ID} — these are UUIDs, not the slugs (e.g. IKA / frontend) shown in the browser URL. Fetch them with your API key:

curl -s "https://api.i-kanban.com/api/teams" \
  -H "Authorization: Bearer $IKANBAN_API_KEY"

The response lists each team's id and its projects. (Stability doesn't need this: you send the project name as app_name, and the backend finds the project.)

How the score updates

Once deploys and test runs are flowing, Stability and Verification light up automatically and the composite score (and the ship gate) reflect real delivery data — no manual upkeep. Open any axis on the scorecard to drill into the underlying issues, deploys, test runs or checklist items.