API
Documentation Map
-
API Reference
-
Channel:
stable -
Source repo:
JaddaHelpifyr/helpifyr-fabric
API
Tool / Contract Summary
jhf-fabric exposes a versioned REST API under /api/v1. The API is the canonical operator and consumer access layer for contract publication, readiness, drift, provider runtime observation, and downstream handoff truth.
Business Value
- gives downstream repos and operators one stable, typed interface to Fabric truth
- separates authoritative shared-state publication from repo-local materialization
- provides machine-readable and human-readable verification paths for Wiki.js, CI, and runtime checks
Current Verified State
- API base:
/api/v1 - health endpoint:
/health - OpenAPI export:
/api/v1/openapi.json - route families are assembled in
src/helpifyr_fabric/api/app.py - route implementations are split across
routes.py,identity_routes.py,plane_routes.py,support_routes.py,voice_routes.py, andcombinations_routes.py
Available Now
Core and governance routes
GET /healthGET /api/v1/platform/servicesGET /api/v1/contracts/*GET /api/v1/acp/contracts/*POST /api/v1/contracts/compatibility/checkPOST /api/v1/tools/admission/dry-runGET /api/v1/governance/*
Purpose:
- publish contract catalogs, drift, governance posture, and additive admission results
Identity and access routes
GET /api/v1/identity/contracts/*GET /api/v1/identity/agent-federation/*POST /api/v1/warp/contextGET /api/v1/projections/plane-unified-access*
Purpose:
- publish deterministic identity policy, access handoff, agent-federation, and authz projection truth
Tooling, products, and update routes
GET /api/v1/tools/*POST /api/v1/products/registerGET /api/v1/products/*GET /api/v1/capabilitiesPOST /api/v1/updates/checkPOST /api/v1/updates/rollout-gatePOST /api/v1/integrations/gitea/webhook
Purpose:
- normalize repo/tool metadata, expose compatibility views, and accept guarded intake
Provider, runtime, and platform routes
GET /api/v1/providers/openclaw/*GET /api/v1/dapr/*POST /api/v1/dapr/state/probePOST /api/v1/dapr/invocation/self-health/probeGET /api/v1/persistence/*GET /api/v1/observability/*GET /api/v1/recovery/*GET /api/v1/security/*GET /api/v1/signoff/*
Purpose:
- expose runtime dependency posture, provider observations, security, recovery, and operator signoff state
Product-domain contract routes
GET /api/v1/combinations/*GET /api/v1/support-orchestration/*GET /api/v1/voice/*GET /api/v1/memory/runtime-claims/*GET /api/v1/events/publishing/*POST /api/v1/events/outbox/*
Purpose:
- publish product-adjacent contract truth and record event/evidence flows where Fabric owns the publication path
Optional / Extended
- platform-plane-specific routes and assets that matter only when Wiki.js and observability services are deployed
- provider preview routes that explain possible actions without directly mutating host state
- product-specific surfaces used only when corresponding consumers exist
Planned / Not In Current Scope
- later governance waves and downstream behaviors not yet implemented
- any undocumented route or contract behavior must be treated as not in current scope until it exists in code and verification
Public Surfaces
Common high-value endpoints for operator and consumer usage:
GET /healthGET /api/v1/contracts/registryGET /api/v1/contracts/driftGET /api/v1/acp/contracts/capability-registryGET /api/v1/acp/contracts/skill-pack-eventsGET /api/v1/acp/contracts/agent-handoff-eventsGET /api/v1/acp/projections/reed-read-only-capabilityGET /api/v1/acp/projections/swatch-scenario-verdictGET /api/v1/acp/projections/agent-handoff-ownershipGET /api/v1/acp/contracts/tool-action-registryGET /api/v1/acp/contracts/tool-execution-evidenceGET /api/v1/contracts/jarvisGET /api/v1/combinations/profilesGET /api/v1/identity/contracts/access-mappingGET /api/v1/identity/contracts/entitlement-policyGET /api/v1/identity/contracts/surface-admissionGET /api/v1/identity/contracts/surface-accessGET /api/v1/identity/contracts/surface-lifecycleGET /api/v1/identity/consumers/onboardingGET /api/v1/identity/agent-federation/readinessGET /api/v1/projections/plane-unified-access/readinessGET /api/v1/platform/version-truthGET /api/v1/platform/projection-catalogGET /api/v1/platform/tool-oss-inventory-directoryGET /api/v1/event-modeling/standardGET /api/v1/event-modeling/catalogGET /api/v1/event-modeling/issue-spec-exportGET /api/v1/events/issue-spec-export/contractsGET /api/v1/event-modeling/readinessGET /api/v1/event-modeling/standard-health-reportGET /api/v1/event-modeling/companion-surfaces-contractGET /api/v1/event-modeling/audit-aggregation-contractGET /api/v1/event-modeling/tenant-bootstrap-contractGET /api/v1/tools/runtime-statusGET /api/v1/providers/openclaw/runtime-statusGET /api/v1/observability/readinessGET /api/v1/recovery/readiness
Contract Families
The API publishes data from:
contracts/docs/contracts/- runtime composition under
deploy/compose/ - repo metadata such as
fabric-manifest.json
OpenAPI is the machine-readable contract envelope, but route meaning is also anchored by the JSON contract artifacts and docs pages.
For platform OSS upgrade governance, Fabric now publishes one canonical version-truth surface plus one canonical projection-catalog surface instead of expecting Beam or other consumers to infer Grafana, Prometheus, Wiki.js, Dapr, n8n, or NATS pins, readback routes, or compatibility surfaces from distributed compose/docs history:
GET /api/v1/platform/version-truthGET /api/v1/platform/projection-catalogGET /api/v1/platform/tool-oss-inventory-directorycontracts/platform/platform_version_truth.jsoncontracts/platform/platform_projection_catalog.jsondocs/contracts/HELPIFYR_PLATFORM_VERSION_TRUTH.mddocs/contracts/HELPIFYR_PLATFORM_PROJECTION_CATALOG.md
For ACP Wave 0/Wave 1 contract truth, Fabric now publishes one canonical capability-registry and skill-pack event-family surface so Reed and Warp consume explicit repository-standard Manifest v2 coupling, Reed-lane admission coupling, projection semantics, and fail-closed behavior instead of reconstructing them from backlog or local repo memory:
GET /api/v1/acp/contracts/capability-registryGET /api/v1/acp/contracts/skill-pack-eventsGET /api/v1/acp/projections/reed-read-only-capabilityGET /api/v1/acp/projections/swatch-scenario-verdict
For Event Modeling Wave 1 core publication, Fabric now publishes one canonical pilot-catalog plus one issue-spec export surface so Shuttle and Warp consume the same serial-first Wave-1 truth instead of reconstructing sequencing from issue comments or chat history:
GET /api/v1/event-modeling/standardGET /api/v1/event-modeling/catalogGET /api/v1/event-modeling/issue-spec-exportGET /api/v1/events/issue-spec-export/contractsGET /api/v1/event-modeling/readinessGET /api/v1/event-modeling/standard-health-reportGET /api/v1/event-modeling/companion-surfaces-contractGET /api/v1/event-modeling/audit-aggregation-contractGET /api/v1/event-modeling/tenant-bootstrap-contractcontracts/event_modeling/event_modeling_issue_spec_export.jsoncontracts/event_modeling/event_modeling_standard_health_report.jsoncontracts/event_modeling/event_modeling_companion_surfaces_contract.jsoncontracts/event_modeling/event_modeling_audit_aggregation_contract.jsoncontracts/event_modeling/event_modeling_tenant_bootstrap_contract.jsondocs/event-models/agent-task-delegation/manifest.jsoncontracts/acp/capability_registry_v1.jsoncontracts/acp/skill_pack_event_families_v1.jsoncontracts/acp/reed_read_only_projection_v1.jsoncontracts/acp/swatch_scenario_verdict_projection_v1.jsondocs/contracts/HELPIFYR_ACP_CAPABILITY_REGISTRY_V1.mddocs/contracts/HELPIFYR_ACP_REED_READ_ONLY_PROJECTION_V1.mddocs/contracts/HELPIFYR_ACP_SWATCH_SCENARIO_VERDICT_PROJECTION_V1.md
For Wave 4 adoption parity, Fabric also publishes one canonical contract descriptor surface for later-wave issue-spec consumers so Bobbin and adjacent repos can discover the single authoritative export path instead of probing undocumented alternatives:
GET /api/v1/events/issue-spec-export/contractsGET /api/v1/event-modeling/issue-spec-exportpython scripts/check_event_modeling_wave4_adoption.py --check-live --fabric-base-url http://<internal-runtime-redacted>:28080
For Event Modeling v2.0 execution-safety and consumer-governance truth, Fabric additionally publishes:
GET /api/v1/event-modeling/standard-health-reportGET /api/v1/event-modeling/companion-surfaces-contractGET /api/v1/event-modeling/audit-aggregation-contractGET /api/v1/event-modeling/tenant-bootstrap-contract
These surfaces provide read-only truth for:
- Dobby-backed standard evolution metrics
- companion-surface read permissions and prohibited behaviors
- audit-safe aggregation boundaries
- tenant bootstrap defaults and module-onboarding linkage
For ACP Wave 2 contract truth, Fabric now also publishes one canonical tool/action registry and one canonical execution-evidence/event family surface so consumers do not create local shadow tool/action truth for approval, dry-run, rollback, or evidence semantics:
GET /api/v1/acp/contracts/tool-action-registryGET /api/v1/acp/contracts/tool-execution-evidencecontracts/acp/tool_action_registry_v1.jsoncontracts/acp/tool_execution_evidence_v1.jsondocs/contracts/HELPIFYR_ACP_TOOL_ACTION_REGISTRY_V1.md
For ACP Wave 4 contract truth, Fabric now also publishes one canonical handoff/escalation/ownership event catalog and one matching ownership projection so consumers do not invent local delegation or owner-selection truth when handoff event chains are missing, stale, circular, or conflicting:
GET /api/v1/acp/contracts/agent-handoff-eventsGET /api/v1/acp/projections/agent-handoff-ownershipcontracts/acp/agent_handoff_event_catalog_v1.jsoncontracts/acp/agent_handoff_ownership_projection_v1.jsondocs/contracts/HELPIFYR_ACP_AGENT_HANDOFF_EVENT_CATALOG_V1.md
For SSO-v4 surfaces, the API now also exposes explicit special-admin posture truth:
surface-accesspublishes machine-readableadmin_capable_surfaceandadmin_posturesconsumers/onboardingmirrors the same superadmin and recovery-only admin posture for downstream consumerssurface-lifecycledefines the audit-evidence event vocabulary forsurface-superadmin-elevatedandsurface-recovery-admin-elevated
Producer / Consumer Zuordnung
- producer:
jhf-fabric - consumers: downstream JHF repos, Wiki.js docs publishing, operators, CI, provider integrators
- rule: consumers must not infer or redefine blocked/degraded/stale/conflict semantics beyond what Fabric already publishes
Compatibility Window
- current route families are versioned under
/api/v1 - additive extension is preferred over incompatible rename or shape drift
- compatibility and admission are explicit route families, not undocumented conventions
Lifecycle Status
- active, verified, and used as the shared truth publication surface
- some preview families remain intentionally preview-only
Readiness / Drift / Monitoring
Typical route-check order:
GET /healthGET /api/v1/contracts/driftGET /api/v1/observability/readinessGET /api/v1/security/readinessGET /api/v1/recovery/readiness- subsystem-specific readiness routes relevant to the current consumer
Deployment / Verify
- local API start:
uvicorn helpifyr_fabric.api.app:app --reload - OpenAPI export:
GET /api/v1/openapi.json - test coverage:
tests/test_api.pyplus subsystem-specific tests - live host verification: route reads against
<internal-runtime-redacted>
Known Limits
- not every consumer needs every route family
- some route families summarize deeper contract documents and should be read alongside their matching docs pages
- preview endpoints must not be mistaken for direct mutation authority
Exceptions / Waivers
- local dev/test paths can differ from guarded live-host auth posture
- provider-derived runtime observations inform API output but do not replace Fabric-owned contract truth
Related Issues
- route and contract history is reflected in
docs/issues/ - contract plans live under
docs/plans/
License
- License: AGPLv3
- Project: https://helpifyr.com