Why we're building Kitwheel

Facilities platforms are built to be systems of record, not to talk to each other. Most providers wish integrating with their CMMS partners were easier, but the plumbing isn't there. So the actual integration layer of this industry is a person with two monitors, retyping work orders from one portal into another.

We've spent months reading work-order APIs: the big platforms, endpoint by endpoint. The surprising part isn't that integration is hard. It's where it's hard. The HTTP part is easy. The hard part is that the same work order doesn't mean the same thing twice.

Here's a representative example, put together from payloads we've worked with. The same job, as two platforms see it:

{
  "workorder": {
    "id": 48213,
    "status": "IN_PROGRESS",
    "priority_id": 7,
    "trade": "HVAC",
    "nte": 1500.00
  }
}

{
  "job": {
    "id": "J-2201",
    "jobStatus": "Dispatched",
    "priority": "Urgent",
    "jobTypeId": 118,
    "appointments": [{"start": "2026-08-05T13:00:00Z"}]
  }
}

Same physical technician, same broken rooftop unit. One system says IN_PROGRESS against a tenant-configured priority table; the other says Dispatched and won't even let the job exist without an appointment. Neither is wrong. They just speak different dialects. Today, a human translates.

Kitwheel is the hub in the middle: it speaks each platform's dialect, translates statuses and vocabularies both ways, and keeps every connected system telling the same story about the same work order.

We're onboarding a small group of early teams. If your week includes retyping work orders, join the beta.