> ## 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.

# Verify

> POST /verify and the real path behind "get the latest Verification"

## Trigger a verification

```
POST /verify
```

Implemented in `packages/api/src/routes/verify.ts`. Validates `businessTransactionId` (required, and must match the same UUID pattern used by `POST /execute`), then calls `application.verify(businessTransactionId)` — [`VerificationService.verify`](/docs/packages/verification) in `packages/runtime/src/services/verification-service.ts`.

```bash theme={null}
curl -X POST http://localhost:3000/verify \
  -H "Content-Type: application/json" \
  -d '{ "businessTransactionId": "b6f1c8de-1a2b-4c3d-8e9f-0a1b2c3d4e5f" }'
```

<Note>
  `VerificationService.verify` re-hashes the stored [Execution Trust Record](/docs/concepts/execution-trust-record) with `VerificationCrypto.verify` (`packages/crypto/src/VerificationCrypto.ts`) and compares it against the persisted `trustRecordHash`. A new, immutable [`Verification`](/docs/concepts/verification) record is created and appended to the trust record either way — `status` is `VERIFIED` or `FAILED` depending on the hash comparison.
</Note>

**Response `200`** — the newly created [`Verification`](/docs/concepts/verification).

**Response `400`**

```json theme={null}
{ "error": "businessTransactionId is required." }
```

or

```json theme={null}
{ "error": "businessTransactionId must be a valid UUID." }
```

## Get the latest Verification

<Warning>
  **This is not `GET /verify/:id`.** `packages/api/src/app.ts` mounts `packages/api/src/routes/verify-get.ts` (which defines `router.get("/:id", ...)`) under the path **`/verification`**, not `/verify`:

  ```ts theme={null}
  app.use("/verify", verifyRoutes);           // POST / only
  app.use("/verification", verificationRoutes); // GET /:id
  ```

  The real, working endpoint is:

  ```
  GET /verification/:id
  ```

  This is confirmed by the route's own integration test (`packages/api/test/verification-api.test.ts`), which calls `GET /verification/txn-001`. Treat any reference elsewhere to `GET /verify/:id` as describing intent, not the mounted route.
</Warning>

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

`verify-get.ts` loads the trust record via `application.getTrustRecord(id)` and returns `record.verifications.at(-1)` — the most recently appended Verification, not a specific one by its own `verificationId`.

**Response `200`** — the latest [`Verification`](/docs/concepts/verification).

**Response `404`**

```json theme={null}
{ "error": "Execution Trust Record not found." }
```

or

```json theme={null}
{ "error": "Verification not found." }
```

## SDK equivalents

<CodeGroup>
  ```ts TypeScript theme={null}
  const verification = await client.verify(businessTransactionId);
  ```

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

<Note>
  Both SDKs' "verify" call is a **read** of the latest Verification, not a way to trigger `POST /verify` directly. TypeScript's `VerificationApi.verify()` (`typescript/src/client/VerificationApi.ts`) sends `GET /verification/${businessTransactionId}` — it correctly targets the real mounted path, matching what's described above rather than the `/verify/:id` shape you might expect from the method name. Neither SDK exposes a method that calls `POST /verify` — in practice, verification is triggered as a side effect of [`execute()`](/docs/api/execute), and these SDK calls are for reading the result afterward.
</Note>

## Related

<CardGroup cols={2}>
  <Card title="Verification" href="/docs/concepts/verification">The concept this endpoint reads and writes.</Card>
  <Card title="Replay" href="/docs/api/replay">A related but distinct integrity check — see that page for how it differs from verification.</Card>
  <Card title="Error Model" href="/docs/api/error-model">Canonical vs. actual error shapes for these routes.</Card>
  <Card title="Receipt Verification Guide" href="/docs/guides/receipt-verification">Using verification as a precondition for receipt generation.</Card>
</CardGroup>