Skip to main content
Public module: The Go SDK is available as a public Go module. No special configuration required.

Installation

Quick Start

main.go

Revoke an attestation

Permanently invalidate an attestation. Once revoked, any verification check returns REVOKED. This action cannot be undone — if you need to issue an updated credential instead, use supersede.
revoke.go
Revocation is permanent and recorded in the transparency log. You cannot undo it. Use supersede if you need to replace a credential with an updated version.

Supersede an attestation

Replace an existing attestation with an updated version. The original is marked as SUPERSEDED and linked to the new one, creating an auditable version chain.
supersede.go
Both the original and new attestation remain in the transparency log. Verifiers can trace the full chain using the superseded_by_attestation_id field on the original.

Configuration

Idempotency keys

The SDK generates an Idempotency-Key header automatically on every write operation (mint, revoke, supersede), making retries safe by default. If a request fails and is retried, the server returns the original response instead of performing the action twice. When multiple applications share the same tenant, set IdempotencyPrefix to namespace the auto-generated keys and prevent collisions:
With these prefixes, a key generated by the billing service looks like billing-svc_<uuid>, while onboarding produces onboarding-svc_<uuid> — so concurrent requests from different services never conflict.
Idempotency keys expire after 24 hours. If you omit IdempotencyPrefix, keys are generated without a prefix and are still unique per request.

Retry behavior

When MaxRetries is set (default: 3), the SDK automatically retries failed requests using exponential backoff with jitter. You do not need to implement retry logic yourself for transient failures.

What gets retried

The SDK retries a request when all of the following are true:
  • The HTTP status code is retryable: 408, 429, 500, 502, 503, or 504
  • The retry count has not exceeded MaxRetries
  • The request context has not been cancelled or timed out
Requests that return 400, 401, 403, 404, or 409 are not retried because these indicate a problem with the request itself.

Backoff schedule

Retry delays use exponential backoff with jitter to avoid thundering-herd effects: The delay doubles on each attempt and is capped at 2 seconds. Jitter adds up to ±20% randomization.

Retry-After header

When the API returns a 429 response with a Retry-After header, the SDK respects the server-specified delay instead of using the calculated backoff. This ensures you do not retry faster than the rate limit allows.

Disabling retries

Set MaxRetries to 0 to disable automatic retries entirely:
The SDK generates idempotency keys automatically for write operations, so retries for mint and revoke calls are safe. See idempotency keys to configure a prefix for multi-service environments.

Error handling

API errors are returned as *truthlock.Error, which implements the standard error interface.
Error handling

API Methods

All methods accept a context.Context as the first argument for cancellation and deadline propagation.

Issuers

  • client.Issuers.Create(ctx, req)
  • client.Issuers.Get(ctx, id)
  • client.Issuers.List(ctx)
  • client.Issuers.Trust(ctx, id)
  • client.Issuers.Suspend(ctx, id, reason)
  • client.Issuers.Revoke(ctx, id, reason)

Keys

  • client.Keys.Register(ctx, issuerId, req)
  • client.Keys.List(ctx, issuerId)
  • client.Keys.Rotate(ctx, kid, req)
  • client.Keys.ReportCompromise(ctx, kid)

Attestations

  • client.Attestations.Mint(ctx, req)
  • client.Attestations.Get(ctx, id)
  • client.Attestations.List(ctx)
  • client.Attestations.Revoke(ctx, id, req)
  • client.Attestations.Supersede(ctx, id, req)see supersede API
  • client.Attestations.GetProofBundle(ctx, id)

Receipts

  • client.Receipts.Mint(ctx, req)
  • client.Receipts.Get(ctx, id)
  • client.Receipts.List(ctx, filter)
  • client.Receipts.Revoke(ctx, id, req)
  • client.Receipts.ListTypes(ctx)
  • client.Receipts.GetType(ctx, name)
  • client.Receipts.CreateType(ctx, req)
  • client.Receipts.GetProofBundle(ctx, id)see proof bundle API
  • client.Receipts.Verify(ctx, receiptID)see verify API
  • client.Receipts.Search(ctx, query)see search API
  • client.Receipts.Export(ctx, req)see export API
  • client.Receipts.GetExport(ctx, exportID)
  • client.Receipts.Redact(ctx, id)see redact API

Verification

  • client.Verify.VerifyOnline(ctx, req)

API Keys

  • client.APIKeys.List(ctx)
  • client.APIKeys.Create(ctx, req)
  • client.APIKeys.Revoke(ctx, id)

Audit

  • client.Audit.Query(ctx, params)
  • client.Audit.Export(ctx, req)

Governance

  • client.Governance.ListRequests(ctx)
  • client.Governance.CreateRequest(ctx, req)
  • client.Governance.ApproveRequest(ctx, id)
  • client.Governance.ExecuteRequest(ctx, id)

Querying audit logs

Retrieve audit events to track API activity, monitor security events, and generate compliance reports. Filter by action, actor, resource, or time range.
audit.go
See the audit API reference for the full list of filter parameters.

Governance workflows

Manage formal issuer actions — suspend, revoke, reinstate, and change trust tier — through a multi-party approval workflow. Create a request, collect approvals from authorized reviewers, then execute.
governance.go
See the governance API reference for the full request and response schemas.

Receipt operations

Mint, verify, search, export, and redact cryptographically signed receipts. See the receipts guide for an overview of receipt types and the full lifecycle.
receipts.go
See the receipts API reference for the full request and response schemas.