Developer Docs
Developer Overview
Start at the main docs hub.
Verification Lifecycle
Artifact submission, receipts, and later comparison.
API Overview
Public request and response model.
Security Model
Claims boundary and public-safe controls.
Architecture
Workflow fit and trust-boundary framing.
Threat Model
Threat assumptions and review posture.
Developer Docs
API Overview
TrustSignal exposes a narrow public API for verification requests, signed verification receipts, lifecycle status checks, and related evaluator workflows.
Problem / Context
Compliance evidence can be collected correctly and still become harder to trust later if provenance is unclear or the artifact is challenged after collection.
TrustSignal addresses that problem by returning verifiable outputs that can travel with the artifact. The upstream platform still owns workflow state, user actions, and the system of record.
Integrity Model
The public surface returns verification signals, signed verification receipts, and later verification outputs that can be stored alongside the system-of-record entry.
How It Works
A typical integration submits an artifact or artifact reference, stores the signed verification receipt, and checks lifecycle state before relying on prior results.
POST /verify
Submit an artifact or artifact reference and receive verification signals plus a signed verification receipt.
GET /receipt/:id
Retrieve a previously issued verification receipt for downstream storage, review, or audit use.
GET /status/:id
Check current lifecycle status before relying on an earlier verification result.
POST /receipt/:id/revoke
Revoke a receipt when lifecycle governance requires the prior verification output to be invalidated.
Example Request / Response
These examples illustrate the public verification lifecycle using evaluator-safe payloads and response fields.
curl -X POST "https://api.trustsignal.dev/api/v1/verify" \
-H "Content-Type: application/json" \
-H "x-api-key: $TRUSTSIGNAL_API_KEY" \
--data @examples/verification-request.json{
"receiptVersion": "2.0",
"decision": "ALLOW",
"reasons": ["receipt issued"],
"receiptId": "623e0b54-87b3-42b7-bc89-65fae0ad8d5e",
"receiptHash": "0x4e7f2ce9d3f7a8d3b0e4c9f2aa17fd59d6b4fda2d7b7b7d1cce8124d7ee39d04",
"receiptSignature": {
"alg": "EdDSA",
"kid": "trustsignal-current",
"signature": "eyJleGFtcGxlIjoic2lnbmVkLXJlY2VpcHQifQ"
},
"anchor": {
"status": "PENDING",
"subjectDigest": "0x8c0f95cda31274e7b61adfd1dd1e0c03a4b96f78d90da52d42fd93d9a38fc112",
"subjectVersion": "trustsignal.anchor_subject.v1"
},
"revocation": {
"status": "ACTIVE"
}
}Production Considerations
Production deployment requires explicit authentication, environment configuration, lifecycle monitoring, and verification checks before relying on prior results.
Security and Claims Boundary
The public contract is intentionally narrow and excludes internal implementation details.
Claims Boundary
- • TrustSignal provides signed verification receipts.
- • Returns verification signals and lifecycle status.
- • Enables later verification of previously checked artifacts.
- • Integrates with existing compliance workflows.
Not Provided
- • Legal determinations
- • Fraud guarantees
- • Compliance certification
- • Replacement for system-of-record platforms
TrustSignal is an integrity layer, not a system-of-record replacement. The upstream platform continues to own workflow state and evidence storage.
Continue to Quick Verification Example for a lifecycle walkthrough or Security Model for public security controls.