Problem Integrity Model Integration Fit Partner Demos Claims Boundary Pilot Request

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.

Get API key Request Pilot

Developer Docs

API Overview

TrustSignal exposes a narrow public API for verification requests, signed verification receipts, lifecycle status checks, and related evaluator workflows.

Developers and technical evaluators

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.

TrustSignal is an integrity layer. The upstream platform still owns workflow state, user actions, and the system of record.

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 /api/v1/verify

Submit an artifact or artifact reference and receive verification signals plus a signed verification receipt.

GET /api/v1/receipt/:receiptId

Retrieve a previously issued verification receipt for downstream storage, review, or audit use.

POST /api/v1/receipt/:receiptId/verify

Check current integrity status of an artifact against a stored receipt.

POST /api/v1/receipt/:receiptId/revoke

Revoke a receipt when lifecycle governance requires the prior verification output to be invalidated.

POST /api/v1/anchor/:receiptId

Record verifiable provenance metadata for a receipt when anchor support is enabled.

POST /api/v1/verifications/github

GitHub Actions adapter — create a verification receipt from a workflow event and return a GitHub check run conclusion.

Example Request / Response

These examples illustrate the public verification lifecycle using evaluator-safe payloads and response fields.

Example Request

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

Example Response

{
  "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",
    "note": "Experimental blockchain anchoring"
  },
  "revocation": {
    "status": "ACTIVE"
  }
}

Production Considerations

Production deployment requires explicit authentication, environment configuration, lifecycle monitoring, and verification checks before relying on prior results.

Authentication and lifecycle monitoring should be explicit, and later verification or status checks should be part of the normal integration path. The quick evaluator flow is intentionally lighter than production deployment.

Public docs live here. Developer account creation and API key issuance are routed through the configured authenticated TrustSignal surface when it is deployed; otherwise access should remain manual or pilot-gated. Start at Get your API key to move from documentation into the current access path.

Security and Claims Boundary

The public contract is intentionally narrow and excludes internal implementation details.

Proof internals, witness data, signing infrastructure specifics, and internal service topology are intentionally not exposed through the public contract.

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

Interactive Reference

Full OpenAPI 3.0 specification with interactive request/response explorer.

Open API Reference →

Also available as a downloadable OpenAPI spec.

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.