Skip to main content
POST
Mint Attestation
Signs a payload using an issuer’s available signing key and records the resulting attestation. Issuer policy, key status, environment, and usage limits can prevent minting.

Choose a record type

For a structured record, choose schema from the record-type dropdown and enter a JSON object in claims. Leave payload_b64url empty. The server serializes these fields into the signed JSON payload. This identifies the record type; it does not independently establish that the claims are true.

Choose a verification pack

Verification packs belong to your workspace. Use the selector below with the same environment and API key as Try it, then copy the selected ID into pack_id. Omit that field for a standalone record. You can also use List verification packs or Mint in Console.

Use an existing payload

If you already have the exact bytes to sign, omit schema and claims. Encode the original bytes as unpadded base64url in payload_b64url. For JSON, serialize the object first. Application fields such as subject, claims, and schema belong inside those encoded bytes; use them either through the structured input above or inside the encoded bytes, never both. This endpoint does not independently verify the truth of submitted claims or validate arbitrary credential schemas. Use the key’s kid and matching alg. Public-key registration alone does not make a private signing key available. See issuer keys.

Retry safely

Idempotency-Key is required. Generate one value per intended mint and retain it with the original request for retries. Do not reuse it for different content.

Document integrity

The stored document hash is selected in this order:
  1. claims.document.sha256 inside a JSON payload.
  2. The request’s document_hash.
  3. SHA-256 of the decoded payload bytes.
An embedded hash takes precedence over the separate field. Include the hash in the signed payload when you need to bind that claim to the signature. A submitted hash is a claim about a file; the server cannot establish the file’s contents from the hash alone. Pass document_hash_hex to verification to compare a file hash. Keep the original payload for payload-integrity verification.

Response and delivery

HTTP 201 returns attestation_id, issued_at_unix, signature, and log. The log position is log.leaf_index, not a top-level log_index. recipient_email requests asynchronous notification. HTTP 201 confirms minting, not email delivery. Omit it when distributing the record yourself. See the quickstart for a request using the actual input and response fields.

Record-type field guide

These fields are suggested claim structures, not a claim-validation or identity-check guarantee.

Authorizations

X-API-Key
string
header
required

API key for machine-to-machine authentication

Headers

Idempotency-Key
string
required

Retain the same value and request body when retrying one mint.

Body

application/json

Choose either raw payload_b64url or the structured schema and claims fields. Never send both formats.

issuer_id
string<uuid>
required

The UUID of the issuer creating the attestation

Example:

"550e8400-e29b-41d4-a716-446655440000"

kid
string
required

Key identifier for the signing key

Example:

"es256-key-1"

alg
enum<string>

Must match the selected issuer signing key.

Available options:
Ed25519,
ES256,
ES384,
ES512,
RS256,
RS384,
RS512,
PS256,
PS384,
PS512
attestation_id
string
content_type
string

MIME type of the original bytes, such as application/json, application/pdf or image/png. Structured schema/claims input requires application/json.

Example:

"application/json"

document_hash
string

Optional hexadecimal SHA-256 document hash. An embedded claims.document.sha256 takes precedence; otherwise this field is used, then the decoded payload hash.

pack_id
string<uuid>

Optional workspace verification-pack UUID. Use List verification packs with the same API key to select an existing active pack; omit for a standalone record.

payload_b64url
string

Unpadded base64url of the exact bytes to sign. Use this OR schema plus claims.

recipient_email
string<email>

Email address of the credential recipient. When provided, the platform sends a notification email with a link to view the attestation on the consumer portal (verify.truthlocks.com). If the recipient does not have a consumer portal account, they receive an invitation to sign up. This enables B2C credential delivery workflows.

schema
enum<string>

Record type for structured input. Provide claims and omit payload_b64url. This label does not independently validate the truth of claims.

Available options:
verifiable-id,
passport,
drivers-license,
government-id,
self-sovereign-id,
employment-verification,
professional-role,
membership-card,
professional-certification,
license,
accreditation,
degree,
completion-cert,
course-credit,
transcript,
micro-credential,
training-completion,
medical-license,
dea-registration,
board-certification,
health-credential,
vaccination-record,
aml-kyc,
security-clearance,
sam-gov,
jurisdiction-approval,
attestation-of-will,
bank-verification,
credit-attestation,
income-verification,
skill-badge,
competency,
industry-cert,
product-authenticity,
chain-of-custody,
origin-verification,
custom,
attestation
Example:

"verifiable-id"

claims
object

Structured record fields. Required with schema; cannot be combined with payload_b64url.

Example:

Response

Attestation minted

attestation_id
string<uuid>
issuer_id
string<uuid>
version
string
status
string
issued_at_unix
integer<int64>
payload_hash
string
signature
object
log
object
governance
object | null