For Developers

An event-driven material ledger. API-first. Agent-ready.

RunBlu is a protocol layer for material state management. If you're building integrations, automating procurement, or connecting field systems — start here.

Read the architecture overview →
Architecture

Three layers. One truth.

TRACK & ENFORCE

Track and enforce material state across physical locations. Receive, allocate, transfer, consume, return. Every state change is an immutable event on the ledger. This is the layer that field teams and purchasing interact with daily.

INTEGRATE & SYNC

Deterministic state engine with ERP sync, procurement system integration, and accounting bridge. Material state flows into your financial systems automatically. Bi-directional — changes in the ERP flow back into RunBlu's context layer.

BUILD & EXTEND

RESTful API. Webhook events. Agent-compatible endpoints. This is the surface you build on. Automated reorder triggers, AI-driven allocation optimization, predictive procurement — anything that reads or writes material state goes through the protocol layer.

Integrations

Connects to what you already run.

ERP Systems

Sync material state to financial records. Two-way data flow keeps both systems current.

Procurement

PO automation driven by real inventory data. Stop ordering what you already have.

Accounting

Cost allocation by job, phase, and crew. Material spend tied to actual consumption, not just purchase.

Field Apps

Barcode and scan-based receiving and transfers. Crew actions become ledger events in real time.

Custom via REST API

Full REST API with webhook events. Build whatever your operation needs on top of the material ledger.

AI & Agent Ready

Agent-compatible endpoints for autonomous procurement, allocation optimization, and predictive restocking.

The Ledger

Append-only. Immutable. Auditable by default.

The ledger is append-only. Once an event is recorded, it cannot be edited or deleted. This is what makes RunBlu trustworthy for high-stakes material tracking. Every transition is immutable, timestamped, and attributed to an actor.

The API exposes both the current state of any material and its complete event history. Query the state endpoint to see what you have and where. Query the events endpoint to understand how it got there — every step, every actor, every timestamp.

This is audit-grade by design. No manual reconciliation. No "who changed what and when" spreadsheets. The ledger is your source of truth.

GET /api/v1/materials/mat_3kx9f2/state
{
  "material_id": "mat_3kx9f2",
  "description": "3/4\" EMT Conduit, 10ft",
  "quantity": 48,
  "state": "ALLOCATED",
  "location": "job_site_1247",
  "last_updated": "2026-03-31T06:52:00Z"
}
GET /api/v1/materials/mat_3kx9f2/events
[
  {
    "event_id": "evt_7lk1q9",
    "type": "RECEIVED",
    "timestamp": "2026-03-28T09:15:00Z"
  }
  ...
]
State Transitions

Every material follows the same state machine.

RECEIVEDSTOREDALLOCATEDIN_TRANSITON_SITEINSTALLED
RETURNEDSTORED
CONSUMED
WRITTEN_OFF

State transitions are enforced by the system. You can't allocate material that hasn't been received. You can't transfer material that's already installed. The ledger won't accept invalid transitions — that's what makes it trustworthy.

Want API access?

We're onboarding integration partners now. If you're building for contractors or connecting field systems, let's talk architecture.

Or book a technical walkthrough →