Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.beltic.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Products Used in This Guide

Everything in Beltic is built around the Workflow API. A workflow is a pipeline of verification blocks that you configure once and trigger with a single call. Credentialing is one of those blocks — add a credential_issue block and Beltic mints a signed JWT from the verified output automatically. This guide uses the Workflow API to verify the human first, with the credential_issue block producing the identity credential the agent chain depends on. It then uses the Credentials API directly to issue the agent_authorization credential — because the agent credential isn’t an output of a verification workflow, it’s a standalone authorization that references the already-verified human. If you have your own verification process, you can skip the workflow entirely and call the Credentials API directly — send Beltic the data you’ve already collected and it wraps it in a signed credential. The trust layer works the same way regardless of how the data got there.

​
The Problem

AI agents can now initiate transactions autonomously — placing orders, authorizing payments, booking services. The infrastructure to execute these transactions exists. What doesn’t exist is a standard way to prove that a real human authorized them. When an agent arrives at a payment endpoint today, the receiving system has no reliable way to answer: did a verified human authorize this? Under what constraints? Is that authorization still valid? Was the human even present? Without that proof, every agentic transaction is a trust gap. Payment processors flag it. Banks can’t satisfy AML requirements. Fraud systems default to blocking it. Beltic closes that gap with a signed, portable credential that travels with the agent and carries the human’s verification & authorization as a cryptographic fact. But that credential is only as strong as the identity behind it — which means the story starts with verifying the human first.

​
Step 1: Verify the Human Through a Workflow

Before any agent can be authorized, the human delegating to it needs to be verified. This is where Beltic’s workflow engine comes in. A workflow is a configured pipeline of verification blocks — each block performs a discrete step. You define the pipeline once in the Console, then trigger it with a single API call. Beltic runs every block in sequence, handles edge cases internally, and returns the complete output when done. For a KYC verification, a typical workflow runs blocks like these in order:
  • identity_check — validates the document, checks name and DOB
  • liveness_check — confirms the person is physically present
  • sanctions_screening — runs against OFAC, UN, EU watchlists
  • credential_issue — mints a signed JWT-VC from the verified output
You trigger it with one call: 
curl -X POST https://api.beltic.com/v1/workflows/execute \
  -H "X-Api-Key: $BELTIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflowId": "wf_kyc_standard",
    "options": {
      "input": {
        "subject_id": "user_jane_doe_001",
        "entity_type": "person",
        "document_type": "passport",
        "document_front_url": "https://your-storage.com/docs/jane_passport_front.jpg",
        "jurisdiction": "US"
      }
    }
  }'
The response contains the block-by-block output of every step that ran: 
{
  "success": true,
  "status": "completed",
  "executionId": "exec_01HQ7P4...",
  "output": {
    "identity_check": {
      "status": "passed",
      "document_type": "passport",
      "name_match": true,
      "dob_match": true
    },
    "liveness_check": {
      "status": "passed",
      "confidence": 0.98
    },
    "sanctions_screening": {
      "status": "clear",
      "lists_checked": ["OFAC", "UN", "EU"]
    },
    "credential_issue": {
      "credential_id": "cred_01HQ7P4M...",
      "credential_type": "user",
      "subject": {
        "id": "user_jane_doe_001",
        "type": "person"
      },
      "claims": {
        "kyc_status": "approved",
        "trust_level": "idv_verified",
        "verified_at": "2026-05-22T10:30:00Z",
        "jurisdiction": "US"
      },
      "signed_payload": "eyJhbGciOiJFUzI1NiIs...",
      "status": "active",
      "issued_at": "2026-05-22T10:30:00Z",
      "expires_at": "2027-05-22T10:30:00Z"
    }
  }
}
Each key in output is a block. The credential_issue block at the end takes the verified output of every preceding block and mints a signed credential from it — a tamper-proof record that the user passed every check. Store credential_issue.credential_id and signed_payload against the user record. The subject.id — user_jane_doe_001 — is now the anchor for any agent the user subsequently authorizes. The chain that starts here is: verified human → authorized agent → agent transaction.
Replace wf_kyc_standard with the ID of your own workflow. When setting up a workflow in the Console, you choose its name — that name becomes the workflowId you pass here.

​
Step 2: Issue the Agent Authorization Credential

The user has been verified. Now they open your app and configure what their agent can do — which resources, which actions, up to what spend. Your backend receives that confirmation and calls Beltic to mint the agent credential: 
curl -X POST https://api.beltic.com/v1/credentials \
  -H "X-Api-Key: $BELTIC_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "credential_type": "agent_authorization",
    "subject": {
      "id": "agent_jane_assistant_session_8821",
      "type": "agent",
      "name": "User's Assistant"
    },
    "claims": {
      "delegated_by_subject_id": "user_jane_doe_001",
      "role": ["payment_agent"],
      "permissions": [
        {
          "resource_type": "wallet",
          "resource_id": "*",
          "actions": ["payment_authorize", "checkout"],
          "conditions": [
            { "field": "transaction_amount", "op": "lte", "value": 15000 },
            { "field": "transaction_currency", "op": "eq", "value": "usd" }
          ]
        }
      ],
      "spend_limit": { "amount": 50000, "currency": "usd", "period": "daily" },
      "max_idle_duration": "PT30M",
      "human_present": true
    },
    "expires_at": "2026-05-22T18:00:00Z"
  }'
Two fields carry the human proof:
  • delegated_by_subject_id — the subject.id of the KYC-verified user from Step 1. This is the cryptographic link that lets any verifier trace the agent back to a real, verified identity. Required on any wallet-scoped permission.
  • human_present: true — attests that the human was actively present and confirmed this authorization at issuance time. A signal downstream systems rely on for AML and fraud scoring.
The response contains a signed_payload JWT. Give this to the agent runtime — it presents it on every downstream call.

​
Step 3: The Agent Transacts — the Credential Travels With It

When the agent reaches a checkout or payment endpoint, it includes the signed_payload JWT in the request. The merchant or payment processor receiving it calls Beltic’s public verify endpoint — no API key, no Beltic account needed: 
curl -X POST https://api.beltic.com/v1/credentials/_public/verify \
  -H "Content-Type: application/json" \
  -d '{
    "credential": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Iks4TDkuLi4ifQ...",
    "context": {
      "resource_type": "wallet",
      "resource_id": "*",
      "action": "payment_authorize",
      "transaction_amount": 8500,
      "transaction_currency": "usd"
    }
  }'
Permitted: 
{
  "valid": true,
  "credential_type": "agent_authorization",
  "subject": {
    "id": "agent_jane_assistant_session_8821",
    "type": "agent"
  },
  "claims": {
    "delegated_by_subject_id": "user_jane_doe_001",
    "human_present": true,
    "spend_limit": { "amount": 50000, "currency": "usd", "period": "daily" }
  },
  "policy_match": {
    "permitted": true,
    "matched_permission": {
      "resource_type": "wallet",
      "actions": ["payment_authorize", "checkout"]
    }
  },
  "status": "active",
  "verified_at": "2026-05-22T11:05:00Z",
  "verification_id": "ver_01HQ9B3R..."
}
What the verifier can now assert with cryptographic confidence:
  • A real, KYC-verified human (user_jane_doe_001) authorized this agent — traceable back to a workflow that ran identity check, liveness, and sanctions screening
  • The human was actively present at authorization time
  • This specific action (payment_authorize, $85, USD) is within the agent’s permitted scope
  • The authorization is still valid — not expired, not revoked
  • The daily spend limit has not been exceeded
Action outside permitted scope: 
{
  "valid": true,
  "policy_match": {
    "permitted": false,
    "reason": "action_not_permitted",
    "detail": "Action 'refund_issue' is not listed in the agent's permissions"
  }
}
Spend limit exceeded: 
{
  "valid": false,
  "reason": "spend_limit_exceeded",
  "detail": "Daily spend limit of $500.00 USD would be exceeded by this transaction"
}

​
Step 4: Attest the Transaction Outcome

For high-value transactions or regulated flows, wrap the final outcome in a signed outcome_attestation credential. This creates a portable record that the transaction was authorized by a verified human and completed — useful for AML audit trails, sponsor bank reporting, or dispute resolution. 
curl -X POST https://api.beltic.com/v1/credentials \
  -H "X-Api-Key: $BELTIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "credential_type": "outcome_attestation",
    "attestation_type": "transaction_attested",
    "subject": {
      "id": "txn_8821_checkout",
      "type": "transaction"
    },
    "claims": {
      "transaction_id": "txn_8821_checkout",
      "amount": 8500,
      "currency": "usd",
      "credential_id": "cred_01HQ9A2M...",
      "verification_id": "ver_01HQ9B3R...",
      "approved_by_user": true,
      "attested_at": "2026-05-22T11:05:12Z"
    }
  }'
The result is a signed JWT that any auditor, regulator, or sponsor bank can verify: at this timestamp, this transaction was authorized by a verified human, executed by their agent, within the permitted scope.

​
Step 5: Revoke When the Session Ends

Agent credentials should be short-lived. When the session ends, the user removes the agent, or a suspicious action is detected — revoke immediately: 
curl -X POST https://api.beltic.com/v1/credentials/cred_01HQ9A2M.../revoke \
  -H "X-Api-Key: $BELTIC_API_KEY"
Revocation propagates to the Status List bitstring within seconds. Every downstream system that calls Beltic to verify this credential gets valid: false — instantly, with no coordination between platforms. The agent is locked out everywhere at once.

​
The Complete Chain

KYC workflow executes
  └── identity_check block   → passed
  └── liveness_check block   → passed
  └── sanctions_screening block → clear
  └── credential_issue block → user credential (user_jane_doe_001, idv_verified)

User authorizes their agent
  └── POST /v1/credentials (agent_authorization)
        delegated_by_subject_id: user_jane_doe_001
        human_present: true
        permissions: [wallet → payment_authorize, checkout, max $150]
        → agent credential (signed_payload handed to agent runtime)

Agent reaches checkout
  └── POST /v1/credentials/_public/verify (with transaction context)
        → valid: true, policy_match: permitted
        → verifier knows: real human, verified identity, authorized action, within limit

Transaction completed
  └── POST /v1/credentials (outcome_attestation)
        → signed record linked to credential_id + verification_id
Each step is cryptographically linked to the one before it. A compliance officer, regulator, or bank can follow the chain from a specific transaction back to the identity verification workflow that authorized it — without calling your platform.

Executing a Workflow

Full reference for POST /v1/workflows/execute — block outputs, pause/resume, and all response shapes

Issuing a Credential

Full reference for agent_authorization credential claims and all four credential types

Fintech Company Using Beltic

The same identity credential used in a fintech onboarding and transaction authorization context

Verifying a Credential

The full verify pipeline — context evaluation, policy matching, and rejection codes