Hub API description
The conformance classes define what a Class H hub must do. This describes the HTTP surface it does it over, in a form a machine can read.
sp1-hub.openapi.json — OpenAPI 3.1.
What it covers
Section titled “What it covers”Only the protocol surface: certificate capture, public verification, withdrawal, grants and redemption, current values under a live grant, evidence-pack export, and the outbound event feed.
What it deliberately omits
Section titled “What it deliberately omits”Portal, admin, consumer-account, authentication, billing, and webhook-management
endpoints. Those are operator concerns, not protocol — describing them would
invite integrations against surfaces an operator is free to change without
breaking anyone’s conformance. /v1/share/sandbox-consent is likewise omitted:
it is a demonstration affordance, not part of SP/1.
Its relationship to the specification
Section titled “Its relationship to the specification”This document is authoritative for shape — paths, methods, status codes, and payload structure. It is not authoritative for behavior. Canonicalization, fingerprint composition, and the audit chain are normative in the specification itself, and where the two disagree, the specification wins.
Why it can be trusted not to drift
Section titled “Why it can be trusted not to drift”The reference hub’s test suite compares this document against its running route table on every build, and fails in both directions: a documented path that no longer exists, and a hub path added without being described. A published description that quietly diverges is worse than none, because it makes a second implementer build against a contract nobody honors.