Connect a receipt API.

Mint and verify a receipt over HTTP.

This example documents the free-receipt API, not a universal verifier. Confirm the current response schema and inspect its data-handling terms before submitting content. Language SDKs are in private preview; no SDK equivalence is established here.

SDK previews and roadmap

Version the schema and its verification rules.

The following is an illustrative field map, not valid request JSON or a schema accepted by every verifier. Commercial profiles, typed contracts and retained operator envelopes have different formats. Verify compatibility against the exact implementation revision.

Commercial receipt profiles and pricing

These commercial profile examples use receipt_profile and receipt_schema_version; other typed contracts use their own schema. Retention and crypto-agile fields describe profile goals, not verified storage recovery or production signature acceptance. Select and validate the exact endpoint before integration.

• receipt_profile is selected per call. Default is standard when no profile is requested.
• A RubricMesh recommendation is not regulatory approval or automatic deployment capacity. Confirm the actual endpoint output and the requirements supplied to it.
• Use the verifier for the exact receipt schema and signature algorithm. The /verify browser supports its documented receipt format, not every contract or PQ profile.
• This profile declares design posture, not an executed PQ signature. The seven reviewed typed contracts use Ed25519. Separately, retained operator envelopes pass local ML-DSA-65 verification; issuer authentication and production acceptance remain separate. ML-KEM is key encapsulation, not a second signature. See endpoint capability evidence.
• Legacy proof_tier compatibility must be tested against the selected verifier. A field name alone cannot establish acceptance.
• Retention schedules must identify artifact classes, start events, legal holds, deletion behavior and verification methods. Receipt, raw-content, inspection, account, log, backup and processor-copy retention may differ. Recovery and enforcement are untested here.

Verify a supported receipt in your browser.

The /verify browser checks current receipt bytes and distinguishes cryptographic validity from issuer trust. Mesh and countersigner evidence are separate checks with explicit unavailable and unchecked states.

• Local signature checks do not require a network call. Loading public samples or checking mesh/countersigner evidence contacts the named endpoints.
• Independent key pins are required for trusted issuer claims. SDK equivalence is not asserted here.
• Example receipts and local tests do not establish customer integration or production acceptance.
• Classical browser format: signed_payload object, signature as 64-byte hex, and public_key_hex as 32-byte hex. alg must be absent or Ed25519. Optional raw_payload must match current bytes; sequence fields must agree. The parser rejects duplicate keys and preserves numeric spelling for its sorted-key canonicalization.
• Countersigner format: signed_over, signed_over_canonical, base64 countersignature and countersigner_public_key_b64, plus root/path material. Ed25519 and BLAKE3 checks establish signature and supplied-root consistency, not trusted-checkpoint freshness or log consistency. The countersigner is Hive-operated, not organizationally independent.
• Typed PQ format: {envelope, fragments}, with object=afir.attestation, version=1.0.0-typed-pq, sig_scheme=ml-dsa-65, inline base64 signature and canonical fragment inputs. Retained fixtures use SHA-256, linear aggregation and a 32-byte decoded digest as the signed message. This is a separate format from the classical receipt. Use the verifier's explicit supported-profile list; unsupported suites or aggregation modes are not successes.
• Size: ML-DSA-65 signatures are 3,309 raw bytes, or 4,412 base64 characters, before keys and receipt fields. NIST FIPS 204, Table 2. Retained measured bundles range from 11,532 to 76,325 bytes as stored; these are not fixed product receipt sizes. See measurement boundaries.

Endpoint evidence and acceptance status

Review boundary: 2026-09-05. Unknown means no accepted evidence, not a successful check. No customer integration or production throughput was established.

Endpoint evidence inventory records schemas, algorithms, key and trust sources, source and deployment observations, test scope and durability limits. The backend route inventory covers explicit source registrations, not production acceptance. Claim register tracks the wording and evidence boundaries used across these pages. A recorded response or source revision does not establish all acceptance requirements.

Typed routes below are POST paths under https://thehiveryiq.com/v1. Their reviewed source is e06d916b261dc495ca8e841130d6d973f224a5aa; deployed revision is unknown. Health catalog and advertised keys are service declarations, not independent trust acceptance.

Readiness requires dated successful positive, adversarial, schema, smoke, benchmark and signature-acceptance artifacts, bound to exact source/deployed revisions, endpoint, schema, algorithm and trusted key. Health listings, filenames, examples and mock/local runs do not satisfy that gate. The historical PRODUCTION_MANIFEST.json is an unverified legacy observation, not deployment acceptance. Naming FIPS 203 or 204 does not establish module validation or regulatory compliance.