> ## Documentation Index
> Fetch the complete documentation index at: https://docs.manthan.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# Receipt Verification

> Verifying an Execution Trust Record and generating its Receipt

[Verification](/docs/concepts/verification) and [Receipt](/docs/concepts/receipt) generation both already happen automatically as the last two steps of [`POST /execute`](/docs/guides/basic-execution). This guide covers triggering them independently afterward.

## Trigger a new verification

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST http://localhost:3000/verify \
    -H "Content-Type: application/json" \
    -d '{ "businessTransactionId": "..." }'
  ```

  ```python Python SDK theme={null}
  verification = client.verification.verify(business_transaction_id)
  ```
</CodeGroup>

<Warning>
  The TypeScript SDK's `client.verify()` does **not** do this — it calls `GET /verification/:id` to read the latest already-computed Verification instead. If you're on TypeScript and need to force a fresh verification, call `POST /verify` directly over HTTP; there's no wrapping method for it. See [REST API → Verify](/docs/api/verify) and [Python SDK → ParmanaClient](/docs/python-sdk/parmana-client) for the full explanation of why the two SDKs diverge here.
</Warning>

Each call to `POST /verify` re-hashes the trust record via `VerificationCrypto.verify()` (see [Packages → crypto](/docs/packages/crypto)) and appends a new [`Verification`](/docs/concepts/verification) — it doesn't replace the previous one. Read the whole history back with [`GET /trust-records/:id`](/docs/api/trust-records).

## Generate a Receipt

```bash theme={null}
curl -X POST http://localhost:3000/receipt \
  -H "Content-Type: application/json" \
  -d '{ "businessTransactionId": "..." }'
```

`ReceiptService.generate()` requires `trustRecord.verifications.at(-1).status === VERIFIED` — if the most recent Verification failed (or none exists yet), Receipt generation throws `ReceiptGenerationError` rather than producing a Receipt. If you need a Receipt after a failed verification, call `POST /verify` again first to produce a new, successful Verification.

## Reading a Receipt back later

```bash theme={null}
curl http://localhost:3000/receipt/latest/b6f1c8de-1a2b-4c3d-8e9f-0a1b2c3d4e5f
```

<Warning>
  This path is `/receipt/latest/:id`, not `/receipt/:id` — and neither SDK has a method for it at all. See [REST API → Receipt](/docs/api/receipt#get-the-latest-receipt). If you need a Receipt through an SDK without regenerating one, read it off [`GET /trust-records/:id`](/docs/api/trust-records)'s `.receipts` array instead.
</Warning>

<Note>
  `examples/05-verification`'s `run.ts` is currently an unimplemented stub (`console.log("Parmana Example 05 - Verification")`) — there's no runnable example for this flow yet in the monorepo. This guide is grounded directly in `packages/runtime/src/services/verification-service.ts` and `receipt-service.ts`.
</Note>

## Related

<CardGroup cols={2}>
  <Card title="Verify (REST API)" href="/docs/api/verify">Full endpoint reference.</Card>
  <Card title="Receipt (REST API)" href="/docs/api/receipt">Full endpoint reference.</Card>
  <Card title="Security Model" href="/docs/architecture/security-model">What the hash and signature actually guarantee.</Card>
  <Card title="Deterministic Replay" href="/docs/guides/deterministic-replay">A related but distinct integrity check.</Card>
</CardGroup>