Quickstart

This walks the full loop end-to-end: register → pick a template → configure a connector → start a run (it parks) → resume. Every step is a single curl call.

Base URL

Replace $API with your Minctrl API base URL (e.g. https://api.minctrl.com). All endpoints except /auth/* and /health require Authorization: Bearer <token>.

1. Register

Registration is open and auto-creates your company. The response contains a JWT.

curl -s -X POST "$API/auth/register" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "you@example.com",
    "password": "a-strong-password",
    "company_name": "Acme Ops"
  }'

Capture the token for the rest of the calls:

TOKEN="<token from the response>"

2. Pick a template

Browse the governed flow templates and choose a vertical slug to run.

curl -s "$API/process-templates/" \
  -H "Authorization: Bearer $TOKEN"

Pick a vertical from the list — this quickstart uses prior-auth. You can inspect its governance-decorated graph (and see which step-ids are gates) with:

curl -s "$API/process-templates/prior-auth/canvas" \
  -H "Authorization: Bearer $TOKEN"

Bind a step's tool-id to your real HTTP API. Here we point the screening tool-id at a vendor endpoint. Irreversible tools stay shadowed (dry-run) unless you set reversible: true — leave it off while testing.

curl -s -X PUT "$API/connectors/screening" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "base_url": "https://screening.vendor.com",
    "method": "POST",
    "path": "/v1/screen",
    "auth_type": "bearer",
    "auth_token": "<vendor-api-key>",
    "reversible": false
  }'

Smoke-test it without touching a real run:

curl -s -X POST "$API/connectors/screening/test" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "base_url": "https://screening.vendor.com", "method": "POST", "path": "/v1/screen" }'

4. Start a run — it parks

Start a governed run of the vertical with seed inputs. The run executes until it reaches the first human gate, then parks.

curl -s -X POST "$API/process-runs/" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "vertical": "prior-auth",
    "inputs": {
      "member_id": "M-10293",
      "procedure_code": "27447",
      "diagnosis": "M17.0"
    },
    "auto_resolve": true
  }'

The response includes the run id and a parked status naming the gate step-id it stopped on. Save both:

RUN_ID="<id from the response>"

You can re-read the run at any time:

curl -s "$API/process-runs/$RUN_ID" -H "Authorization: Bearer $TOKEN"

5. Resume

A human records a verdict against the gate step-id the run parked on. The gate is the step-id (not a display label); decision is approved, denied, or a branch label for a gateway.

curl -s -X POST "$API/process-runs/$RUN_ID/resume" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "gate": "signoff",
    "decision": "approved"
  }'

The run continues from exactly where it parked. If it reaches another gate it parks again; repeat step 5 until it completes.

Next steps

Connect a step to your API — connector config in depth.
Run a governed process — gates, park/resume, shadowing.
Governance model — why a step parks (or doesn't).