# Legacy V2 API

The Legacy V2 API exists for compatibility with older POS integrations (the FiscoBridge-era contract). New integrations should use v3. V2 signing reuses the exact same fiscalisation pipeline as v3 — only the request parser and the returned result shape differ.

## Endpoints

<table id="bkmrk-endpointpurpose-get-"><thead><tr><th>Endpoint</th><th>Purpose</th></tr></thead><tbody><tr><td>`GET /api/attention`</td><td>Availability + readers.</td></tr><tr><td>`GET /api/status`</td><td>Availability + readers.</td></tr><tr><td>`POST /api/sign`</td><td>Sign an invoice (V2 request → V2 result).</td></tr><tr><td>`POST /api/sign/SignInvoice`</td><td>Alias of `/api/sign`.</td></tr></tbody></table>

PIN verification uses the same `POST /api/v3/pin` as v3 — the cached PIN is shared across both APIs.

## Key differences from v3

- **Single payment type.** The V2 request carries one request-level `paymentType` (not a `payment` array). A single payment is synthesised with an amount equal to the sum of item totals.
- **Stringly-typed nested fields.** `items` and `options` are provided as JSON *strings*, and item `labels` is a JSON string such as `"[\"A\"]"`.
- **`buyerCostCenterId`** limit is 15 chars in V2 (50 in v3).
- **`unitPrice`** defaults to 1 if omitted (v3 requires it).
- **Result shape** is the abbreviated legacy `FiscalizationResultV2` (short field names) rather than the full-named v3 `InvoiceResult`. The underlying values (verification URL, QR, journal, signature, counters) are the same.

## Request fields (V2)

<table id="bkmrk-fieldnotes-invoicety"><thead><tr><th>Field</th><th>Notes</th></tr></thead><tbody><tr><td>`invoiceType`</td><td>`Normal` / `ProForma` / `Copy` / `Training` / `Advance`.</td></tr><tr><td>`transactionType`</td><td>`Sale` / `Refund`.</td></tr><tr><td>`paymentType`</td><td>Single value: `Cash`, `Card`, etc.</td></tr><tr><td>`items`</td><td>JSON string of an array of `{ gtin, name, quantity, unitPrice, labels, totalAmount }`; `labels` itself is a JSON string like `"[\"A\"]"`.</td></tr><tr><td>`dateAndTimeOfIssue`, `cashier`, `buyerId`, `buyerCostCenterId`, `invoiceNumber`, `referentDocumentNumber`, `options`</td><td>As v3, with the V2 limits noted above.</td></tr></tbody></table>

## Validation

V2 validation returns the same 400 `modelState` shape as v3; a parse failure (unparseable date, wrong JSON type) is reported as `2805` (field value invalid). You can dry-run a V2 request with `POST /api/v3/invoices/v2/validate`.

## Recommendation

Use V2 only to keep an existing POS working. For new development, target v3 for the typed `payment` array, the richer result fields, and `RequestId` idempotency.