Integration sandboxWhat integrating Intellign into HeliumOS actually looks like. Back to demos

One endpoint: POST /api/v1/optimize

HeliumOS’s backend sends its own patient and bed records plus the goals it cares about — no chat, no manual review workflow, no data leaving their format. We solve it and hand back assignments.

The call

curl -X POST https://api.intellign.ai/api/v1/optimize \
  -H "Authorization: ApiKey <your-sandbox-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "problem_type": "assignment",
    "resources": [
      {
        "id": "PT-1042",
        "name": "Adaeze N.",
        "required_ward_type": "ICU",
        "severity": 9
      },
      {
        "id": "PT-1043",
        "name": "Bello M.",
        "required_ward_type": "General Ward",
        "severity": 4
      },
      {
        "id": "PT-1044",
        "name": "Chinwe O.",
        "required_ward_type": "Maternity",
        "severity": 6
      },
      {
        "id": "PT-1045",
        "name": "Dauda K.",
        "required_ward_type": "ICU",
        "severity": 8
      },
      {
        "id": "PT-1046",
        "name": "Efe I.",
        "required_ward_type": "General Ward",
        "severity": 3
      },
      {
        "id": "PT-1047",
        "name": "Fola A.",
        "required_ward_type": "Paediatrics",
        "severity": 5
      }
    ],
    "targets": [
      {
        "id": "BED-A1",
        "ward_name": "ICU Bay 1",
        "ward_type": "ICU",
        "capacity": 2
      },
      {
        "id": "BED-B4",
        "ward_name": "General Ward B",
        "ward_type": "General Ward",
        "capacity": 2
      },
      {
        "id": "BED-M2",
        "ward_name": "Maternity Wing",
        "ward_type": "Maternity",
        "capacity": 1
      },
      {
        "id": "BED-P1",
        "ward_name": "Paediatric Ward",
        "ward_type": "Paediatrics",
        "capacity": 1
      }
    ],
    "goals": [
      {
        "description": "Match patient condition to ward type.",
        "resource_columns": [
          "required_ward_type"
        ],
        "target_columns": [
          "ward_type"
        ],
        "logic_config": {
          "logic_type": "categorical_match",
          "exact_match": true
        },
        "weight": 60,
        "award_type": "Reward"
      },
      {
        "description": "Prioritise higher-severity patients for placement.",
        "resource_columns": [
          "severity"
        ],
        "target_columns": [],
        "logic_config": {
          "logic_type": "weighted_scoring"
        },
        "weight": 40,
        "award_type": "Reward"
      }
    ],
    "quality_mode": "fast"
  }'

Sample data — 6 patients, 4 beds

This is the exact payload the button below sends — real patient IDs, ward types, and severity scores, shaped like a real HeliumOS export.

Resources (patients)
PT-1042 · Adaeze N. · ICU · sev 9
PT-1043 · Bello M. · General Ward · sev 4
PT-1044 · Chinwe O. · Maternity · sev 6
PT-1045 · Dauda K. · ICU · sev 8
PT-1046 · Efe I. · General Ward · sev 3
PT-1047 · Fola A. · Paediatrics · sev 5
Targets (beds)
BED-A1 · ICU Bay 1 · ICU · cap 2
BED-B4 · General Ward B · General Ward · cap 2
BED-M2 · Maternity Wing · Maternity · cap 1
BED-P1 · Paediatric Ward · Paediatrics · cap 1
Hits our real backend with a real sandbox key — solved in under a second.
Their production data never leaves their infrastructure until this call — no upload step, no storage on our side beyond the run itself. Goals are configured once and reused, not re-typed per request.