Developer reference

Build against an explicit scope, version and evidence trail.

The design goal is a stable integration contract with transparent ownership, mapped input, rule version, result and review boundary.

Discuss your workflow

Canonical object

A record can represent more than one delivery.

{
  "trip_id": "example-trip",
  "consignments": [{
    "consignment_id": "example-consignment",
    "stops": [],
    "parties": [],
    "documents": []
  }],
  "provenance": {
    "source_system": "example-tms",
    "mapping_version": "example-v1"
  }
}

This is an illustrative internal shape, not a new exchange standard. Real integration profiles must adopt relevant external specifications and handle multi-stop, multi-consignment access boundaries.

Result design

Every failed rule should be actionable.

RULE

Profile and version

Identify the exact subset, rule and profile version being evaluated.

FIELD

Source and owner

Link a missing or conflicting value to the system and party that can fix it.

TRACE

Evidence and correlation

Retain the check time, fixture or payload reference and review state.

Capability status

Do not mistake a sample for a production integration.

Capability	Status	Meaning
Browser assessment and field-name scanner	PUBLIC DEMO	Local educational tools only
Customer-specific mapping and fixtures	PILOT OFFER	Requires defined statement of work
Public preflight API / SDK	PLANNED	No public endpoint
Authority submissions	NOT AVAILABLE	Do not treat this project as a certified platform or Gate

See conceptual API contract